Ok, never mind. Everything below is correct except for the solution. no matter how I get that SIGUSR1 sent to apache-ssl, it still fails the reload randomly - from the command line or from logrotate...
I guess I'll be trying apache+mod_ssl out of despiration. On Tue, May 06, 2003 at 10:33:34AM -0600 or thereabouts, David Wilk wrote: > Howdy folks, > > Well, I did some digging and found some answers. I'm posting my > solution here in the event that others might find it useful. > > first of all, there's a bug in woody's logrotate package. Logrotate > will (might?) issue the postrotate command from any logrotate config (be > it daily, weekly or monthly) on a daily basis. So, if you only expect > apache-ssl to get restarted (apache-sslctl restart or > /etc/init.d/apache-ssl restart) monthly with your monthly logrotate > config, think again. it's probably happening every night. > > Second, I figured out that although the debian apache-ssl script > (/etc/init.d/apache-ssl) would cause apache-ssl to choke on a reload, > using 'apache-sslctl graceful' which has the same effect of sending a > SIGUSR1 to the apache-ssl parent process does not appear to have the > same problem. So far I've gone through several weeks of daily > apache-sslctl graceful's and one monthly logrotate without a single > problem with apache-ssl. so, to be clear, all I did was replace > /etc/init.d/apache-ssl reload with /usr/sbin/apache-sslctl graceful in > the postrotate command in my logrotate config for apache-ssl. > > I haven't investigated exactly why this change works, but I know that it > does, most likely. I won't really be sure that it's trouble free until > it's been up for several months without incident, but after going down > every couple days, I feel like a few weeks is a pretty good indication > that the problem has been resolved. > > hope someone finds this useful. > > Dave > > > On Wed, Apr 16, 2003 at 11:56:45AM -0600 or thereabouts, David Wilk wrote: > > Hello all, > > > > I think I have found that an /etc/init.d/apache-ssl restart is the only > > way to properly restart apache-ssl after a logrotation. However, I've > > had apache-ssl die two days in a row, and the culprit appears to be some > > process that is sending apache-ssl a SIGUSR1 (what apache-ssl reload or > > httpsdctl graceful issues). > > > > Here's the log: > > > > [Mon Apr 14 03:00:18 2003] [notice] SIGUSR1 received. Doing graceful > > restart > > [Mon Apr 14 03:00:18 2003] /usr/lib/apache-ssl/gcache started > > [Mon Apr 14 03:00:19 2003] [error] (2)No such file or directory: > > mod_mime_magic: ca > > n't read magic file /etc/apache-ssl/share/magic > > [Mon Apr 14 03:00:19 2003] [notice] Apache/1.3.26 Ben-SSL/1.48 (Unix) > > Debian GNU/Li > > nux PHP/4.1.2 mod_perl/1.26 configured -- resuming normal operations > > [Mon Apr 14 03:00:19 2003] [notice] suEXEC mechanism enabled (wrapper: > > /usr/lib/apa > > che-ssl/suexec) > > [Mon Apr 14 03:00:19 2003] [notice] Accept mutex: sysvsem (Default: > > sysvsem) > > > > the problem is I don't know what could possibly be issueing this SIGUSR1 > > signal to apache-ssl every morning at the exact same time that cron runs > > /etc/cron.daily. I've checked all my cron jobs and can't seem to find > > the culprit. > > > > if anyone has any ideas, I'd be grateful. > > > > thanks, > > Dave > > -- > > ******************************* > > David Wilk > > System Administrator > > Community Internet Access, Inc. > > [EMAIL PROTECTED] > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > -- > ******************************* > David Wilk > System Administrator > Community Internet Access, Inc. > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- ******************************* David Wilk System Administrator Community Internet Access, Inc. [EMAIL PROTECTED]
