Looking at some of the stuff in /etc/logrotate.d, I see entries like this in some of the configuration files:
postrotate /sbin/service privoxy reload 2> /dev/null || true
From the commandline, that doesn't work:
# /sbin/service privoxy reload 2> /dev/null || true Usage: /etc/init.d/privoxy {start|stop|restart}
Changing reload to restart does work:
]# /sbin/service privoxy restart 2> /dev/null || true Stopping Privoxy, OK. Starting Privoxy, OK.
I find "reload" in the httpd logrotate file as well:
postrotate /sbin/service httpd reload > /dev/null 2>/dev/null || true
What am I failing to understand?
On Mon, Dec 27, 2010, Frank Cox wrote:
Looking at some of the stuff in /etc/logrotate.d, I see entries like this in some of the configuration files:
postrotate /sbin/service privoxy reload 2> /dev/null || true
From the commandline, that doesn't work:
# /sbin/service privoxy reload 2> /dev/null || true Usage: /etc/init.d/privoxy {start|stop|restart}
Changing reload to restart does work:
]# /sbin/service privoxy restart 2> /dev/null || true Stopping Privoxy, OK. Starting Privoxy, OK.
I find "reload" in the httpd logrotate file as well:
postrotate /sbin/service httpd reload > /dev/null 2>/dev/null || true
What am I failing to understand?
The reload command usually does a ``kill -HUP'' on the running process to get it to reload its configuration files whild restart will kill the running process and restart it which, of course, causes it to read the configuration. The reload command should cause the running process to close and reopen log files.
Unfortunately, not all programs properly handle the HUP command, either not reading the configuration, not properly handling log files, or both. Thus the restart should always work while reload may not depending on the application.
Bill
On Mon, 27 Dec 2010 10:40:48 -0800 Bill Campbell wrote:
The reload command usually does a ``kill -HUP'' on the running process to get it to reload its configuration files whild restart will kill the running process and restart it which, of course, causes it to read the configuration. The reload command should cause the running process to close and reopen log files.
"reload" doesn't appear to be recognized as a command line option with the /sbin/service command, as seen here:
# /sbin/service privoxy reload 2> /dev/null || true Usage: /etc/init.d/privoxy {start|stop|restart}
Does that vary between what /sbin/service is trying to reload?
Unfortunately, not all programs properly handle the HUP command, either not reading the configuration, not properly handling log files, or both. Thus the restart should always work while reload may not depending on the application.
This came up because I'm trying to figure out why privoxy crashes overnight sometimes (and not at other times of the day). It occurred to me that perhaps some of the jiggery-pokery involved in the logrotate business might be at the root of the issue.
On Mon, Dec 27, 2010 at 2:24 PM, Frank Cox theatre@sasktel.net wrote:
On Mon, 27 Dec 2010 10:40:48 -0800 Bill Campbell wrote:
The reload command usually does a ``kill -HUP'' on the running process to get it to reload its configuration files whild restart will kill the running process and restart it which, of course, causes it to read the configuration. The reload command should cause the running process to close and reopen log files.
"reload" doesn't appear to be recognized as a command line option with the /sbin/service command, as seen here:
# /sbin/service privoxy reload 2> /dev/null || true Usage: /etc/init.d/privoxy {start|stop|restart}
Does that vary between what /sbin/service is trying to reload?
*/sbin/service* is working fine. It's just a shell script that finds and passes arguments to the init scripts in /etc/rc.d/init.d/. (/etc/init.d is a symlink to /etc/rc.d/init.d: don't be confused by that.)
If the init script supports reload, then service will successfully pass the argument to it. If it doesn't support reload, such as the "privoxy" script in this case does not, then you'll need to use start, stop, or restart.
Some init scrupts have much more useful useful options, such as "configtest" from some Apache init scripts.
Unfortunately, not all programs properly handle the HUP command, either not reading the configuration, not properly handling log files, or both. Thus the restart should always work while reload may not depending on the application.
This came up because I'm trying to figure out why privoxy crashes overnight sometimes (and not at other times of the day). It occurred to me that perhaps some of the jiggery-pokery involved in the logrotate business might be at the root of the issue.
-- MELVILLE THEATRE ~ Melville Sask ~ www.melvilletheatre.com www.creekfm.com - FIFTY THOUSAND WATTS of POW WOW POWER! _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 27 Dec 2010 16:31:29 -0500 Nico Kadel-Garcia wrote:
*/sbin/service* is working fine. It's just a shell script that finds and passes arguments to the init scripts in /etc/rc.d/init.d/. (/etc/init.d is a symlink to /etc/rc.d/init.d: don't be confused by that.)
If the init script supports reload, then service will successfully pass the argument to it. If it doesn't support reload, such as the "privoxy" script in this case does not, then you'll need to use start, stop, or restart.
Ah... gotcha! I've learned something today....
On Mon, Dec 27, 2010, Frank Cox wrote:
On Mon, 27 Dec 2010 16:31:29 -0500 Nico Kadel-Garcia wrote:
*/sbin/service* is working fine. It's just a shell script that finds and passes arguments to the init scripts in /etc/rc.d/init.d/. (/etc/init.d is a symlink to /etc/rc.d/init.d: don't be confused by that.)
If the init script supports reload, then service will successfully pass the argument to it. If it doesn't support reload, such as the "privoxy" script in this case does not, then you'll need to use start, stop, or restart.
Ah... gotcha! I've learned something today....
There are many options to logrotate that control this, and things like creating a new log file before reloading or restarting the service (e.g. at least some syslogd programs will not work unless their output log file(s) exist when they start.
The GNU shtool also provides log rotate functions which can be used in cron jobs and such.
Bill
On 12/27/2010 12:01 PM, Frank Cox wrote:
Looking at some of the stuff in /etc/logrotate.d, I see entries like this in some of the configuration files:
postrotate /sbin/service privoxy reload 2> /dev/null || true
From the commandline, that doesn't work:
# /sbin/service privoxy reload 2> /dev/null || true Usage: /etc/init.d/privoxy {start|stop|restart}
Changing reload to restart does work:
]# /sbin/service privoxy restart 2> /dev/null || true Stopping Privoxy, OK. Starting Privoxy, OK.
I find "reload" in the httpd logrotate file as well:
postrotate /sbin/service httpd reload> /dev/null 2>/dev/null || true
What am I failing to understand?
You're not failing to understand anything. The init.d/privoxy script you have is broken. While https://bugzilla.redhat.com/show_bug.cgi?id=597732 was reported against a different problem, the corrected initscript it contains should fix your problem as well.
It might be worthwhile to report a new bug against privoxy since the failure to do a reload after logrotate is a more serious problem than the one reported in #597732.
On 12/28/2010 10:13 AM, Robert Nichols wrote: [SNIP]
You're not failing to understand anything. The init.d/privoxy script you have is broken. While https://bugzilla.redhat.com/show_bug.cgi?id=597732 was reported against a different problem, the corrected initscript it contains should fix your problem as well.
It might be worthwhile to report a new bug against privoxy since the failure to do a reload after logrotate is a more serious problem than the one reported in #597732.
Forgot what mailing list I was reading. Sorry. Looks like the same problem as in the Fedora bugzilla, though.
On Tue, 28 Dec 2010 10:13:45 -0600 Robert Nichols wrote:
It might be worthwhile to report a new bug against privoxy since the failure to do a reload after logrotate is a more serious problem than the one reported in #597732.
This is privoxy rpm that I created myself by copying the spec file from a Fedora srpm and substituting the latest version (3.0.17) of privoxy.
The logrotate configuration file for privoxy disappeared in the latest version so I had to copy it in from an older version and haven't yet gotten around to figuring out how to integrate it into the rpm properly.
Since the rpm I'm using isn't "official" but rather is just something I've slapped together I don't think a bug report would be particularly useful.
I got tired of privoxy crashing and want to see if a substantially newer version will crash less.
The behaviour with system-config-services varies under Centos from what is contained in that bug report. Using the init file that came with the source tarball I see that system-config-services doesn't even try to report its status, but rather simply says "Usage: /etc/init.d/privoxy {start|stop| restart}" in the Status window.
On 12/28/2010 10:49 AM, Frank Cox wrote:
On Tue, 28 Dec 2010 10:13:45 -0600 Robert Nichols wrote:
It might be worthwhile to report a new bug against privoxy since the failure to do a reload after logrotate is a more serious problem than the one reported in #597732.
This is privoxy rpm that I created myself by copying the spec file from a Fedora srpm and substituting the latest version (3.0.17) of privoxy.
The logrotate configuration file for privoxy disappeared in the latest version so I had to copy it in from an older version and haven't yet gotten around to figuring out how to integrate it into the rpm properly.
Since the rpm I'm using isn't "official" but rather is just something I've slapped together I don't think a bug report would be particularly useful.
I got tired of privoxy crashing and want to see if a substantially newer version will crash less.
The behaviour with system-config-services varies under Centos from what is contained in that bug report. Using the init file that came with the source tarball I see that system-config-services doesn't even try to report its status, but rather simply says "Usage: /etc/init.d/privoxy {start|stop| restart}" in the Status window.
That's the problem that was reported in the Fedora bugzilla. What you've built is an RPM with a logrotate.d file that requests an action ("reload") that the init.d file does not support. It doesn't work, but the logrotate.d file is ignoring the error and discarding the error message. system-config-services is having a problem because the "status" action is not supported. If you were to substitute the more complete init.d file that was attached to that bug report, I believe that would take care of both the logrotate problem and the status report problem.