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): sysklogd-1.4.1-26_EL3 How reproducible: Always 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 sharedscripts postrotate /bin/kill -HUP 491 2> /dev/null || true endscript } 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.
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, and # 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 : http://people.redhat.com/~jvdias/sysklogd/RHEL-3 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!
[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 install. 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 sysklogd-1.4.1-12.3 [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 { sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true endscript } [sjs298@linuxdev1 sjs298]$ sudo up2date -u sysklogd <snip> [sjs298@linuxdev1 sjs298]$ rpm -q sysklogd sysklogd-1.4.1-26_EL3 [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 { sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true endscript } 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.
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 sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true endscript } EOF And the backticks weren't escaped... D'OH. Sorry to be a bother!
No problem, it happens to the best of us :-)