Bug 159629 - sysklogd writes erroneous logrotate.d file, causing HUP to be sent to random process.
sysklogd writes erroneous logrotate.d file, causing HUP to be sent to random ...
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sysklogd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-06-06 06:33 EDT by Sam Sharpe
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-06 12:05:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sam Sharpe 2005-06-06 06:33:17 EDT
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/syslog.pid`

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/syslogd.pid 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 10:41:08 EDT
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 11:27:50 EDT
[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/syslogd.pid 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/syslogd.pid 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 11:32:42 EDT
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/syslogd.pid 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 12:05:37 EDT
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.