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: sysklogdAssignee: Peter Vrabec <pvrabec>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: 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 Flags
sysklogd.spec patch - run %post script only during installation none

Description Jose Pedro Oliveira 2006-02-23 17:10:13 UTC
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):
sysklogd-1.4.1-34.2.src.rpm

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 17:12:21 UTC
Created attachment 125115 [details]
sysklogd.spec patch - run %post script only during installation

Comment 2 Jason Vas Dias 2006-02-23 17:43:43 UTC
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 21:53:27 UTC
How is this 'stopping the other syslog daemons'?

Comment 4 Jose Pedro Oliveira 2006-02-27 17:13:25 UTC
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


Comment 5 Jose Pedro Oliveira 2006-02-27 17:26:32 UTC
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

Comment 6 Bill Nottingham 2006-02-27 19:16:07 UTC
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 20:06:01 UTC
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


Comment 8 Bill Nottingham 2006-02-27 20:09:21 UTC
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 20:30:56 UTC
(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 20:38:36 UTC
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 20:50:02 UTC
Bill,

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

jpo


Comment 12 Jose Pedro Oliveira 2006-02-27 21:33:08 UTC
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"?  



Comment 13 Miloslav Trmač 2006-02-27 21:38:51 UTC
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.

Comment 14 Jose Pedro Oliveira 2006-03-07 01:55:34 UTC
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

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

Comment 16 Bill Nottingham 2006-03-15 16:13:23 UTC
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 13:14:13 UTC
fixed in sysklogd-1.4.1-46.fc7.

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