Bug 630952

Summary:	Does not enable the prefdm and rc-local services
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	low
Version:	14	CC:	bruno, iarlyy, jonathan, lpoetter, mschmidt, notting, plautrba, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	initscripts-9.20-1.fc14	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-09-15 07:13:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	611991

Description Adam Williamson 2010-09-07 13:16:14 UTC

The prefdm and rc-local services were moved from systemd-units to initscripts with initscripts-9.18-1.fc14, but initscripts does not enable them in %post.

There's a wrinkle, here: in system-units the enabling was wrapped in a 'if [ $1 -eq 1 ]; then' statement, but if we do that in initscripts, we'll break upgrades from f13 to f14. initscripts will be being upgraded, not installed, so the if statement won't be satisfied, so the services won't be enabled. There's no immediately obvious solution to this besides enabling the services on every package update, which is inelegant and may be undesired (I can see an admin wanting to disable rc-local). Adding Lennart to CC for his thoughts on how to deal with this. Maybe we should move them back to systemd-units?

(this results in fresh installs and f13 to f14 upgrades with this initscripts package not booting to a graphical login, hence urgent).

thanks to Michael Schmidt for diagnosing this.

Comment 1 Michal Schmidt 2010-09-07 13:26:53 UTC

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.

Comment 2 Adam Williamson 2010-09-07 13:33:39 UTC

that seems reasonable.

it's worth considering the behaviour of the previous system here, too. If a SysV service file specifies it should on certain runlevels by default, then when it's installed, it automatically gets enabled; nothing is required to happen in the spec file.

Comment 3 Bill Nottingham 2010-09-07 19:31:28 UTC

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=f39163514fc1b108c80df1b9b01b63d2d9eafe8d

The trick is to not make them enable-able (or disable-able). This works for the case of prefdm, rc-local, etc. which are things that are hardwired to happen. It doesn't solve the larger concern.

Comment 4 Michal Schmidt 2010-09-07 20:24:43 UTC

Let's discuss the more general concern in bug 630174.

Comment 5 Fedora Update System 2010-09-07 20:30:59 UTC

systemd-9-3.fc14,initscripts-9.19-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.19-1.fc14

Comment 6 Fedora Update System 2010-09-08 03:18:52 UTC

initscripts-9.19-1.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update initscripts systemd'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.19-1.fc14

Comment 7 Fedora Update System 2010-09-10 15:14:30 UTC

initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update initscripts sysvinit systemd'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14

Comment 8 Fedora Update System 2010-09-14 04:28:56 UTC

systemd-10-1.fc14, initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update systemd initscripts sysvinit'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-10-1.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14

Comment 9 Fedora Update System 2010-09-15 07:12:32 UTC

initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-10-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.