Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159629 - sysklogd writes erroneous logrotate.d file, causing HUP to be sent to random process.
Summary: sysklogd writes erroneous logrotate.d file, causing HUP to be sent to random ...
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sysklogd
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-06 10:33 UTC by Sam Sharpe
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-06 16:05:37 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Sam Sharpe 2005-06-06 10:33:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.8) Gecko/20050512 Red Hat/1.0.4-1.4.1 Firefox/1.0.4

Description of problem:
The logrotate file for sysklogd /etc/logrotate.d/syslog is written by the RPM to include the PID of syslog at the actual time the RPM is installed rather than the generic `cat /var/run/`

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install updated sysklogd
2. Wait for logrotate to run


Actual Results:  3. all your syslog messages stay logging to <file>.1 even though <file> ha been created

Expected Results:  syslog should have been HUP'ed and will start writing to <file> instead of <file>.1

Additional info:

[root@hart logrotate.d]# cat /etc/logrotate.d/syslog
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
    create 0664 root root
        /bin/kill -HUP 491 2> /dev/null || true

The file in the sysklogd tarball has:
        /bin/kill -HUP `cat /var/run/ 2> /dev/null` 2> /dev/null || true

And all the RPM does is:
install -m644 redhat/syslog.log $RPM_BUILD_ROOT/etc/logrotate.d/syslog

so your guess is as good as mine why it somehow ends up with the the output of the `` rather than the actual command itself.

Oh yeah, and this happens on all our systems - including new builds so it's definitely not just me.

Comment 1 Jason Vas Dias 2005-06-06 14:41:08 UTC
This is very strange - I've just tested both upgrade and clean install
of sysklogd and cannot duplicate this problem.

Please check your /usr/bin/install program - it should be a binary,
# rpm --verify coreutils
should produce no output - if it does, reinstall the default Red Hat
RHEL-3-U5 coreutils-4.5.3-26 package.

If coreutils checks out OK:
How was the sysklogd RPM upgraded - through RHN ? Was it a clean
install or upgrade ? If upgrade, what release were you upgrading
from, and what rhel-3 flavour / architecture - ie. 
(AS,ES,WS,Desktop) / ( i386, ia64, x86_64, ppc, ppc64, s390, s390x) ?

Please test manual upgrade on one of the affected systems - obtain
the sysklogd-1.4.1-26_EL3 rpm, eg. from :
and then 
   # rpm -Uvh force sysklogd-1.4.1-26_EL3.${arch}.rpm
   ( check /etc/logrotate.d/syslog )
   # rpm -e --nodeps sysklogd
   # rpm -ivh sysklogd-1.4.1-26_EL3.${arch}.rpm
   ( check /etc/logrotate.d/syslog )
Repeating these steps on my i386 rhel-3-AS system never fails to 
install a correct logrotate.d/syslog file. If it produces a 
corrupt logrotate file for you, please do:
   # rpm -e --nodeps sysklogd 
   # rpm -ivvv sysklogd-1.4.1-26_EL3.${arch}.rpm 2>&1 | 
     tee /tmp/sysklogd.install.log
and append the /tmp/sysklogd.install.log to this bug report.
Thank you!

Comment 2 Sam Sharpe 2005-06-06 15:27:50 UTC
[root@hart root]# rpm --verify coreutils
[root@hart root]#

That particular machine (hart) is up2date'd weekly via a cronjob. The machine we
actually noticed it on first was a completely new build nfsiso over the network
from EL3-u5 images, which was immediately updated in the %post section of the

All of our server machines run EL3 of some update, but I've checked with a
colleague in another section who also runs an EL3 box, and he has no such error.
It's really weird... I'm not doing any alteration to logrotate scripts in my
post-install (although I do manipulate quite a lot of configs)

However, I'm going to try something:

[sjs298@linuxdev1 sjs298]$ rpm -q sysklogd
[sjs298@linuxdev1 sjs298]$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon Update 4)

[sjs298@linuxdev1 sjs298]$ cat /etc/logrotate.d/syslog
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler
/var/log/boot.log /var/log/cron {
        /bin/kill -HUP `cat /var/run/ 2> /dev/null` 2> /dev/null || true

[sjs298@linuxdev1 sjs298]$ sudo up2date -u sysklogd
[sjs298@linuxdev1 sjs298]$ rpm -q sysklogd
[sjs298@linuxdev1 sjs298]$ cat /etc/logrotate.d/syslog
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler
/var/log/boot.log /var/log/cron {
        /bin/kill -HUP `cat /var/run/ 2> /dev/null` 2> /dev/null || true

Which is absolutely totally fine. Very Very Very weird.

I'm just going to rebuild a complete automated AS3 install as our new boxes
would be, but without running up2date in the post install section - then I'll
have a look at what happens to that file before and after an update and see what
happens... I'll tell you more later.

Comment 3 Sam Sharpe 2005-06-06 15:32:42 UTC
Please close this bug with the resolution: IAMAMORON

I'm installing BigBrother client, which needs a mode of 664 on the syslog files.
 The moral of this story is don't copy other people's scripts without testing
them yourself.

What I was doing is this:

# fix the problems with syslog files
chmod 0664 /var/log/messages
cat <<EOF > /etc/logrotate.d/syslog
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler
/var/log/boot.log /var/log/cron {
    create 0664 root root
        /bin/kill -HUP `cat /var/run/ 2> /dev/null` 2> /dev/null || true

And the backticks weren't escaped... D'OH.

Sorry to be a bother!

Comment 4 Jason Vas Dias 2005-06-06 16:05:37 UTC
No problem, it happens to the best of us :-) 

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