Currently, we have no way to ensure service files are disabled when the package providing them is uninstalled and, then, this leads to errors like this being shown on every boot for every no longer available unit file: [ 22.350644] systemd[1]: Cannot add dependency job for unit abrt-vmcore.service, ignoring: Unit abrt-vmcore.service failed to load: No such file or directory. See system logs and 'systemctl status abrt-vmcore.service' for details. [ 22.350655] systemd[1]: Cannot add dependency job for unit abrt-ccpp.service, ignoring: Unit abrt-ccpp.service failed to load: No such file or directory. See system logs and 'systemctl status abrt-ccpp.service' for details. [ 22.350670] systemd[1]: Cannot add dependency job for unit abrt-oops.service, ignoring: Unit abrt-oops.service failed to load: No such file or directory. See system logs and 'systemctl status abrt-oops.service' for details. [ 22.350676] systemd[1]: Cannot add dependency job for unit abrtd.service, ignoring: Unit abrtd.service failed to load: No such file or directory. See system logs and 'systemctl status abrtd.service' for details. [ 22.350682] systemd[1]: Cannot add dependency job for unit abrt-xorg.service, ignoring: Unit abrt-xorg.service failed to load: No such file or directory. See system logs and 'systemctl status abrt-xorg.service' for details. Fedora takes care of this running disable stuff when package is removed, on Gentoo, I guess we could achieve the same exporting a pkg_postinst phase running systemctl disable (this also reminds me that we are also not running "systemctl daemon-reload" when units are modified (installed or removed). This could be achieved with a postinst phase too. The problem is that I see no easy way to standardize that command as service files can have multiple names. Should we suggest upstream to have some kind of auto-disable option to disable no longer existing units? Thanks for your suggestions and ideas
Adding postinst() and/or postrm() at this point sounds dangerous. Maybe we should just do some kind of cronish auto-cleanup in gentoo-systemd-integration?
Then, I'm not really not convinced about auto-playing with user config. If ebuild enables some service, the symlink enabling it should be removed along with the ebuild (it's owned by it). If user enables some service, I don't see 'emerge --depclean' removing it.
(In reply to Michał Górny from comment #2) I agree with this.
(In reply to Michał Górny from comment #1) > Adding postinst() and/or postrm() at this point sounds dangerous. Maybe we > should just do some kind of cronish auto-cleanup in > gentoo-systemd-integration? Why would it be dangerous? In the worst case, the exported phase won't be run because some ebuilds will overwrite it (and, then, they will behave as currently until fixed)
In the worst case, it will actually override important pkg_postinst() / pkg_postrm() from some other eclass.
True, for some reason I though this was the kind of eclass called in alphabetical before others... but taking care it starts by "s"... yes, it would be risky if we don't launch a systemd-r1.eclass for handling this (and the reload commands at install /removal time). Other option would be to suggest upstream (I would report it of course) to add a command to automatically remove all *dead* symlinks, otherwise, people will need to load one command per removed .service file, that can be a bit annoying :/
But why should we do that? Does any other distro do such a thing? We don't do it for OpenRC, I doubt we should do for systemd. One case I can think of is that temporary uninstall of a package would cause it to be disabled permanently.
Fedora is doing that as can be seen in .spec files (for example abrt one). Also, this is not needed in openrc because openrc doesn't look to try to load missing init.d files, while systemd keeps trying to start missing unit files forever. Anyway, having an option to easily disable all dead unit files (removing dead links) could be a mid way: we would still rely on administrator doing that manually (that would solve your valid concerns), still allowing admin to easily remove all of them easily when he wants
Well, something that automatically fixes symlinks in /etc would be a good start. Lemme explain shortly. systemd doesn't use symlinks through the explicit expansion. Rather, it does readlink() and uses target's basename. For example: acpid.service -> /usr/lib64/systemd/system/acpid.service I probably got that due to /usr/lib being a symlink. Now when it's no longer a symlink, the path is completely invalid. Yet systemd starts acpid.service since it uses the basename and looks for it in standard directories. Now, a stale symlinking cleaning service would drop the file. IMO we would first use a tool that would actually fix it to point to the correct location. I wonder if that's upstreamable.
I talked with upstream about this and Lennart explained me that this should be solved by the equivalent of the rpm macro they are using in Fedora, in our case, with a newer eclass doing this on removal of the packages (like the case of running systemd-tmpfilesd --create that is commented in other bug report)
It's been several years, and I still think this is a bad idea. Closing.
