Package: init-system-helpers Version: 1.18 Severity: important Both syslog-ng and rsyslog are socket-activated. /lib/systemd/system/syslog.socket is shipped by systemd itself and the currently installed (and active) syslog implementation is supposed to create a symlink like /etc/systemd/system/syslog.service -> /lib/systemd/system/rsyslog.service via /-------------------- |[Install] |Alias=syslog.service \-------------------- in its service file. If rsyslog is removed, but not purged, i-s-h does *not* remove that symlink. Consider that rsyslog is installed and active, and you run "apt-get install syslog-ng". This will cause rsyslog to be uninstalled (since those packages conflict with each other). Still, after syslog-ng has been installed, the /etc/systemd/system/syslog.service symlink still points to rsyslog.service. This is obviously broken. I'm not sure how to address this. We switched i-s-h to not remove symlinks on "remove" but only on "purge", but I don't remember all the details anymore, why we did that. Michael, do you remember? I fear, switching i-s-h back to remove the symlinks on "remove" might break certain cases again. In this particular case, I assume i-s-h doesn't update the /etc/systemd/system/syslog.service symlink, because it already exists. Any clever idea how to fix this? Michael
Hi Michael, Michael Biebl <biebl@debian.org> writes: Agreed. So, my first thought was whether we could just overwrite symlinks that point to non-existing files, but that’d be a diversion from how “systemctl enable” behaves and foil our plan of replacing deb-systemd-helper with a very simple wrapper/symlink even at some point in the future. Given that this only affects packages that share a common symlink (so far just syslog implementations, display managers, right?), I’m not entirely sure that we need to address this in dh-systemd itself. I mean, certainly, it’d be better if dh-systemd could just do the right thing, but I don’t see a good solution. Can we work around this in the maintscripts of the affected packages instead, perhaps by simply deleting /etc/systemd/system/syslog.service in preinst when it points to a non-existing file?
Am 15.03.2014 20:48, schrieb Michael Stapelberg: Do you remember why we went this route? I don't recall those discussions/reasons anymore but I think initially we went for removing the symlinks on "remove" but changed later on. The remove-symlinks-on-purge approach has the unpleasant side-effect that we might end up with quite a few dangling symlinks if users install and uninstall packages (but forget to purge them). Well, one could argue this is only cosmetical, but still. So far, syslog implementations are affected. Shared symlink is /etc/systemd/system/syslog.service The display-manager scheme proposed by upstream [0][1] uses /etc/systemd/system/display-manager.service So far this scheme is not (yet) adopted by Debian, but I've already seen packages (e.g. slim) use that Alias (which tbh looks like a bug in the package, since it ships the upstream .service file unmodified). As the files are not yet unpacked in preinst (say rsyslog.preinst), checking for the file to be a dangling symlink is probably not a sufficient check, since we potentially would remove it, even if /etc/systemd/system/syslog.service pointed to /lib/systemd/system/rsyslog.service. [0] http://www.freedesktop.org/software/systemd/man/systemd.special.html [1] http://fedoraproject.org/wiki/Features/DisplayManagerRework
Am 17.03.2014 13:53, schrieb Michael Biebl: I also need to check, if leaving the dangling /etc/systemd/system/syslog.service symlink around after package uninstall confuses systemd wrt to syslog.socket.
control: reassign -1 rsyslog control: retitle -1 Remove dangling syslog.service symlink in preinst Hi Michael, As discussed in person, removing the dangling symlink in preinst in the affected packages (rsyslog, syslog-ng) should work fine, because it will be fixed afterwards in postinst of that same package. Regardless of where the socket points, this should be okay — it is being recreated after all.
Am 26.04.2014 19:39, schrieb Michael Stapelberg: Consider the following sequence of events 1/ rsyslog is installed 2/ rsyslog is removed, but not purged 3/ syslog-ng is installed, makes sure that the /etc/systemd/system/syslog.service symlink is created and pointing at syslog-ng *). 4/ rsyslog package is purged → i-s-h removes the symlink I don't think i-s-h stores enough information to distinguish where the symlink is pointing at, righ? So, either we rethink how i-s-h handles such shared symlinks, or we don't handle them via i-s-h at all and do that manually in the maintainer scripts of syslog-ng-core and rsyslog. But then, I don't think we can let i-s-h handle the multi-user.target.wants symlink but not the syslog.service symlink? *) atm it doesn't do that, i.e. after installation of syslog-ng the symlink points at rsyslog.service
Hi, FWIW, I just ran into this bug on several machines while switching from inetutils-syslogd to rsyslog. Not being very familiar with systemd, I scratched my head for a few days with it. My workaround at the end: for e in stop disable enable start; do systemctl $e rsyslog; done logger test tail /var/log/syslog Hoping this helps others running into the bug,