Bug 182605 - sysklogd - the post installation script should only be executed during installation
sysklogd - the post installation script should only be executed during instal...
Product: Fedora
Classification: Fedora
Component: sysklogd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-02-23 12:10 EST by Jose Pedro Oliveira
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-07 08:14:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sysklogd.spec patch - run %post script only during installation (534 bytes, patch)
2006-02-23 12:12 EST, Jose Pedro Oliveira
no flags Details | Diff

  None (edit)
Description Jose Pedro Oliveira 2006-02-23 12:10:13 EST
Description of problem:
Right now, the sysklogd post installation script is executed during
the package installation and upgrade (rpm -i/-F/-U). It should only be executed
during installation and not during an upgrade as it stops other syslog daemons
(e.g. syslog-ng).

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

Expected results:
Place the current post bash script inside an if statement
(full patch enclosed below).

Additional info:
This is somewaht related to #172885.
Comment 1 Jose Pedro Oliveira 2006-02-23 12:12:21 EST
Created attachment 125115 [details]
sysklogd.spec patch - run %post script only during installation
Comment 2 Jason Vas Dias 2006-02-23 12:43:43 EST
OK, this bug is now fixed with sysklogd-1.4.1-36 - 'chkconfig --add' now only
done if '$1 -eq 1'. 
Comment 3 Bill Nottingham 2006-02-24 16:53:27 EST
How is this 'stopping the other syslog daemons'?
Comment 4 Jose Pedro Oliveira 2006-02-27 12:13:25 EST
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... 

Comment 5 Jose Pedro Oliveira 2006-02-27 12:26:32 EST
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 ).

Comment 6 Bill Nottingham 2006-02-27 14:16:07 EST
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?
Comment 7 Jose Pedro Oliveira 2006-02-27 15:06:01 EST
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


* One of the mailing list threads about syslog-ng review
  Re: Review request: syslog-ng (syslog replacement daemon)
Comment 8 Bill Nottingham 2006-02-27 15:09:21 EST
Which part of the preun stops syslog-ng? killproc klogd? killproc syslogd?
I'm not seeing how that relates to logrotate, actually.
Comment 9 Jose Pedro Oliveira 2006-02-27 15:30:56 EST
(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

Comment 10 Bill Nottingham 2006-02-27 15:38:36 EST
OK, so, the pid file name is trusted over the path of the daemon. Not sure if
that's fixable without breaking compatibility.
Comment 11 Jose Pedro Oliveira 2006-02-27 15:50:02 EST

I think there is a missing test in killproc: pidof syslogd should fail (exit
code 1).

Comment 12 Jose Pedro Oliveira 2006-02-27 16:33:08 EST
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")"

echo "FUNCTIONS killproc 2: <$1> <$pid_file> <$killlevel> <$base> <$pid>"

Removing sysklogd (rpm -e) with syslog-ng running
Shutting down kernel logger:
FUNCTIONS killproc 0: <klogd> <> <> <klogd> <>
FUNCTIONS killproc 1: <klogd> <> <> <klogd> <>
FUNCTIONS killproc 2: <klogd> <> <> <klogd> <>
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"?  

Comment 13 Miloslav Trmač 2006-02-27 16:38:51 EST
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

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.
Comment 14 Jose Pedro Oliveira 2006-03-06 20:55:34 EST

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}
     [ -f $n ] && continue
     touch $n
     chmod 600 $n
are now part of the %postun script! 

Comment 15 Jose Pedro Oliveira 2006-03-15 05:06:10 EST
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?

Comment 16 Bill Nottingham 2006-03-15 11:13:23 EST
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.
Comment 17 Peter Vrabec 2007-02-07 08:14:13 EST
fixed in sysklogd-1.4.1-46.fc7.

testing "-f /var/lock/subsys/syslog" before running "service syslog stop".

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