JeremyNicoll

Automatic updates didn't happen for several days

Recommended Posts

Using EIS v11.6.0.6267 on a 64-bit W8.1 system.

 

(Incidentally, why can't I c&p that version number out of the 'About' screen?)

 

My EIS is configured to update itself every hour.  I just noticed that the systray icon was orange, and looked at the

'Security Overview' screen, which said it was several days since an update had happened.  I triggered a manual

update, which worked ok. 

 

The machine's been on for days, though 'asleep' quite a lot.  But I've been actively using it for many hours out of

the last 12 or so, so it should have tried to update ten or eleven times in that period.   The update log shows

hourly updates occurring on the 4th, 5th and 6th of April then nothing at all - no error messages - no success

messages, until the 'Update successful' for the update I just did manually about half an hour ago. 

Share this post


Link to post
Share on other sites

A few others mentioned issues updating late last week. Most of them have reported back that the issue has been resolved now. Are you still having issues?

Share this post


Link to post
Share on other sites

It's been fine since my manual update, with about 11 updates each day so far.  But, the issue isn't so much whether

it's working now, but that it was /silently/ failing before.  I find the tiny systray shield really doesn't attract the eye

when it goes orange, not least because it's next to a whole load of multi-colour icons.  I think EIS should produce

some sort of alert if it hasn't been updated for some (configurable threshhold?) length of time.

 

 

Any chance of getting the product release number c&p-able?

Share this post


Link to post
Share on other sites

After 24 hours with no update, Windows will display an alert to let you know that EIS is not up to date (unless those alerts are turned off).

I'll forward the request about making the version number copyable.

Share this post


Link to post
Share on other sites

I've got "Show icons and notifications" or "Only show notifications" set for every
possible option.  But my question was more in trying to find out if the notification
is caused by EIS saying to Windows "here's a notification that you might want to
display", or whether some part of Windows itself, maybe its Security Centre, is
meant to notice that updates have stopped for an installed security product.

Should such an alert happen just once?  Or every 24 hours, or what?   If the 24-hour
point comes when the machine is asleep, should it happen when the machine is next
woken up?

Share this post


Link to post
Share on other sites

The notification is from the Security Center (or Action Center as it's called in newer versions of Windows). There's information at this link (note that there are lots of ads at that link) on how to use it, however I don't think it covers notifications specifically.

Share this post


Link to post
Share on other sites

There's only one entry for EIS, in the Security section of the Action Centre, and it says that EIS is on.

 

I know that back in XP days it was normal for the Security Centre to be bad at recognising if non-MS

anti-virus/malware & firewall products were even installed, far less whether they were working properly,

and I'd have thought that an element of the same is still true.

 

Do you actually expect Action Centre to monitor whether EIS is updating properly, all by itself?  I'd

have thought MS, at best, would provide an API that EIS would have to use, perhaps just telling

Action Centre each time an update has been done, so that Action Centre can look for that not

happening.  Otherwise, MS would need to poke around in the inner workings of all the different 

security companies' products to try to see if updating is working.  

Share this post


Link to post
Share on other sites

It's possible the way it works is EIS has to send something to the Action Center to tell it when something is wrong, however I'm not certain about that. It's hard to get information about how the anti-virus monitoring in the Action Center works.

Generally, as long as there are no problems with the data in WMI about what anti-virus products are registered, then the monitoring works fine. It is entirely possible for that data to get messed up, especially when installing or uninstalling anti-virus or firewall software. Fortunately it's relatively easy to fix it when that happens (usually just reinstalling your security software fixes it). If there is a problem with the WMI data for which anti-virus is registered, then the Action Center will usually pester you with notifications to tell you that your installed security software is not working.

Share this post


Link to post
Share on other sites

The bottom line is that my EIS ran for several days without anything (apart from
the colour of the tiny systray icon) telling me that updates had ceased.  It's a
pity that your 'updates log' only seems to record the end of an update process,
rather than also that one is starting, because it's therefore impossible for you
or I to know if the problem was updates starting & failing, or not even being
scheduled.

If the Action Centre is meant to have told me, then either it or the interaction
between it and EIS isn't working.

Share this post


Link to post
Share on other sites

If you turn off the Guards in EIS, does the Action Center pop up some sort of notification? Turning off the Firewall is the quickest way to test this, as the notification should appear right away once the firewall is off.

Share this post


Link to post
Share on other sites

Trying firewall first: I unplugged the LAN cable, went to GUI's Protection ->
Firewall tab, and unticked 'Activate Firewall'; an Action Centre notification
did pop-up immediately, but it fades from view about 45 seconds later.  After
that to realise there's an issue one would need to spot the red cross symbol
next to the white notify flag systray icon.  The red cross & (if you go into
Action Centre) detailed message do both clear themselves as soon as the fw is
switched back on.

Trying guards: if I turn Surf Protection alone off/on, Action Centre doesn't
notice (at least not immediately).  If I turn File Guard alone off/on, Action
Centre doesn't immediately notice.  If I turn BB alone off/on, Action Centre
doesn't immediately notice.

If I turn pairs of guards off, Action Centre doesn't notice.

If I turn all three guards off, Action Centre does notice, immediately.  The
notification seems to stay visible for quite a while - more than a minute when
I wasn't using the machine, but it faded soon after once I started typing in
my notes.  I didn't click on it.  I tried that again; with no keyboard or mouse
activity the Action Centre notification stayed visible for > 2 minutes, but as
soon as I moved the mouse (over the EIS GUI where it had been since I unticked
the third guard) the AC notification faded away.  It did of course leave the
red cross/white flag icon visible.  And within AC, there were messages about
both anti-virus & anti-spyware apps.

After turning the three guards back on I tried again stopping each in turn; &
again no alert (or red-cross etc) from any single one of them.  If I stopped
all three, turning any single one back on banishes the AC notification & both
the a/v and a/s messages within it.

My first test of the Firewall being turned off suggested that its notification
faded after 45 seconds, but I repeated this and - like the Guard ones - it fades
if you let it stay visible for a while, then move the mouse.

So if one is busy doing something else when the notification pops up, will one's
mouse movement banish it without you seeing it?  More or less, yes.  Turning off
the firewall and moving the mouse immediately fades to pop-up away within ten
seconds.

I think if one was engrossed in something else, one could miss that.

But apart form all this, even if the AC alerts are working ok, I don't really see
why EIS could not generate an alert that needs a positive action taken (ie a click
on a button) to dismiss it.

If a guard or the firewall is turned off by the user clicking something in the GUI,
maybe some users would be slightly annoyed at being told immediately that they'd
just turned something off.  Personally I'd rather see that, as a sort of confirmation
that the alerting mechanism was working.  I certainly would want to see it if some
feature turns itself off.  Updates-wise, I would like to see an alert as soon as
the period since the last successful update exceeds some threshhold.

Better than that would be a recurring reminder that something is off or has not worked
recently.  Perhaps within that alert there could be a configurable value for how soon
the next alert might be generated - that might satisfy anyone who did not want to see
recurring alerts, and might be a good reason to display such an alert even after a
user manually turns something off.  I presume EIS has its own internal scheduler, since
you don't seem to use Windows' task scheduler, so it should be easy to set up recurring
checks.

Of course, if the problem with no updates for days is actually because your scheduler
hasn't triggered anything for days, that won't help much.

Would you at least consider adding a log entry when you start an update?  Then at
least it would be easier to see if no updates happening was a scheduler issue.
 

Share this post


Link to post
Share on other sites

It's normal for those Action Center notifications to stay on the screen until there is some sort of keyboard or mouse activity, and then start to fade away. There is supposed to be information at this link (lots of ads) on how to change the timeout so that they stay on the screen longer, or disappear faster.

We no longer have notifications that require user interaction due to complaints about them. Even the reboot notification for updates gets a lot of complaints, and we have to try to minimize the amount of notifications that people see. Also, since Windows already has this feature, and people expect a consistent form of notification about anti-virus status, we use the built-in Windows system.

Our update logs already show the start/end time of each update. If an update fails for any reason, then it should be reflected in the logs.

Share this post


Link to post
Share on other sites

> changing notification timeout

I don't think those options (Control Panel - Ease of Access - Using computer without a
display - Adjust time limits - How long should Windows notifications stay open) will be
relevant (a) because I'm not using the machine without a display, but also (b) because
they were set to the default of 5 seconds and the pop-ups already stay visible for much
longer than that (in the absence of mouse activity).


> We no longer have notifications ...

People must be mad, then.  It's not your fault as a software vendor if the OS does not
allow you to change certain elements of the OS without a reboot.  (It's something I'd
have thought MS would pay more attention to, since it's impossible for businesses to
run continuously available systems if they keep needing reboots.)  That aside, users
who complain about alerts ought to be able to discriminate between annoying things
that maybe can wait, and those that any sane user would want to know immediately.


> Our update logs already show the start/end time of each update. If an update fails
> for any reason, then it should be reflected in the logs.

I think that's not the case.  I think that probably your log records showing each
update are only written to the log when an update completes successfully.  Maybe
there's some entries for partial failures.  But they don't have entries describing
that start of an attempted update, OR your internal scheduler is not starting them
when it should.  Do you think if my EIS had shown umpteen started updates for the
"No updates in three days" period I'd have raised this ticket?

Nevertheless, looking back at what I wrote above I see that I described the lack of
update activity in the log, but didn't show you a picture, so here it is.  Note no
log entries at all in the period 7-9 April.
 

post-25439-0-58268200-1461137411_thumb.jpg
Download Image

Share this post


Link to post
Share on other sites

It may not log an update attempt until update process has finished, but in the case of an update that is frozen you're still going to see evidence of that in the update logs since there will be gaps in the update log entries that you can't account for.

Share this post


Link to post
Share on other sites

> in the case of an update that is frozen you're still going to see evidence of that
> in the update logs since there will be gaps in the update log entries

Yes, if that's the cause.  But how do you know that your internal scheduler properly
scheduled successive attempts?

Does your automatic scheduler only schedule later attempts if the current one
completes ok?

I mean in my situation, was my system likely to have one stalled upgrade that prevented
the next 30+ being attempted, or did 30+ attempts start and get nowhere?  (This is why
I think it would be useful to see an attempt strating.)

And, if automatic attempts are stalled, why would a manual attempt succeed?  Does a
manual attempt clear any flags or anything before it starts that don't get cleared
when an automatic attempt starts?

Share this post


Link to post
Share on other sites

Yes, if that's the cause.  But how do you know that your internal scheduler properly scheduled successive attempts?

Does your automatic scheduler only schedule later attempts if the current one completes ok?

The update schedule is, by default, every 60 minutes from the point at which you log in to your computer (or at least from when you power it on). This may vary a bit in Windows 8.1 and Windows 10, since they don't stop all of the running services when they shut down or reboot (they keep some of the system in a running state in an image sort of like Hibernate mode does and then restore it when booting). If an update attempt is missed, then subsequent update attempts will not fail unless the original update attempt is still frozen. Only one attempt to check for updates can run at a time.

I mean in my situation, was my system likely to have one stalled upgrade that prevented the next 30+ being attempted, or did 30+ attempts start and get nowhere?  (This is why I think it would be useful to see an attempt strating.)

The only logs that would be able to tell us for certain would be debug logs, however if there are no update logs entries for a period of 30 hours then chances are an update froze and blocked any subsequent updates since it never finished.

And, if automatic attempts are stalled, why would a manual attempt succeed?  Does a manual attempt clear any flags or anything before it starts that don't get cleared when an automatic attempt starts?

If an update is in progress, then it would not be possible to manually check for updates. Doing so would just open the EIS window so you could see the progress of the current update.

Share this post


Link to post
Share on other sites

OK... your first & second answers make it clear that you think there was a stalled update
preventing any other automatic updates from starting.  But you then say that a manual
(check for) updates would be impossible - it would just show the current one's progress.

But right at the start of this discussion I told you that I triggered a manual update,
which worked immediately.  To me, that suggests that there wasn't a stalled update, but
instead a scheduling problem.

This is why I keep suggesting that a log entry saying that a scheduled update is about to
start, would be a good thing.

If stalled updates really do block other attempted updates from starting maybe your suite
needs deliberately to look for update processes that started - say - more than 3 hours ago,
and kill them.  And, if it did do that, LOG that it found such a problem and tried to fix
it.  Unless the developers start trying to find where the problems lie, I don't think this
will ever get fixed.

I've been an EMSI customer for quite a while, and I've read loads of threads which boil
down to updates not happening when people expected them to.
Constantly being told that 'debug logs' are needed to solve the problem just isn't good
enough. We all know that nearly no-one has debug logs active when problems occur.  I'm
tryin to suggest things that might help pin down where the problems are.

Share this post


Link to post
Share on other sites

OK... your first & second answers make it clear that you think there was a stalled update preventing any other automatic updates from starting.  But you then say that a manual (check for) updates would be impossible - it would just show the current one's progress.

But right at the start of this discussion I told you that I triggered a manual update, which worked immediately.  To me, that suggests that there wasn't a stalled update, but instead a scheduling problem.

If you could start an update while a previous update appeared to be frozen/stalled, then the previous update wasn't actually stalled and it may have just been a UI glitch.

This is why I keep suggesting that a log entry saying that a scheduled update is about to start, would be a good thing.

It would also double the number of rows in the update log table of the SQLite database, which would cut the number of updates that get logged in half. This is the sort of thing that we generally keep in debug logs rather than in regular logs.

If stalled updates really do block other attempted updates from starting maybe your suite needs deliberately to look for update processes that started - say - more than 3 hours ago, and kill them. ...

That wouldn't solve the problem, and the user would be in the same bad situation. No updates, and no clue why.

... Unless the developers start trying to find where the problems lie, I don't think this will ever get fixed.

... I've read loads of threads which boil down to updates not happening when people expected them to. Constantly being told that 'debug logs' are needed to solve the problem just isn't good enough. We all know that nearly no-one has debug logs active when problems occur. ...

Debug logs are the way that developers find out where a problem in the software is. Without them, they have no way to know why something isn't working as expected. They can't just go through millions of lines of code and hope they stumble upon the part of the code that is causing the problem, and just so happen to notice an issue with that code that they overlooked when they wrote it/updated it. The only time bugs get fixed without debug logs is when our QA team can reproduce the issue in their own testing.

... I'm tryin to suggest things that might help pin down where the problems are.

I understand that, but please try to keep in mind that we can't just start adding a bunch of stuff to the software hoping it fixes problems. We need to know why a problem is happening before we try to make changes to fix it, and while I know you're probably tired of hearing this, that brings us back to debug logs.

Obviously, if our management thinks that adding some of your suggestions is a good idea, then they will have our developers work on it.

Share this post


Link to post
Share on other sites

> If you could start an update while a previous update appeared to be frozen/stalled, then
> the previous update wasn't actually stalled and it may have just been a UI glitch.

A three-day failure to update its signatures, AND no decent alert to the user saying that
there was a problem is FAR MORE than a 'UI glitch'.  It's a serious fault.

I note that in another thread someone else recently complained that the tiny systray shield's
colour-change is just not adequate, especially for older eyes on high-res screens - as a way of
notifying the user of a serious issue.
[http://support.emsisoft.com/topic/20090-eam-shows-no-protection/]


> It would also double the number of rows in the update log table of the SQLite database, which
> would cut the number of updates that get logged in half.  This is the sort of thing that we
> generally keep in debug logs rather than in regular logs.

... which would be fine if anyone ever had debug logging on when this occurs.  Debug logs
are no good for things that users can't reproduce.  You must know that.


> [killing stalled updates] That wouldn't solve the problem, and the user would be in the same
> bad situation. No updates, and no clue why.

Not correct.  I see you snipped my suggestion that when such a 'kill' is done, it would be
logged.  So while, yes, it wouldn't fix the problem - but then no-one seems to understand
how to fix the problem - it would not the leave the user without any clue.  There would be
a log entry saying that the stalled update had been detected.  At least we'd then all know
that these presumed stalled updates were really happening.


> Debug logs are the way that developers find out where a problem in the software is. Without them,
> they have no way to know why something isn't working as expected. They can't just go through
> millions of lines of code and hope they stumble upon the part of the code that is causing the
> problem, and just so happen to notice an issue with that code that they overlooked when they
> wrote it/updated it. The only time bugs get fixed without debug logs is when our QA team can
> reproduce the issue in their own testing.

Then you have a fundamental design problem, don't you?  Debug logs are not "the way", they're
just one way of finding out why things don't work.  There needs to be a middle ground, where
when users never have debug logging on when a problem occurs, developers have to find another
way to collect basic info - maybe not enough to pin down exactly why something is going wrong,
but enough to /prove/ that it is.

I lead a programming team before illness forced me to stop work.  We occasionally had this sort
of problem, and fixed it with a basic trace that ran all the time in whichever specific part of
our product until the reported problem happened again.  We were lucky (compared with you) that our
customers were on a corporate network and so we were able to have our product send those small
log files to us automatically and we received and filtered them automatically until one showed
what we needed to know.  Obviously you can't, in these days of angst about apps that 'phone home',
have EIS send logs to you without the customers knowing, but it should be possible to create (if
you like) an extra log that records some small details about the start and stop of the update
processes.  If you're so concerned about its impact on the SQLite databases put it somewhere
else.  It has to be active all the time so that it's active when people hit the problem.  But for
goodness sake, do something about this problem.


> Obviously, if our management thinks that adding some of your suggestions is a good idea, then
> they will have our developers work on it.

Do your management know about any of my suggestions?

Share this post


Link to post
Share on other sites

I'm not really sure we're getting anywhere. The issue happened, then was resolved, and hasn't happened again. Under those circumstances it isn't possible to tell why it happened, or fix it.

As for debug logs, these are not a design defect. They work as we intend them to. User's can't have debugging information saved all the time due to performance and disk usage issues, so they need to have debugging off off until it's needed. There is some automatic debugging, but only in the case of crash reporting, and even that much causes some performance issues.

Share this post


Link to post
Share on other sites

> I'm not really sure we're getting anywhere. The issue happened, then was resolved, and hasn't
> happened again.

I agree we're not getting anywhere.  But I don't agree that the issue was resolved.  We have no
idea why /automatic/ updates failed to happen for three days, then a manual update worked.


> As for debug logs, these are not a design defect. ...

They're fine so far as they go, but the chicken-and-egg problem of needing logging on to find out
if there's a problem, but not having logs on until after you've seen a problem has no solution if
you're not willing to find a way around it.

I still think that there's doubt over whether your scheduler always starts update attempts when it
is meant to.  If you won't add a log record to say so, another option would be to create a empty
file in: %TEMP% with a name like:

    EIS update started at yyyymmdd hhmmss.log

and delete it again when an update process runs to completion.  I'm not suggesting it should go in
a2temp, because /if/ a user should end up with lots of those flag files, they would be much less
likely to find them if they were in \a2temp.  Whenever anyone complains about an updating problem
you could ask if any such files exist.

Share this post


Link to post
Share on other sites

Why not just check the timestamps on the files?

Also, as I mentioned before, the time and update starts and ends does get logged.

Share this post


Link to post
Share on other sites

> Why not just check the timestamps on the files?

 

Because they don't tell me that an update process /started/.

 

 

> Also, as I mentioned before, the time and update starts and ends does get logged.

 

If it includes the time that the process ends, that log record must be written at the end of the update.

In my example of three days with no updates occurring, there were no log records.  It is impossible to

tell whether umpteen update attempts started and got nowhere.  It's also (according to you) not possible

that a manual update would work (which it did) when automatic updates are stalled.  So there's a big mystery

about why the expected hourly updates did not happen.

Share this post


Link to post
Share on other sites

Because they don't tell me that an update process /started/.

If no files have been modified, then no update process has started. Something happened before the process could actually start.

If it includes the time that the process ends, that log record must be written at the end of the update.

A log can be started and then appended. Regardless, the logs available in the UI are not for debugging purposes. As I keep saying, that's what debug logs are for.

It's also (according to you) not possible that a manual update would work (which it did) when automatic updates are stalled.

In the case of the update process being frozen, yes. As I have mentioned before, I was told that that was not the case here.

None of this matters though, as we can't know anything without debug logs. Since you weren't able to collect them, and the issue has been resolved, that's essentially the end of it. All of the discussion above is pointless if the issue is no longer happening. If it does happen again, then debug logs would be great, and if it doesn't happen again then that's even better. ;)

Share this post


Link to post
Share on other sites

> If no files have been modified, then no update process has started

Is there a file that should be modified before the update process makes any contact
with your update servers?  That is, before any external part of the process has a
chance to stop an update from working?


> A log can be started and then appended.

Does that actually happen during an update process?  If so, why have I never seen
a 'we started but didn't finish' log record?


> ... debug logs. Since you weren't able to collect them ...

Are you saying the lack of debug logs is my fault?

Share this post


Link to post
Share on other sites

Is there a file that should be modified before the update process makes any contact with your update servers?  That is, before any external part of the process has a chance to stop an update from working?

a2settings.ini should at least be accessed, and I would believe updated as the update process starts. Granted that file can be modified for a number of other reasons.

Does that actually happen during an update process?  If so, why have I never seen a 'we started but didn't finish' log record?

I haven't tested to see if it does.

Are you saying the lack of debug logs is my fault?

No, I was taking the opportunity to again emphasis the fact that without debug logs there is nothing that can be done.

Share this post


Link to post
Share on other sites

OK, I'm going to stop pursuing this matter for now.  It does seem that there are several
changes made to some .ini files separate from the arrival of new signatures, and while
they might not tell me precisely what I want to know, they will provide clues if & when
I hit this problem again.

Moreover, once the creeping memory issue is solved, I intend to run with debug logging
on all the time.  My machine seems to have enough 'grunt' to be able to cope with that
alright, and so hopefully there'll be much more info available in future.

Share this post


Link to post
Share on other sites

Moreover, once the creeping memory issue is solved, I intend to run with debug logging on all the time.  My machine seems to have enough 'grunt' to be able to cope with that alright, and so hopefully there'll be much more info available in future.

Be sure to check disk usage periodically when you do that. Debug logs will eat up gigabytes of disk space rather quickly.

Share this post


Link to post
Share on other sites

> Debug logs will eat up gigabytes of disk space rather quickly.

Yes, of course.  Last time I ran with logging on for several days I was disappointed to
see that there was no automatic close/reopen (spin-off) of the logs, which would make it
easier to archive them (and throw-away older logs) automatically.

Is there any point in asking for such a feature?  If there is, please don't make the
spin-off happen at any exact hour boundary, and definitely not midnight, since there's
so many things on a computer that change/happen on such boundaries, and it'd be sad if
logging was never active at such critical times!  Ideally I'd rather see such a thing
implemented by an external command, so anyone who wanted to do it could send a 'spin'
command at times of their choosing.

In the absence of such a feature, I will pick a screen automation utility (I've used
none for real for many years) and try to write a script that will open the EIS support
window, turn off logging for a second or so, and then turn it back on.

Then I can adapt existing code (for other apps' logs) to archive the logs and delete
older ones on a sensible basis.  

Share this post


Link to post
Share on other sites

Last time I ran with logging on for several days I was disappointed to see that there was no automatic close/reopen (spin-off) of the logs, which would make it easier to archive them (and throw-away older logs) automatically.

Every time an executable exits it will start a new log the next time it runs. Since a2guard.exe, a2start.exe, and a2service.exe now run all the time you might not notice new logs being created (especially on Windows 8.1 where a2service.exe doesn't shut down when you restart the computer).

Share this post


Link to post
Share on other sites

New logs are created though (on W8.1) if you turn logging off & then on again, so provided
that continues to be the case an automation solution will achieve what I want.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.