[opensuse-factory] package systemd migration
Hi, I might have missed important systemd information during the 12.1 development phase but haven't had to deal with it for my packages up to now. A recent package update now introduced systemd services and I found it's not obvious to me what to do. It already starts with trivial questions where I have an my own understanding but not absolutely sure. The package provides an init script currently and now added systemd service files. So the following questions came to my mind: Do I still package the sysvinit files? I guess that's a yes because we still offer the sysvinit boot process. The package has a sysconfig file which only takes a variable to modify the daemon options. Can I use that for systemd as well? How to do that? The daemon is currently started by default when installed. What happens after the update to the new version which includes systemd files? Will it be enabled by default? (I've actually tried the update and the service was running afterwards so I guess it will be enabled in update case but not for a fresh installation?) For the service it makes a lot of sense to use systemd's socket activation feature. So what do I need to do exactly to have the service disabled but have the socket enabled to start the service automatically (in terms of system configuration)? Is the only way to have services/sockets enabled by default to modify some certain systemd package and not from within a package installation? This sounds strange and rather unfortunate so it's for example not possible to install/update a package which then starts a service by default w/o updating an official central distribution package? I've tried to find answers to those questions in the wiki but had no luck. Any hints? Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Wolfgang, I'm in no way a systemd expert. I'm trying to answer your questions with what I know. This might be incomplete or partially wrong, if someone finds an error, please correct me. On 20.11.2011 22:32, Wolfgang Rosenauer wrote:
Hi,
I might have missed important systemd information during the 12.1 development phase but haven't had to deal with it for my packages up to now. A recent package update now introduced systemd services and I found it's not obvious to me what to do. It already starts with trivial questions where I have an my own understanding but not absolutely sure.
The package provides an init script currently and now added systemd service files. So the following questions came to my mind:
Do I still package the sysvinit files? I guess that's a yes because we still offer the sysvinit boot process.
Yes. And obviously if there is a native file, it overrides the SysV init script: susi:~ # systemctl status syslog.service syslog.service - System Logging Service Loaded: loaded (/lib/systemd/system/syslog.service; enabled) [...] susi:~ # l /etc/init.d/syslog -rwxr-xr-- 1 root root 6197 Nov 11 12:28 /etc/init.d/syslog*
The package has a sysconfig file which only takes a variable to modify the daemon options. Can I use that for systemd as well? How to do that?
Check the NetworkManager-wait-online.service, it does exactly that: susi:~ # cat /lib/systemd/system/NetworkManager-wait-online.service [Unit] Description=Network Manager Wait Online Requisite=NetworkManager.service After=NetworkManager.service Wants=network.target Before=network.target [Service] Type=oneshot Environment=NM_ONLINE_TIMEOUT=30 EnvironmentFile=-/etc/sysconfig/network/config ExecStart=/usr/bin/nm-online -q --timeout=${NM_ONLINE_TIMEOUT} [Install] WantedBy=network.target
The daemon is currently started by default when installed. What happens after the update to the new version which includes systemd files? Will it be enabled by default? (I've actually tried the update and the service was running afterwards so I guess it will be enabled in update case but not for a fresh installation?)
I don't know this one, there was something discussed about the package "systemd-branding" which defines which services to start by default etc, but I don't know if this will apply here.
For the service it makes a lot of sense to use systemd's socket activation feature. So what do I need to do exactly to have the service disabled but have the socket enabled to start the service automatically (in terms of system configuration)? Is the only way to have services/sockets enabled by default to modify some certain systemd package and not from within a package installation? This sounds strange and rather unfortunate so it's for example not possible to install/update a package which then starts a service by default w/o updating an official central distribution package?
I think that your package should be able to supply its own socket file. Udev does it, too: susi:~ # rpm -qf /lib/systemd/system/udev-kernel.socket udev-173-6.1.x86_64 Hope this helps, seife -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 22.11.2011 13:58, schrieb Stefan Seyfried:
I'm in no way a systemd expert.
not a problem if you know more than I do ;-)
I'm trying to answer your questions with what I know. This might be incomplete or partially wrong, if someone finds an error, please correct me.
On 20.11.2011 22:32, Wolfgang Rosenauer wrote:
The package provides an init script currently and now added systemd service files. So the following questions came to my mind:
Do I still package the sysvinit files? I guess that's a yes because we still offer the sysvinit boot process.
Yes. And obviously if there is a native file, it overrides the SysV init script:
Ok, I revived all the postinstall scriptlets for sysvinit which are obviously still needed.
The package has a sysconfig file which only takes a variable to modify the daemon options. Can I use that for systemd as well? How to do that?
Check the NetworkManager-wait-online.service, it does exactly that:
Thanks for the pointer. Trying that.
The daemon is currently started by default when installed. What happens after the update to the new version which includes systemd files? Will it be enabled by default? (I've actually tried the update and the service was running afterwards so I guess it will be enabled in update case but not for a fresh installation?)
I don't know this one, there was something discussed about the package "systemd-branding" which defines which services to start by default etc, but I don't know if this will apply here.
I know neither. But as I said this makes upgrade in an existing release pretty ugly. Think about tumbleweed or other backports users. That means I cannot create a smooth migration. Unless: Could I just do: systemctl enable pcscd.socket systemctl disable pcscd.service in the %post script?
For the service it makes a lot of sense to use systemd's socket activation feature. So what do I need to do exactly to have the service disabled but have the socket enabled to start the service automatically (in terms of system configuration)? Is the only way to have services/sockets enabled by default to modify some certain systemd package and not from within a package installation? This sounds strange and rather unfortunate so it's for example not possible to install/update a package which then starts a service by default w/o updating an official central distribution package?
I think that your package should be able to supply its own socket file. Udev does it, too:
It does. I was basically wondering how to enable it on upgrades w/o touching base system packages in addition. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On ti., 2011-11-22 at 14:59 +0100, Wolfgang Rosenauer wrote:
Hi,
Am 22.11.2011 13:58, schrieb Stefan Seyfried:
I know neither. But as I said this makes upgrade in an existing release pretty ugly. Think about tumbleweed or other backports users. That means I cannot create a smooth migration. Unless: Could I just do: systemctl enable pcscd.socket systemctl disable pcscd.service in the %post script?
For the service it makes a lot of sense to use systemd's socket activation feature. So what do I need to do exactly to have the service disabled but have the socket enabled to start the service automatically (in terms of system configuration)? Is the only way to have services/sockets enabled by default to modify some certain systemd package and not from within a package installation? This sounds strange and rather unfortunate so it's for example not possible to install/update a package which then starts a service by default w/o updating an official central distribution package?
I think that your package should be able to supply its own socket file. Udev does it, too:
It does. I was basically wondering how to enable it on upgrades w/o touching base system packages in addition.
Wolfgang
Depending on whether your service should or should not be started/stopped/restarted during package installation, deinstallation or upgrade, a different set of commands may be specified. See systemctl(1) for details. To facilitate upgrades from a package version that shipped only SysV init scripts to a package version that ships both a SysV init script and a native systemd service file, use a fragment like the following: %triggerun -- foobar < 0.47.11-1 if /sbin/chkconfig --level 5 foobar ; then /bin/systemctl --no-reload enable foobar.service foobar.socket
/dev/null 2>&1 || : fi
Where 0.47.11-1 is the first package version that includes the native unit file. This fragment will ensure that the first time the unit file is installed it will be enabled if and only if the SysV init script is enabled, thus making sure that the enable status is not changed. Note that chkconfig is a command specific to Fedora which can be used to check whether a SysV init script is enabled. Other operating systems will have to use different commands here. //Bjørn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le dimanche 20 novembre 2011 à 22:32 +0100, Wolfgang Rosenauer a écrit :
Hi,
I might have missed important systemd information during the 12.1 development phase but haven't had to deal with it for my packages up to now. A recent package update now introduced systemd services and I found it's not obvious to me what to do. It already starts with trivial questions where I have an my own understanding but not absolutely sure.
First things first, you should read : http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines
The package provides an init script currently and now added systemd service files. So the following questions came to my mind:
Do I still package the sysvinit files? I guess that's a yes because we still offer the sysvinit boot process.
Yes, unless you don't want to drop sysvinit support :)
The package has a sysconfig file which only takes a variable to modify the daemon options. Can I use that for systemd as well? How to do that?
You can, but it depends how the variable was used. It is was just appending the parameters to the daemon, using variable content, you can do use something like EnvironmentFile=-/etc/sysconfig/foobar (- is to make sure /etc/sysconfig/foobar missing won't cause an issue) ExecStart=/bin/foobar ${MY_PARAMS} where /etc/sysconfig/foobar contains things like : MY_PARAMS=-f foo -b ...
The daemon is currently started by default when installed. What happens after the update to the new version which includes systemd files? Will it be enabled by default? (I've actually tried the update and the service was running afterwards so I guess it will be enabled in update case but not for a fresh installation?)
No it won't be enabled by default. If you really want that, you need to open a sr against systemd-presets-branding-openSUSE (see http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_servic... )
For the service it makes a lot of sense to use systemd's socket activation feature. So what do I need to do exactly to have the service disabled but have the socket enabled to start the service automatically (in terms of system configuration)? Is the only way to have services/sockets enabled by default to modify some certain systemd package and not from within a package installation? This sounds strange and rather unfortunate so it's for example not possible to install/update a package which then starts a service by default w/o updating an official central distribution package?
You should be able to use the same mecanism for socket than for .service (and yes, you should not enable .service if you want on-demand activation, see http://0pointer.de/blog/projects/socket-activation.html ) -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/11/11 13:27, Frederic Crozat wrote:
Le dimanche 20 novembre 2011 à 22:32 +0100, Wolfgang Rosenauer a écrit :
Hi,
I might have missed important systemd information during the 12.1 development phase but haven't had to deal with it for my packages up to now. A recent package update now introduced systemd services and I found it's not obvious to me what to do. It already starts with trivial questions where I have an my own understanding but not absolutely sure.
First things first, you should read :
http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines
huh, that will uglify spec files even more :-| why doesnt those macros are declared as noop in older products and %{_unitdir} defined as %exclude /lib/systemd.... ? will be a matter of defining it in the project configuration... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 28 novembre 2011 à 14:45 -0300, Cristian Rodríguez a écrit :
On 28/11/11 13:27, Frederic Crozat wrote:
Le dimanche 20 novembre 2011 à 22:32 +0100, Wolfgang Rosenauer a écrit :
Hi,
I might have missed important systemd information during the 12.1 development phase but haven't had to deal with it for my packages up to now. A recent package update now introduced systemd services and I found it's not obvious to me what to do. It already starts with trivial questions where I have an my own understanding but not absolutely sure.
First things first, you should read :
http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines
huh, that will uglify spec files even more :-| why doesnt those macros are declared as noop in older products and %{_unitdir} defined as %exclude /lib/systemd.... ? will be a matter of defining it in the project configuration...
Well, you should have commented on packaging when I proposed those macros earlier (months ago).. And the point is to get those macros "upstreamed" too. %{_unitdir} was already used by Fedora before I worked on the proposal. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.11.2011 17:27, schrieb Frederic Crozat:
Le dimanche 20 novembre 2011 à 22:32 +0100, Wolfgang Rosenauer a écrit :
Hi,
I might have missed important systemd information during the 12.1 development phase but haven't had to deal with it for my packages up to now. A recent package update now introduced systemd services and I found it's not obvious to me what to do. It already starts with trivial questions where I have an my own understanding but not absolutely sure.
First things first, you should read :
http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines
Does it actually looks like I didn't? That's obviously what I did before but it doesn't answer any of my questions directly.
The package provides an init script currently and now added systemd service files. So the following questions came to my mind:
Do I still package the sysvinit files? I guess that's a yes because we still offer the sysvinit boot process.
Yes, unless you don't want to drop sysvinit support :)
Ok, that's what I found after writing the initial mail ;-)
The package has a sysconfig file which only takes a variable to modify the daemon options. Can I use that for systemd as well? How to do that?
You can, but it depends how the variable was used. It is was just appending the parameters to the daemon, using variable content, you can do use something like EnvironmentFile=-/etc/sysconfig/foobar (- is to make sure /etc/sysconfig/foobar missing won't cause an issue) ExecStart=/bin/foobar ${MY_PARAMS}
where /etc/sysconfig/foobar contains things like : MY_PARAMS=-f foo -b ...
I was pointed to an example and already resolved this one.
The daemon is currently started by default when installed. What happens after the update to the new version which includes systemd files? Will it be enabled by default? (I've actually tried the update and the service was running afterwards so I guess it will be enabled in update case but not for a fresh installation?)
No it won't be enabled by default. If you really want that, you need to open a sr against systemd-presets-branding-openSUSE (see http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_servic... )
You didn't answer to my concern about updates from backports or things like Tumbleweed. I cannot enable a service from a package? I guess I can just call systemctl? Sorry, but this needs another solution. What about third party packages? They are never allowed to register themselves as a service automatically? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 28 novembre 2011 à 19:30 +0100, Wolfgang Rosenauer a écrit :
Am 28.11.2011 17:27, schrieb Frederic Crozat:
Le dimanche 20 novembre 2011 à 22:32 +0100, Wolfgang Rosenauer a écrit :
Hi,
I might have missed important systemd information during the 12.1 development phase but haven't had to deal with it for my packages up to now. A recent package update now introduced systemd services and I found it's not obvious to me what to do. It already starts with trivial questions where I have an my own understanding but not absolutely sure.
First things first, you should read :
http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines
Does it actually looks like I didn't? That's obviously what I did before but it doesn't answer any of my questions directly.
I don't know, I'm not behind you, looking at your screen ;) And other people might not have looked at this page, reminding everybody can't be wrong.
The daemon is currently started by default when installed. What happens after the update to the new version which includes systemd files? Will it be enabled by default? (I've actually tried the update and the service was running afterwards so I guess it will be enabled in update case but not for a fresh installation?)
No it won't be enabled by default. If you really want that, you need to open a sr against systemd-presets-branding-openSUSE (see http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_servic... )
You didn't answer to my concern about updates from backports or things like Tumbleweed. I cannot enable a service from a package?
You should not (the policy is to use presets from systemd-presets-branding-openSUSE). But if you do (by adding systemctl enable in %post), we won't come and kill you (at least, for now).
I guess I can just call systemctl? Sorry, but this needs another solution. What about third party packages? They are never allowed to register themselves as a service automatically?
They can drop a file in /lib/systemd/system.preset to change policy for their package. Again, we are trying to come to cross-distribution rules. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Frederic Crozat wrote:
Le lundi 28 novembre 2011 à 19:30 +0100, Wolfgang Rosenauer a écrit : [...]
You didn't answer to my concern about updates from backports or things like Tumbleweed. I cannot enable a service from a package?
You should not (the policy is to use presets from systemd-presets-branding-openSUSE). But if you do (by adding systemctl enable in %post), we won't come and kill you (at least, for now).
I guess I can just call systemctl? Sorry, but this needs another solution. What about third party packages? They are never allowed to register themselves as a service automatically?
They can drop a file in /lib/systemd/system.preset to change policy for their package.
Hmm, maybe we should add rpmlint checks to prevent distro packages from doing that. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 29 novembre 2011 à 09:49 +0100, Ludwig Nussel a écrit :
Frederic Crozat wrote:
Le lundi 28 novembre 2011 à 19:30 +0100, Wolfgang Rosenauer a écrit : [...]
You didn't answer to my concern about updates from backports or things like Tumbleweed. I cannot enable a service from a package?
You should not (the policy is to use presets from systemd-presets-branding-openSUSE). But if you do (by adding systemctl enable in %post), we won't come and kill you (at least, for now).
I guess I can just call systemctl? Sorry, but this needs another solution. What about third party packages? They are never allowed to register themselves as a service automatically?
They can drop a file in /lib/systemd/system.preset to change policy for their package.
Hmm, maybe we should add rpmlint checks to prevent distro packages from doing that.
Sounds like a good idea. Also, rpmlint should check if a .service (or .socket) is listed and cause build to fail if no macros are used to register systemd service (this was top most complains from packages shipping both sysv and systemd services but not migrated to new macros, since systemd was favoring its native services but it wasn't "registered" by default). -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (6)
-
Bjørn Lie -
Cristian Rodríguez -
Frederic Crozat -
Ludwig Nussel -
Stefan Seyfried -
Wolfgang Rosenauer