Summary: | systemd.eclass: take care of disabling uninstalled services | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | Current packages | Assignee: | Gentoo systemd Team <systemd> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=487504 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Pacho Ramos
2013-08-11 13:04:32 UTC
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. |