Many thanks to Lennart for writing the initial text for the systemd guidelines. I've taken his draft and reworked it a bit so that it matches the flow and style of the existing guidelines:
https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft
Keep in mind that %{_unitdir} is undefined at the moment, we would add it to redhat-rpm-config before this draft becomes a guideline.
Please look it over and give any feedback.
Thanks, ~tom
== Fedora Project
On Wednesday 01 December 2010, Tom Callaway wrote: [...]
https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft
[...]
Please look it over and give any feedback.
I haven't educated myself much at all about systemd, and didn't read the draft completely, but here are some comments:
| BusName= should be set for all services connecting to D-Bus. (i.e. it is a | must for those where Type=dbus, but might make sense otherwise, too) Omit | this option if your service does not take a name on the bus.
Should the "the bus" at the end be replaced by "D-Bus" or "a bus" or "any bus" or "the bus specified with Type=..." or...? Not sure exactly what bus does it mean.
| ExecReload= should be specified for all services supporting reload. It is | highly recommended to add code here that synchronously reloads the | configuration file here (i.e. /bin/kill -HUP $MAINPID is usually a poor | choice, due to its asynchronous nature). Omit this option if your service | does not support reloading.
Does this mean that services that do support reloading but only asynchronously should not include this option? I guess not, i.e. asynch reload is better than no reload? If that's correct, explicitly mentioning that would be an improvement.
On 12/02/2010 05:04 PM, Ville Skyttä wrote:
| BusName= should be set for all services connecting to D-Bus. (i.e. it is a | must for those where Type=dbus, but might make sense otherwise, too) Omit | this option if your service does not take a name on the bus.
Should the "the bus" at the end be replaced by "D-Bus" or "a bus" or "any bus" or "the bus specified with Type=..." or...? Not sure exactly what bus does it mean.
Should probably be replaced by "any bus". Lennart, do you agree?
| ExecReload= should be specified for all services supporting reload. It is | highly recommended to add code here that synchronously reloads the | configuration file here (i.e. /bin/kill -HUP $MAINPID is usually a poor | choice, due to its asynchronous nature). Omit this option if your service | does not support reloading.
Does this mean that services that do support reloading but only asynchronously should not include this option? I guess not, i.e. asynch reload is better than no reload? If that's correct, explicitly mentioning that would be an improvement.
I'll defer to Lennart here as to what he thinks is acceptable.
~tom
== Fedora Project
On Wed, Dec 01, 2010 at 10:46:21AM -0500, Tom Callaway wrote:
Many thanks to Lennart for writing the initial text for the systemd guidelines. I've taken his draft and reworked it a bit so that it matches the flow and style of the existing guidelines:
https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft
Keep in mind that %{_unitdir} is undefined at the moment, we would add it to redhat-rpm-config before this draft becomes a guideline.
Please look it over and give any feedback.
Okay -- one thing is whether we want to specifiy that services either install unit files or systemvinit files but not both (in the same package. A subpackage for the alternate init system would be fine.) The idea being that there's several ways that having the sysvinit can confuse sysadmins. Off the top of my head I can think of:
1) A system admin unfamiliar with systemd installs apache and sees that there's an /etc/init.d/httpd file. He runs /etc/init.d/httpd start to startup the service unaware that when systemd reboots the service it will be using the unit file and not the sysvinit script.
2) A system admin unfamiliar with systemd sees that there's an /etc/init.d/httpd file. He customizes the file for his environment but then is confused why his customizations aren't being used when the system reboots (and systemd starts httpd using the unit file).
SysVinit scripts could still be installed as documentation or via a subpackage for system admins that want to run an alternate init system.
-Toshio
On 12/02/2010 10:58 PM, Toshio Kuratomi wrote:
Okay -- one thing is whether we want to specifiy that services either install unit files or systemvinit files but not both (in the same package. A subpackage for the alternate init system would be fine.) The idea being that there's several ways that having the sysvinit can confuse sysadmins. Off the top of my head I can think of:
The subpackage idea seems like the cleanest way to permit packagers to provide this option, but minimize admin confusion.
$foo-sysvinit seems like a sane scheme.
~tom
== Fedora Project
Toshio Kuratomi (a.badger@gmail.com) said:
- A system admin unfamiliar with systemd installs apache and sees that
there's an /etc/init.d/httpd file. He runs /etc/init.d/httpd start to startup the service unaware that when systemd reboots the service it will be using the unit file and not the sysvinit script.
/etc/init.d/<foo> start redirects to systemctl; systemd will then start whichever of the units is 'active' - in this case, it would be the systemd service both before and after reboot.
- A system admin unfamiliar with systemd sees that there's an
/etc/init.d/httpd file. He customizes the file for his environment but then is confused why his customizations aren't being used when the system reboots (and systemd starts httpd using the unit file).
This is a more likely source of confusion.
Just attempting to clarify current behavior, Bill
On Fri, Dec 03, 2010 at 02:00:37PM -0500, Bill Nottingham wrote:
Toshio Kuratomi (a.badger@gmail.com) said:
- A system admin unfamiliar with systemd installs apache and sees that
there's an /etc/init.d/httpd file. He runs /etc/init.d/httpd start to startup the service unaware that when systemd reboots the service it will be using the unit file and not the sysvinit script.
/etc/init.d/<foo> start redirects to systemctl; systemd will then start whichever of the units is 'active' - in this case, it would be the systemd service both before and after reboot.
How does this work? Does this mean that init scripts have to be rewritten to do something like this?
start) systemctl check-that-systemd-is-the-init-system if test $? ; then systemctl $1 start else # Do startup when running sysvinit/upstart/etc fi
-Toshio
Toshio Kuratomi (a.badger@gmail.com) said:
On Fri, Dec 03, 2010 at 02:00:37PM -0500, Bill Nottingham wrote:
Toshio Kuratomi (a.badger@gmail.com) said:
- A system admin unfamiliar with systemd installs apache and sees that
there's an /etc/init.d/httpd file. He runs /etc/init.d/httpd start to startup the service unaware that when systemd reboots the service it will be using the unit file and not the sysvinit script.
/etc/init.d/<foo> start redirects to systemctl; systemd will then start whichever of the units is 'active' - in this case, it would be the systemd service both before and after reboot.
How does this work?
Transparently; if an init.d script is called with 'start', 'stop', 'reload', 'restart', or 'condrestart' (or any synonyms thereof), it's silently redirected to systemctl if systemd is in use. See the top of /etc/init.d/functions for details.
Does this mean that init scripts have to be rewritten to do something like this?
No, no initscript changes are required.
Bill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2010 10:23 AM, Bill Nottingham wrote:
Toshio Kuratomi (a.badger@gmail.com) said:
How does this work?
Transparently; if an init.d script is called with 'start', 'stop', 'reload', 'restart', or 'condrestart' (or any synonyms thereof), it's silently redirected to systemctl if systemd is in use. See the top of /etc/init.d/functions for details.
I'd like to mention that this isn't all working at present: https://bugzilla.redhat.com/show_bug.cgi?id=655116
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Tom Callaway (tcallawa@redhat.com) said:
Many thanks to Lennart for writing the initial text for the systemd guidelines. I've taken his draft and reworked it a bit so that it matches the flow and style of the existing guidelines:
https://fedoraproject.org/wiki/TomCallaway/Systemd_Revised_Draft
Keep in mind that %{_unitdir} is undefined at the moment, we would add it to redhat-rpm-config before this draft becomes a guideline.
Please look it over and give any feedback.
1) Typo - 'For "one-short" scripts "oneshot" is ideal'
2) On one hand, perhaps what BusName is should be elaborated on, but on the other hand, if you need to ask, you don't need it.
3) ExecStart (and similar keys) take full pathnames as the binary/script to execute (instead of searching $PATH); this should be mentioned.
4) Suggest changing:
The recommended parameters for WantedBy are either multi-user.target (for most system services) or graphical.target (for services related to the UI).
to:
The recommended parameters for WantedBy are either multi-user.target (for most system services, analagous to runlevel 3 in System V) or graphical.target (for services related to the UI, analagous to runlevel 5). Note that graphical.target automatically includes services from multi-user.target.
5) In 'Support for /etc/sysconfig files', perhaps should note that variable substitution is not supported for the initial argument for Exec<foo> lines.
Bill
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Stephen Gallagher -
Tom Callaway -
Toshio Kuratomi -
Ville Skyttä