no attempt to autoupdate...

jrmarino

Well-Known Member
#1
Hi -
I've got 3.0.1 installed on a Solaris 10 system. I had to put the configuration aside for a couple of weeks to deal with other things. Since I've come back, I've realized that 2 minor versions have been released since.

My litespeed install has been running the entire time, yet there has been no attempt to even check if there is another version available. The only two lines in the autoupdate/update.log are:
Code:
[2007-04-12 18:27:52] Checking for new release...
[2007-04-12 18:27:52] [OK] Package is uptodate.
I tried to run the update agent from the command line, and it scolded me not too! :)

I've restarted it server twice to see if a restart would check for an update. It's set for DAILY checks.

Any idea what's wrong?
 

jrmarino

Well-Known Member
#3
I have some additional information.

I'm in the process of installing version 3.1 on another server. I've noticed that it is check for updates each time I restart the server. The autoupdate log supports this as well as the error log.

Perhaps between 3.01 and 3.10 this problem was corrected along the way.

If so, how do I upgrade manually?
Can I get wget the file and run an upgrade script -- is that equivalent?
 

mistwang

LiteSpeed Staff
#4
Just run install.sh and select "upgrade", same result as doing it from web admin. Maybe the awstats problem was fixed as well.
 

jrmarino

Well-Known Member
#5
Ok, I successfully upgraded the server.

However, the first server is still not even attempting to check for updates. The awstats problem was also not fixed.

The first and second servers are identical in every way. Same make, model, operating system, and configuration. Kind of a mystery...
 

jrmarino

Well-Known Member
#6
I think I'm getting somewhere!

THe second server had the "auto restart = yes" which is wrong. I turned it off and now it no longer checks for updates.

Is it possible that auto restart and the update parameter are linked together? If so, should they be? It does not seem like it should be.
 
Last edited:

jrmarino

Well-Known Member
#7
That's definitely the problem.

As soon as I turned autorestart = yes on the first server, it checks for an update and created the awstats configuration (awstats works now).

Can you please explain why this autostart parameters affects these seemingly unrelated things?
 
Last edited:

mistwang

LiteSpeed Staff
#8
"Auto restart" should be "Yes" for most setup, it helps restoring the service immediately if one lshttpd crashes. To me, there is no down side of doing this.
 

mistwang

LiteSpeed Staff
#9
update checking and awstats update are done in the watchdog process, if "auto start" is set to "no", those steps probably is skipped.

Maybe we should remove this option from our web console, and let it on all the time.
 

jrmarino

Well-Known Member
#10
Solaris 10 does this natively with the SMF functionality, and I want Solaris to handle it. There's your downside, and that's a legitimate reason.

However, that statement still doesn't explain why "auto restart = no" breaks awstats and the auto update.
 

jrmarino

Well-Known Member
#11
update checking and awstats update are done in the watchdog process, if "auto start" is set to "no", those steps probably is skipped.

Maybe we should remove this option from our web console, and let it on all the time.
Please.
I really want to turn off auto restart. The awstats and autoupdate should be decoupled from auto restart.
 

mistwang

LiteSpeed Staff
#12
I am not familiar with Solaris 10 SMF function, but I think it is just a Process watch dog, which start another instance if the previous instance is dead.

Our "Auto Restart" is far superior than any third party watch dog implementation, as it simply fork a child process with everything has been loaded/configured, ready to serve incoming requests. It also can inspect the core dump file with gdb and send a bug report to administrator's emails.
 

jrmarino

Well-Known Member
#13
Trust me, that's not how Solaris SMF works and it is far more sophisticated that that. Right now there are two activities in conflict doing the same job, and I want Solaris to do it.
 

jrmarino

Well-Known Member
#14
although you are correct in that if the litespeed process dies unexpectedly, it will bring up a brand new process if it's possible to do so.
 

jrmarino

Well-Known Member
#15
By the way, your auto-restart has a weakness. What if the parent process is the one that dies? No more protection. (I'm assuming the children live on in that event)
 

jrmarino

Well-Known Member
#16
I'm wondering if these are actually in conflict. It may work that:
first line of defense is your watchdog
and if that crashes, solaris would attempt to bring back a whole new one.
 

mistwang

LiteSpeed Staff
#17
The watchdog process does not do much things after loading the configuration, rarely crash once started.

Yes, you can have SMF watch the watchdog process. That's what I am going to suggest as well.
 
#18
I hate to seem annoying... but you didn't seem to address the bug report he had, which was that:

When auto-restart is disabled, litespeed does not look for updates.


Sounds like someone internally confused auto-update and auto-restart, and so it checks the auto-restart config when going to auto-update.


Obviously, this post is from awhile ago, but I wanted to point it out in case it is still an issue. I found this because I'm having problems with my auto-update not seeing the latest update... I wish there was a 'check for update now' button in the web admin page...
 

mistwang

LiteSpeed Staff
#19
All those operations are performance by LSWS watchdog process, so "Auto Restart" must be set to on. Since we have a lot of feature depends on the watchdog process, 3.3.4 has been changed to always on, can not be disabled.
 
Top