This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 494179 - Pre and Post Logrotate Commands are Incorrect for boinc-client
Pre and Post Logrotate Commands are Incorrect for boinc-client
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: boinc-client (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Milos Jakubicek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-05 07:55 EDT by William Makowski
Modified: 2009-04-24 15:49 EDT (History)
3 users (show)

See Also:
Fixed In Version: 6.4.7-10.r17542svn.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-22 16:27:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Output from Cron (92 bytes, text/plain)
2009-04-11 07:57 EDT, William Makowski
no flags Details

  None (edit)
Description William Makowski 2009-04-05 07:55:49 EDT
Description of problem:
When logrotate executes for boinc-client the client is meant to be stopped while logs are being rotated and started afterward.  The client does not stop and restart with the current commands.  The prerotate and postrotate commands for this operation are set to /etc/init.d/boinc stop and /etc/init.d/boinc start.  They should be set to /etc/init.d/boinc-client stop and /etc/init.d/boinc-client start.

Version-Release number of selected component (if applicable):
boinc-client-6.4.7-8.r17542svn.fc10.i386

How reproducible:
Always

Steps to Reproduce:
1. Logs are rotated when cron.daily executes and logs meet rotation criteria.
  
Actual results:
Client continues running while logs are rotated.

Expected results:
Client should be stopped and started during rotation.

Additional info:
I would also recommend combining the rotation of boinc.log and boincerr.log into one operation using the sharedscripts option rather than separately.  Putting them together would be less disruptive and more efficient.  The client would only be stopped and started once rather than twice (once for each log).  I'm also of the opinion that keeping 2 months worth of logs is a bit excessive.  The default of 4 weeks should be sufficient for monitoring purposes.  Below is a proposed logrotate configuration for boinc-client.

/etc/logrotate.d/boinc-client
# Global Parameters

missingok
compress
delaycompress
notifempty
nomail

# Log Specific Parameters

# boinc.log and boincerr.log

/var/log/boinc.log /var/log/boincerr.log
{
        create 664 boinc boinc
        sharedscripts
        prerotate
          if [ -f /var/lock/subsys/boinc ]; then
            touch /var/run/boinc_was_running
            /etc/init.d/boinc-client stop
          fi
        endscript
        postrotate
          if [ -f /var/run/boinc_was_running ]; then
            rm /var/run/boinc_was_running
            /etc/init.d/boinc-client start
          fi
        endscript
}

## EOF ##
Comment 1 Milos Jakubicek 2009-04-06 11:38:31 EDT
Ops, another upstream relict, thanks for reporting.
Comment 2 Fedora Update System 2009-04-07 20:27:03 EDT
boinc-client-6.4.7-9.r17542svn.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/boinc-client-6.4.7-9.r17542svn.fc10
Comment 3 Fedora Update System 2009-04-07 20:31:19 EDT
boinc-client-6.4.7-8.r17542svn.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/boinc-client-6.4.7-8.r17542svn.fc9
Comment 4 Fedora Update System 2009-04-09 12:13:49 EDT
boinc-client-6.4.7-8.r17542svn.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update boinc-client'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3468
Comment 5 Fedora Update System 2009-04-09 12:14:55 EDT
boinc-client-6.4.7-9.r17542svn.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update boinc-client'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3476
Comment 6 William Makowski 2009-04-09 12:19:49 EDT
I upgraded to the latest version yesterday and had some interesting results.
After the upgrade it installed /etc/logrotate.d/boinc-client.rpmnew. This can be explained since I modified the original and %config(noreplace) is in the
spec file. I have a second installation that replaced the original file and did
not create an rpmnew or rpmsave since the original was untouched.  I don't feel this is an issue.

On the other hand, my boinc logs weren't suppose to rotate until April 11, but they did last night. I can't be certain, but I'm guessing that logrotate spotted the new config file and decided to run it. The other peculiar thing was that
boinc-client was logging to boinc.log-20090409 rather than boinc.log. This is
not desirable. I'm thinking it might be necessary to add a sleep or wait
command in the prerotate script so boinc-client has enough time to stop before
the log is rotated.

It looked like an easy fix, but I don't think this one is ready for release. 
I'll do some more testing and let you know the results. It may take a few days
to test completely.
Comment 7 Milos Jakubicek 2009-04-09 15:05:40 EDT
(In reply to comment #6)
> I upgraded to the latest version yesterday and had some interesting results.
> After the upgrade it installed /etc/logrotate.d/boinc-client.rpmnew. This can
> be explained since I modified the original and %config(noreplace) is in the
> spec file. I have a second installation that replaced the original file and did
> not create an rpmnew or rpmsave since the original was untouched.  I don't feel
> this is an issue.

Yes, this is completely correct.

> On the other hand, my boinc logs weren't suppose to rotate until April 11, but
> they did last night. I can't be certain, but I'm guessing that logrotate
> spotted the new config file and decided to run it.

That might be.

> The other peculiar thing was that 
> boinc-client was logging to boinc.log-20090409 rather than boinc.log. This is
> not desirable. I'm thinking it might be necessary to add a sleep or wait
> command in the prerotate script so boinc-client has enough time to stop before
> the log is rotated.

Well, are you sure boinc was logging to boinc-log-%{date} file? Otherwise, this is correct (there is "delaycompress" and "dateext" option used). Note that the "service boinc-client stop" command returns *after* boinc is really down, there is already a delay+checking in the init script.
Comment 8 William Makowski 2009-04-11 07:57:33 EDT
Created attachment 339177 [details]
Output from Cron

My bad, I found the problem.  There was another spot where we have boinc instead of boinc-client.  The test on line 33 should be if [ -f /var/lock/subsys/boinc-client ]; then.  I tried out the new criteria last night and it worked properly.  Another side effect when it works is that root gets a message from the cron daemon (see attachment).  Should be able to stop that by adding > /dev/null to lines 35 and 41.
Comment 9 William Makowski 2009-04-12 09:31:51 EDT
Checked this morning and the logs rotated again.  I was expecting the weekly global parameter from /etc/logrotate.conf to be used, but it looks like they are rotating daily.  Are you experiencing the same thing or is it just me?  I noticed that the configuration for other log files in /etc/logrotate.d do not use a global configuration area.  Instead they put everything within the braces under the log file name(s).  I'm going to run a few more tests with some dummy logs to get the configuration right.  The logrotate learning curve appears to be larger than I originally thought.
Comment 10 Milos Jakubicek 2009-04-12 17:39:21 EDT
(In reply to comment #8)
> Created an attachment (id=339177) [details]
> Output from Cron
> 
> My bad, I found the problem.  There was another spot where we have boinc
> instead of boinc-client.  The test on line 33 should be if [ -f
> /var/lock/subsys/boinc-client ]; then.

Yes, my fault, didn't notice that...thanks.

> I tried out the new criteria last night
> and it worked properly.  Another side effect when it works is that root gets a
> message from the cron daemon (see attachment).  Should be able to stop that by
> adding > /dev/null to lines 35 and 41.  

Of course.

Moreover, regarding the configuration, it has indeed wide side-effects for everything read after this lines (including other configuration files), the global section has to be moved into the log-specific.

Quoting from logrotate manpage:

"logrotate reads everything about the log files it should be handling from the series of configuration files specified on  the  command line. Each configuration file can set global options (local definitions override global ones, and later definitions override earlier ones)"
Comment 11 William Makowski 2009-04-13 09:48:41 EDT
(In reply to comment #10)
> Moreover, regarding the configuration, it has indeed wide side-effects for
> everything read after this lines (including other configuration files), the
> global section has to be moved into the log-specific.

Agreed.

> Quoting from logrotate manpage:
> 
> "logrotate reads everything about the log files it should be handling from the
> series of configuration files specified on  the  command line. Each
> configuration file can set global options (local definitions override global
> ones, and later definitions override earlier ones)"  

I saw this too.  I moved the global options under the log specific yesterday and it did not rotate last night.  This change will impact all of my logs, since default in /etc/logrotate.conf is nocompress and nodelaycompress among other things. My guess is that everything will sort itself out overtime.

However, the original config still doesn't explain why the logs rotated daily instead of weekly. The daily option was never set either globally or in the log specific config.  I don't see this as something to worry about as long as it continues to rotate weekly.
Comment 12 Milos Jakubicek 2009-04-14 11:38:51 EDT
Well I've just tested for the few days, the logs do not rotate daily for sure. I'll rebuild for F11 right now to catch the final freeze.
Comment 13 Fedora Update System 2009-04-15 14:00:57 EDT
boinc-client-6.4.7-10.r17542svn.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update boinc-client'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3476
Comment 14 Fedora Update System 2009-04-15 14:02:34 EDT
boinc-client-6.4.7-9.r17542svn.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update boinc-client'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3468
Comment 15 William Makowski 2009-04-22 10:31:58 EDT
I finished testing and everything is looking good.  The logs are rotating properly and boinc-client stops and starts as it should.  My comments have also been updated in Bodhi.
Comment 16 Fedora Update System 2009-04-22 16:27:32 EDT
boinc-client-6.4.7-9.r17542svn.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 17 Fedora Update System 2009-04-24 15:49:46 EDT
boinc-client-6.4.7-10.r17542svn.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.