I have the following error in syslog (and a dead httpd server) under salck64-13.0 after upgrading http-2.2.21 today:

I reverted to the previous version (2.2.20) with a great panic . I have no time now to examine the problem, but be warned...

Please check/verify this.
If you have such a system and have a succesfull upgrade please answer to this thread, and I will check it again, but be prepared to be able revert this patch.

Sorry if it is a false alarm but I think it's better to say a warning than leave other systems to fail.

Please note that this is not a spelling syntax error in httpd.conf, this is an error in the mod_negotiation module.


fdeak

I had this on 13.37 (32).

I didn't see that error but I didn't check syslog.

I restarted httpd again and it 'seemed' to be ok. I'll keep an eye on it though.

I've just restarted my system after the latest upgrades and my apache server won't start - same problem with mod_negotiation.so. This is on a Slackware64 13.37 system. I don't have a copy of the previous update to
httpd-2.2.20-x86_64-1_slack13.37.txz or the time to investigate further so I've had to resort back to the original httpd-2.2.17-x86_64-3.txz. Not at all ideal but it'll do for now till things get looked into.

Hi,

A thousand pardons and I'm looking into this as soon as possible. Luckily OSUOSL is no longer blocked. BTW, it's not Slackware specific:

http://icesquare.com/wordpress/apach...n-freebsd-8-2/

Cheers,

Pat

4 members found this post helpful.

Thanks a lot for the prompt feedback.

Just a quick note: if you restart httpd twice it will run fine.
[#2 says the same, but I would like to be clear on this, because bgeddy reverted the patch, while a double restart is solves the problem, or at least it seems to be solve ]

1 members found this post helpful.

Thank you for posting that tip. I upgraded Apache today in a Slackware 13.1 server install and ran into the same problem. It complained about not being able to load mod_negotiation.so and pointed to the line in httpd.conf. My initial reaction was to turn this feature off, which allowed the server to start. What puzzled me was that I kept my old configuration file after looking at the differences, meaning that this was not a totally new module. After reading your post, I turned it back on, and restarted again. This time it was fine with the option. Apparently something about the patch causes a change that creates a temporary error.

Just curious here...

Did you stop httpd before the upgrade or did you upgrade while the server was still running?

I let it upgrade while it was running. Sometimes I will stop the process(es) before running the upgrade, but then I also anticipate that the script will automatically stop the process before changing files and then restart it after the changes. Perhaps I am spoiled from other distributions, but it would be best for the upgrade scripts to not make any assumptions and stop and start the process.

Do you think that this is the cause of this problem?

But by thinking it's ok to stop and start the processes the script would be making assumptions.

That's one of the fundamental differences between Slackware and other distros. The Slackware wisdom is that it's best to leave those sorts of decisions to the humans. This may occasionally catch someone out when they're not paying attention, but on the whole I believe it's for the best.

I'm not stopped it, but I never stopped apache before for an upgrade, and it was ok until this patch.

fdeak

This problem appears to be somewhat common and distribution agnostic and I am really starting to wonder if this was the cause of the problem. Something to note for the future and a potential 'wrinkle' to complicate using the text base slackpkg tool, which tells you what upgrades are available and performs the operation(s) on your behalf.

This httpd update did not cause issues here (13.37 x86_64). I look at which updates there are (mailing list, changelog, slackpkg dialog). Stop services pertaining to the updates, apply updates, start services. Web server is functional. Nothing in systemlog, dmesg, httpd/error_log ....

You wouldn't try to keep firefox open while upgrading it would you (kind of hard to do that if you follow the book )

For server activities often a live upgrade is the preferred method...for example, when upgrading ssh remotely, restarting sshd still hangs onto existing connections. Obviously stopping the service before the upgrade is not possible. For other services perhaps the same situation does not apply but certainly any downtime for a web server should be minimized and upgrading over the existing installation and restarting the service has been a fine solution in the past.

It should be noted that I did not get bitten by this but the above still stands, and I don't think a live upgrade is as silly as some are making it out to be.

1 members found this post helpful.

The downtime involved in stop, update, start, is less than - apply update, restart, WTF!!!! why didn't it work!!!
An ounce of prevention is worth a pound of cure.