Red Hat Bugzilla – Bug 739446
RFE: Convert to systemd
Last modified: 2013-08-17 11:18:38 EDT
Created attachment 523782 [details]
convert spin-kickstarts to systemd
As per summary. ;)
This is a giant patch which converts livesys and livesys-late into a set of systemd services and scripts.
I've tested at least that it produces desktop, KDE and xfce spins with the current F16 package set which work the same as the non-systemd versions.
1) we should be able to use systemd's ConditionKernelCommandLine to replace checking of the 'livesys' parameter within the scripts - and we could also use it in other packages to prevent services starting live, obviating the need for livesys.service to dirtily disable them - but it seems like it does not work when running in a VM, which makes it fairly useless for our purposes.
2) I disabled the "gsettings set org.gnome.settings-daemon.plugins.updates active 'false' || :" line in livesys.sh because I thought it was breaking things; it probably wasn't, but there's a comment from mclasen in the git log to the effect that it doesn't work anyway, and it's probably in the wrong place. disabling automatic update checking should probably be done per-spin, depending on the update checking mechanism installed on the spin. Regardless, it would be easy to uncomment it and try it again.
3) I initially added commands to disable systemd's readahead services to livesys.sh, but ordering livesys.service before systemd's readahead services is problematic: it causes livesys.service to fire before systemd-tmpfiles-setup.service , and that causes various other problems. So we can't do that very easily.
4) I haven't checked the 'liveinst' and 'textinst' bits yet, but they're not working right in current non-systemd spin-kickstarts anyway (systemd times out the livesys-late service after 90 seconds, and X starts up all over your anaconda).
5) I realize this makes the spec file a bit long. It'd probably be trivial to set it up so spin-kickstarts.spec.in was much shorter and got expanded out into the whole thing by the Makefile - obviously, the sub-packages for each spin could fairly easily be auto-generated somehow.
6) We could get more adventurous and split livesys into several smaller services which just did one thing each; splitting out the persistent home stuff would be an obvious choice. But that's further down the road.
This patch is against *current* spin-kickstarts - it's not cumulative with the smaller patches I also have submitted recently. I doubt we'd want to do this for F16 at this point, though I suspect it'd actually probably work out okay. It might be best to make it F17 stuff.
Comments, questions, bugs, improvements welcome!
I took a brief look at this.
The patch no longer cleanly applies to the master branch. Some of this is minor stuff (the version change in confiure.ac) and some of it loses important changes.
I am not sure I like creating per spin sh and service files or separate packages for that matter.
We really should be moving towards integrating systemd in live images. This is the sort of thing that we should be covering in our non-existent Spins SIG meetings. I'll try to see if I can get some attention for this bug on the spins mailing list.
"I am not sure I like creating per spin sh and service files or separate
packages for that matter."
Well, the existing .ks has this comment:
# FIXME: it'd be better to get this installed from a package
cat > /etc/rc.d/init.d/livesys << EOF
so I rather thought it was desired. If we want to install it from a package, it seems to me to make sense to have a sub-package for each spin for each spin's spin-specific customizations; how else would you do this, if we're getting them from a package somehow?
I did try to start a discussion about this subject on the spins list, since some of the other people there have a better feel for this stuff than myself. Hopefully that generates some feedback from more knowlegeable people than me.
I actually like the ks files being more self contained, though they do depend on some base ks files. I think it makes it a bit easier to customize stuff when all you might want to change is in one place. But I could easily be wrong about this really being better.