package sysklogd (not installed) failed to install/upgrade: subprocess installed post-removal script returned error exit status 1

Please ignore the part about ttf-dejavu-extra and ttf-dejavu, that's bug #398660.

sysklogd fails on postrm during purge since it tries to delete the user syslog, but the replacement rsyslogd is logged in in as that user now.

D000002: fork/exec /var/lib/dpkg/info/sysklogd.postrm ( purge )
userdel: user syslog is currently logged in
/usr/sbin/deluser: `/usr/sbin/userdel syslog' returned error code 8. Exiting.
dpkg: error processing sysklogd (--purge):
subprocess installed post-removal script returned error exit status 1
Errors were encountered while processing:
sysklogd

maybe test for existence of rsyslog in post removal script?

if [ ! -f /etc/init.d/rsyslog ]
    then
        deluser --system --quiet syslog
fi

or suchlike

If you kill the process it should help. or restart

Happened to me when I did a Complete Removal, when it was located in the "Not Installed (Residual Config)" category from within Synaptic.

> maybe test for existence of rsyslog in post removal script?
>
>if [ ! -f /etc/init.d/rsyslog ]
> then
> deluser --system --quiet syslog
>fi

Actually, the user for the rsyslogd process is still syslog.

>Actually, the user for the rsyslogd process is still syslog.

thats the essence of the problem. thats why i thought it might be a good idea to test to make sure rsyslog isnt installed before attempting to remove user syslog, i'm sure there are better ways than that to check if sysklogd 'owns' the user syslog when purging but i dont know

Happened to me. I can not purge sysklogd after installing rsyslogd

This really needs to be fixed before Karmic is released, otherwise an awful lot of people are likely to run into this issue, now that rsyslogd replaces the two old log daemons.

why not just TRY to delete de syslog user, and, if it fails due to rsyslog logged in as syslog (userdel returns 8 in this case) then just ignore as it's not a problem.

The point is, the post-removal script should exit successfully if userdel returns 8.

It happened to me - with Intel, not AMD64. I can't remove sysklogd's residual config. I got exit status 1.

I strongly agree with Martin-Éric that this package needs a fix.

For those of you who can't wait, you can manually patch the /var/lib/dpkg/info/sysklogd.postrm script by commenting or removing the "deluser" command and then purge the package.

Thanks Arnaud!

I can wait, but I would have waited in vain, because the package was already removed, which means no updates for it...
So the remove completely script would never have been updated.

This package should be fixed for Jaunty first, otherwise upgraders will hit this problem.
For karmic, just do what Arnaud said.

Diego, I really like your approach of treating exit code 8 as success.

Do you think that you could produce a patch for the postrm maintainer scripts of both rsyslogd and sysklogd (the same problem happens when people try to migrate from other syslog substitutes to sysklogd)? If yes, then please attach them both to this bug report and I can point the right people to this bug to merge your patches.

Thanks!

Here is a patch against sysklogd for Jaunty. It works by removing the 'set -e' line in postrm so that this script does not exit on the first error.

Note that it is not bullet proof: if a non-patched Jaunty (or older) user upgrades to Karmic, this bug *will* trigger...

RFC: rsyslog should depend on an new, dummy, postrm-fixed, karmic-specific version of sysklogd. But how to get rid of this dummy sysklogd package then ?

Arnaud, thank you for your patch. Unfortunately, removing 'set -e' is out of the question, because it would make the package non-compliant with the packaging policy, which states that all maintainer scripts must exit upon error. Thus, the only desirable fix for this issue would be to make exit code 8 interpreted as success or, alternately, to make sysklogd not attempt to remove the group if another package uses it.

how about,

#! /bin/sh

set -e

if [ "$1" = "purge" ]
then
    ( userdel syslog
  ERR="$?"
  if [ "$ERR" -eq "8" ] ; then
   echo "Ignoring removal of logged in user syslog"
   exit 0
  else
   exit $ERR
  fi
 ) || false
 update-rc.d sysklogd remove >/dev/null
fi

Need to use userdel to catch only error 8, deluser only gives 0 or 1.
Note, this problem will also happen if purging rsyslog when sysklogd is running

removing residual got me here,
would second the need for this to
be fixed - too many people are
going to do the same thing
thanks

It's still good to use deluser. It's less lowlevel and supports flags like --system, which we want.

Here's a debdiff against Jaunty for an SRU. I'm not 100% clear on the necessity, though. Does sysklogd get purged during a normal install? I would have assumed just a normal remove.

The patch ignores return value 1 (which means either that the user is not a system user or that the user is still logged in).

Debdiffs for sysklog in Karmic and rsyslog in Karmic are coming. I nominated this bug for Jaunty, but I only wanted to nominate sysklogd, not rsyslog...

Dash it, I forgot to handle the case where deluser succeeds. :)

I added universe-sponsors for the karmic-sysklogd case. jaunty-sysklogd and karmic-rsyslog are in main.

Hi,

that's really a tough case, hence I subscribed both mvo (since it affects the uprade path) and slangasek (to have the release-manager on board).

The tricky part is that it's not 100% guaranteed that the deleted syslog user (which will then get readded later on) will have the same uid. These would lead us with a number of "orphaned" files in /var/log, which could be made readable to another (unwanted) user that happens to obtain the new uid.

Given that, I believe that the right thing to do is to just not delete the syslog user and to not assume that it's not present for the udpated package.

However I'd really like to hear a second opinion on this.

Cheers,
     Stefan.

Stefan, you're the voice of reason here. I don't know if my opinion counts as I'm not a Debian or Ubuntu developer, but I'd strongly recommend to never delete any accounts from a system. It may own files. It may be needed for audit. There may a backup somewhere with this account's uid. Whatever the case, once the account is created, it should at the most be disabled somehow, never deleted.

That is sensible now that you say it. When I adapted rsyslog to be unprivileged, I copied sysklogd's handling of the syslog user. Maybe it would be better to remove the deluser logic from both.

Yes, neither of these packages should be deleting the system user on purge. It's a bad idea in the general case, and is guaranteed to break things when more than one package is using the user. Even if rsyslogd were stopped at the time, that would just mean that the sysklogd purge succeeds at the expense of rsyslogd being able to start again later! (Note that rsyslogd is probably installed *before* sysklogd is purged.)

Also a sysklogd SRU to jaunty is insufficient because the same problem will affect users upgrading from hardy to karmic+1; as well as missing any users who happen to have not upgraded sysklogd before removing it. So I think the best approach is as follows:

- fix sysklogd postrm to not call deluser.
- fix rsyslog postrm to not call deluser.
- add a one-time hack to rsyslog postinst to call sed -e'/deluser/d' /var/lib/dpkg/info/rsyslog.postrm

Michael, is this something you'd like to work on? If not, I can cook this up quickly.

I tested your suggestion (sudo apt-get install rsyslog --purge) with a patched rsyslog to do what you suggested (with the caveat that it sed's sysklogd.postrm, not rsyslog.postrm; I think that was a typo on your part).

But apt-get purges sysklogd before running the postinst (or preinst) for rsyslog. So it's too late to hack a fix in by then.

One other option could be to do an SRU for every release. But as you say, that doesn't cover people that don't fully upgrade before doing a release upgrade.

Another option is to change rsyslog to use a different user than 'syslog'. But that seems not quite appropriate. Though it would fix this issue.

What about adding the sysklogd.postrm hack to update-manager? It has a quirk system for upgrading between releases, right?

On Tue, Sep 22, 2009 at 01:04:35AM -0000, Michael Terry wrote:
> But apt-get purges sysklogd before running the postinst (or preinst) for
> rsyslog. So it's too late to hack a fix in by then.

Not necessarily.

And, if sysklogd *is* purged before the rsyslog postinst runs, then there's
no cleanup needed - sysklogd postrm removes the user, rsyslog postinst
re-adds the user, no problem at all.

So this should simply be:

  if [ -e /var/lib/dpkg/info/sysklogd.postrm ]; then
   sed -i -e'/deluser/d' /var/lib/dpkg/info/sysklogd.postrm
  fi

in the rsyslog postinst, before the #DEBHELPER# block that starts the
service.

If that *doesn't* work, then there's another bug going on; rsyslog shouldn't
be started before its postinst has run.

> What about adding the sysklogd.postrm hack to update-manager? It has a
> quirk system for upgrading between releases, right?

Could be done, but I think it's better to keep the quirk local to the
affected packages (i.e., we only care about this in the case that sysklogd
is being removed and rsyslog is being installed, so rsyslog can just as well
do the same thing that update-manager would in its stead).

Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

> no cleanup needed - sysklogd postrm removes the user, rsyslog postinst
> re-adds the user, no problem at all.

Well, except for the problem noted by Stefan that we aren't guaranteed that rsyslog's syslog user has the same uid/gid as sysklogd's syslog user. This isn't an operational problem (rsyslog will re-chown the files it writes to), but any files that sysklogd owned that rsyslog doesn't care about could be left with an unclaimed uid.

Regardless, I'll shortly attach a debdiff, assuming that the above case is acceptable losses.

Uploaded, thanks. These look like changes that would also be straightforward to push to Debian, could you take care of this?

This bug was fixed in the package sysklogd - 1.5-5ubuntu4

---------------
sysklogd (1.5-5ubuntu4) karmic; urgency=low

  * debian/postrm: Don't delete the syslog user upon purge. LP: #401056

 -- Michael Terry <email address hidden> Tue, 22 Sep 2009 13:16:47 -0700

This bug was fixed in the package rsyslog - 4.2.0-2ubuntu4

---------------
rsyslog (4.2.0-2ubuntu4) karmic; urgency=low

  * debian/rsyslog.postrm: Don't delete syslog user
  * debian/rsyslog.postinst: Stop sysklogd from deleting the syslog user
    when removed. LP: #401056

 -- Michael Terry <email address hidden> Mon, 21 Sep 2009 15:38:13 -0700

Added a bug tracker for the Debian bug I filed for sysklogd. But rsyslog doesn't need a Debian bug because the Debian package doesn't use a syslog user -- it still runs as root.