Bug 182605
Summary: | sysklogd - the post installation script should only be executed during installation | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jose Pedro Oliveira <jose.p.oliveira.oss> | ||||
Component: | sysklogd | Assignee: | Peter Vrabec <pvrabec> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | mitr, notting | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-02-07 13:14:13 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Jose Pedro Oliveira
2006-02-23 17:10:13 UTC
Created attachment 125115 [details]
sysklogd.spec patch - run %post script only during installation
OK, this bug is now fixed with sysklogd-1.4.1-36 - 'chkconfig --add' now only done if '$1 -eq 1'. How is this 'stopping the other syslog daemons'? Bill Nottingham, You are right: the syslog-ng daemon wasn't being stopped by some side effect of the post script. I think I finally understood the strange behaviour I having regarding the syslog-ng and sysklogd packages. The problem is caused by syslog-ng using the same pid file as sysklogd in order to be able to have its log files rotated. Having the same pidfile causes side effects when the service command is being used in the sysklogd preun script. Whenever an rpm -e sysklogd is executed, syslog-ng is stopped (if active). Argh... jpo Regarding the patch in comment #1: The patch still avoids having both syslog daemons being registered as active in the same run-levels: * FC5 test system with only sysklogd installed $ chkconfig --list | grep ^syslog syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off * yum install syslog-ng (from Extras) * chkconfig --level 2345 syslog-ng on * chkconfig --del syslog * service syslog stop * service syslog-ng start * ... * upgrade sysklogd * chkconfig --list | grep ^syslog syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off syslog-ng 0:off 1:off 2:on 3:on 4:on 5:on 6:off Note: I know that the correct way to disable syslog should have been "service syslog off" instead of "service --del syslog". Note2: It fails to protect the same problem if someone removes then re-installs sysklogd ( rpm -e sysklogd ; yum install sysklogd ). jpo Yes, to disable you need to use 'off', not --del. Outside of that, you may have been seeing bug 182729. As for using the same pid file, I suspect that perhaps separate pidfiles would make sense? Bill Nottingham, pidfiles and logrotate config files ----------------------------------- In the past I have tried to do that but I have had some problems. Some of the goals I (we) have tried to achieve during the syslog-ng packaging were: * being able to install syslog-ng side-by-side with sysklogd (without using alternatives) * duplicate the sysklogd logging configuration One of the major problems was the logrotate script as logrotate can't handle duplicate log files (if one log file is mentioned in two diferent logrotate files it just aborts execution). At the time Jeremy suggested dropping all the triggers I had in the specfile and shipping the same logrotate file as shipped in sysklogd (same MD5 digest -> no rpm file conflict). Shipping the same logrotate file required using the same pidfile. I will have to rethink the syslog-ng packaging. Maybe change logrotate to allow duplicate entries? Suggestions are welcome on how to handle core daemons replacements. jpo References: * One of the mailing list threads about syslog-ng review Re: Review request: syslog-ng (syslog replacement daemon) https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00258.html Which part of the preun stops syslog-ng? killproc klogd? killproc syslogd? I'm not seeing how that relates to logrotate, actually. (In reply to comment #8) > Which part of the preun stops syslog-ng? killproc klogd? killproc syslogd? "killproc syslogd" is killing syslog-ng. The output of "ps aux | grep syslog" just before "killproc syslogd" is: --- root 5607 0.0 0.1 1828 520 ? Ss 20:27 0:00 /sbin/syslog-ng -p /var/run/syslogd.pid root 5631 0.0 0.2 4360 1060 pts/1 S+ 20:28 0:00 /bin/sh /sbin/service syslog stop root 5634 0.0 0.2 4540 1372 pts/1 S+ 20:28 0:00 /bin/bash /etc/init.d/syslog stop --- OK, so, the pid file name is trusted over the path of the daemon. Not sure if that's fixable without breaking compatibility. Bill, I think there is a missing test in killproc: pidof syslogd should fail (exit code 1). jpo A couple of echo statements /etc/init.d/functions: killproc added three echo statements ---------- ... echo "FUNCTIONS killproc 0: <$1> <$pid_file> <$killlevel> <$base> <$pid>" # Find pid. __pids_var_run "$1" "$pid_file" echo "FUNCTIONS killproc 1: <$1> <$pid_file> <$killlevel> <$base> <$pid>" if [ -z "$pid_file" -a -z "$pid" ]; then pid="$(__pids_pidof "$1")" fi echo "FUNCTIONS killproc 2: <$1> <$pid_file> <$killlevel> <$base> <$pid>" ... ---------- Removing sysklogd (rpm -e) with syslog-ng running Output ---------- Shutting down kernel logger: FUNCTIONS killproc 0: <klogd> <> <> <klogd> <> FUNCTIONS killproc 1: <klogd> <> <> <klogd> <> FUNCTIONS killproc 2: <klogd> <> <> <klogd> <> [FAILED] Shutting down system logger: FUNCTIONS killproc 0: <syslogd> <> <> <syslogd> <> FUNCTIONS killproc 1: <syslogd> <> <> <syslogd> < 6475> FUNCTIONS killproc 2: <syslogd> <> <> <syslogd> < 6475> [ OK ] ---------- __pids_pidof is only called for klogd. It's skipped for syslogd as $pid is a non-zero string. Would it be possible to check it if $pid matches the result of "pidof syslogd"? LSB seems to require using the PID in the specified file as is, without further checks; of course we can have a special LSB mode in killproc to avoid this requirement. Checking the process name would currently break at least dbus, hal, sm-client (only from what is currently running on my laptop). If necessary, this is one way to check that a specified process is from the correct command (which is more fine-grained than just "a process with the correct command exists"): awk '$1 == "Name:" && $2 == "syslogd" { found = 1 } END { exit (found ? 0 : 1); }' < /proc/$pid_from_pid_file/status I'm leaning towards letting the syslog{d,-ng} init scripts handle this special case, although extending init.d/functions is of course possible. Jason, I don't think the patch from comment #2 was applied correctly. The %post script lines ------ for n in /var/log/{messages,secure,maillog,spooler} do [ -f $n ] && continue touch $n chmod 600 $n done ------ are now part of the %postun script! jpo Could someone read the previous comment. I think this may be problematic for first time sysklogd installations. Does sysklogd create all the log files with the correct file permissions if they don't exist? jpo The %postun is wrong, yes. The files do eventually get created with the right umask, due to the umask set in the syslog init script. fixed in sysklogd-1.4.1-46.fc7. testing "-f /var/lock/subsys/syslog" before running "service syslog stop". |