Description of problem: While systemd's symlink-based configuration is very flexible, it's not as easy to back out of as a config file approach, where you can just install the stock config file. What would be nice is some simple command that resets /etc/systemd/system to a default known state. Not sure how complex this would be, though. Version-Release number of selected component (if applicable): systemd-9-3
In today's IRC conversation with Adam Williams during the systemd Test Day about bug 630952 I got some ideas which are in fact closely related to this bug. I'll copy my comment from bug 630952 here: -------- I'm thinking the main error is in systemd design itself. Deciding to "systemctl enable" a service in various %post scriptlets based on whether the package is installed or upgraded is fragile. Once a packager forgets to enable the service in a package, he cannot easily fix it in a later version. The "if [ $1 -eq 1 ]" test is no good. We witnessed this already several times during F-14 development. See the "Heads-up" emails from Lennart on the devel mailing list asking people to fixup their symlinks by a manual action. A good design would easily allow a new version of the package to correct the mistakes of the previous version automatically. Also, the default configuration of symlinks is scattered across packages' scriptlets. There's no way to easily find out, what the default setup is supposed to look like. See a related bug 630174. I propose systemctl should get a new subcommand, let's call it "new-services". Scriptlets would not run "systemctl enable my.service" but "systemctl new-services". This would scan the /lib/systemd/system directory for newly installed *.service and process their "[Install]" sections as the "enable" command would. The difference would be that systemctl would keep a state directory somewhere to track which services were already enabled by it. This will allow to distinguish between services that were never enabled and those that were manually disabled by the user.
Some more thoughts about the general issue: Considering a service which ships a SysV initscript: The initscript can be in these states: - INSTALLED - /etc/init.d/$service exists - /etc/rc?.d/[SK]* symlinks not present - ADDED - e.g., after "chkconfig --add $service" - K* symlinks present - if the initscript's chkconfig header asks for it, also some S* symlinks are present - MODIFIED - after the administrator changed some K* symlinks to S* or vice-versa - e.g. after "chkconfig $service {on,off}" was used The service is packaged in a RPM which does: %post chkconfig --add $service It can do that both after installation and upgrade, because the action is idempotent - repeating it does not change the result. If the service was just INSTALLED, it will be ADDED. If it was already ADDED, nothing will change. If it was already MODIFIED, nothing will change. Now consider the service uses a native systemd unit instead: A systemd service can be either: - DISABLED - /lib/systemd/system/$service.service exists, but is not symlinked - ENABLED - after "systemctl enable $service.service" - some symlinks point to it The key problem here is that there is no third state. There is no simple way to detect if the service was enabled/disabled by the administrator. If there were three states, packages could do something like: %post systemctl add-unit $service.service add-unit would notify systemd of a newly installed unit file and optionally enable the service too. The service could request this using a new key in the [Install] section: EnableByDefault=true add-unit would have to be idempotent. Tracking of the three states could be implemented using state information kept in, say /var/lib/systemd/. It could be a simple flat list of units already added or something more complicated if needed. (The "new-services" idea from comment #1 was probably complicating it a bit too much.)
Amen to that - I've gotten bit by this issue already (my gettys managed to evaporate). Additionally, as this makes its way into RHEL and onto systems that have audit requirements, there *will* be questions from auditors of the form "list all installed but not enabled daemons". It's easy to find them under chkconfig, just look in /etc/init.d and all possible daemons are there, whether or not chkconfig --add has been run. Doing an 'rpm -qa' and wading through the 1,889 rpms on my laptop is a non-starter.
Moving systemd bugs to f15, since the systemd feature got delayed.
Note that at least the issue with default.target is gone since we nowadays place a fallback default.target symlink in /lib/systemd which is used in case the one in /etc/systemd does not exist.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Ping what's the current status on this?
Presets are poised to fix this problem. Check F18 features.
We could implement this relatively nicely now, using the preset logic. i.e. by doing the equivalent of invoking "systemctl reenable" on all unit files we have. That will sync the system with the preset files, and leave only symlinks to services that are not shipped upstream in /etc, plus any files that might exist there.
(In reply to comment #9) > We could implement this relatively nicely now, using the preset logic. i.e. > by doing the equivalent of invoking "systemctl reenable" on all unit files > we have. That will sync the system with the preset files, and leave only > symlinks to services that are not shipped upstream in /etc, plus any files > that might exist there. ping
pinging... who? That seems like a reasonable implementation.
(In reply to comment #11) > pinging... who? That seems like a reasonable implementation. ping for the actual implementation :)
#9 is now implemented in git.
systemctl preset-all should do the trick.