= Proposal topic =
= Overview =
FPC recently passed guidelines on how to write rpm spec files that need to migrate from systemV init scripts to systemd unit files. The migration strategy does not attempt to mimic runlevels so the on/off value of services is set back to what is the default for the systemd unit files.
The FPC thinks that this warrants coordination to ensure the best user experience. The best case is that all services which have shipped with system v init scripts in the past are upgraded to have systemd unit files in one Fedora release. The next best thing would be for individual services to transition to unit files only in the lead up to a new release. Today the FPC passed a clarification to have a warning about the latter put into the guidelines. This ticket is to find out what can be done about the former. Could we have a FES ticket to get people to work on this for F16? Is there another way to coordinate this?
I would think that the formal procedure would be to create a feature page however converting the service files are one thing cleaning up another related things in the process is another and on top of my head there are few things that need to be sorted out preferable by fesco before fixing the submitted service files to match the approved guidelines and converting the rest.
Several service are inserting and removing modules when started and stopped.
Now afaik modules should be loaded via autoloading based on bus information, or via /etc/modules-load.d/*.conf. and unloading a module from the kernel should not be done except for debugging purposes so the question remains if this should not be fixed in the process?
Now the proper way of handling this in service files would be ( if we continue with things as they are as opposed to fixing them )
To load a module before a service is started
ExecStartPre=-/sbin/modprobe -qab <module>
To remove a module after a service has been stopped.
ExecStop=-/sbin/modprobe -qabr <module>
And then there is a question if we drop the support for loading legacy modules ( /etc/sysconfig/modules/ )
Should we not identify which services they are and create udev rules for those?
We are missing some kind of policy/guidelines on writing those
Getting a list of from freedesktop on which services support dbus activation ( the method I have been using is to monitor dbus and see if something changes when starting the old sysv init script before converting it and this significantly slows down the time to convert the service as opposed to just have a list of service which are capable of dbus activation and convert those ).
We need to have a deadline during the release cycle that all submitted native systemd service files should be packed and available so we can host a test day and properly test and catch any potential updates/upgrades issues and conflicts etc. in those native systemd service files.
Then it's the question if an service has not been converted and ship before that time it wont be introduced until next release cycle.
Converting all those service should be doable during F16 if all pieces fall into place ( we converted something like 100 - 150 which leaves us with ca 400 left to convert ) if not the remaining ones during the F17 cycle so F17 should be completely sysv init free.
Adding meeting keyword here.
I think personally a FES ticket would be great, as well as a feature page to help coordinate progress and people working on it. ;)
Fesco would love to see:
We will keep this open to address items moving forward.
The feature page draft can be found here https://fedoraproject.org/wiki/Features/SysVtoSystemd once finished it will flag FeatureReadyForWrangler for standard process handling..
Would it be a good idea to have a git instance to contain all the native systemd service files?
This work can be tracked on the feature page. ;)
Login to comment on this ticket.