Hi,
I'm working on systemd unit file for ypbind and found some problems, that I'm not sure about:
1) if I use systemctl enable/disable instead of chkconfig in %post and %preun sections in spec file, rpmlint prints errors: postin-without-chkconfig /etc/rc.d/init.d/ypbind preun-without-chkconfig /etc/rc.d/init.d/ypbind Is this just rpmlint problem or should I change %post and %preun sections somehow?
%post and %preun sections in spec file:
%post /bin/systemctl enable %{name}.service || :
%preun if [ $1 -eq 0 ] ; then /bin/systemctl stop %{name}.service >/dev/null 2>&1 || : /bin/systemctl disable %{name}.service >/dev/null 2>&1 || : fi
2) there is some code before and after starting the daemon in former SysV init script, which should be executed even when using systemd unit file. I created two scripts, placed them to /usr/lib/ypbind/ and add them to "ExecStartPre:" in ypbind.service file. Is this correct solution or there is a better one to execute more complicated scripts before/after daemon script itself?
Regards,
Honza
Hi,
2011/4/13 Honza Horak hhorak@redhat.com:
Hi,
I'm working on systemd unit file for ypbind and found some problems, that I'm not sure about:
- if I use systemctl enable/disable instead of chkconfig in %post and
%preun sections in spec file, rpmlint prints errors: postin-without-chkconfig /etc/rc.d/init.d/ypbind preun-without-chkconfig /etc/rc.d/init.d/ypbind Is this just rpmlint problem or should I change %post and %preun sections somehow?
%post and %preun sections in spec file:
%post /bin/systemctl enable %{name}.service || :
%preun if [ $1 -eq 0 ] ; then /bin/systemctl stop %{name}.service >/dev/null 2>&1 || : /bin/systemctl disable %{name}.service >/dev/null 2>&1 || : fi
- there is some code before and after starting the daemon in former
SysV init script, which should be executed even when using systemd unit file. I created two scripts, placed them to /usr/lib/ypbind/ and add them to "ExecStartPre:" in ypbind.service file. Is this correct solution or there is a better one to execute more complicated scripts before/after daemon script itself?
This is the most correct solution
Regards,
Honza
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, Apr 13, 2011 at 08:00:33PM +0200, Michał Piotrowski wrote:
Hi,
2011/4/13 Honza Horak hhorak@redhat.com:
Hi,
I'm working on systemd unit file for ypbind and found some problems, that I'm not sure about:
- if I use systemctl enable/disable instead of chkconfig in %post and
%preun sections in spec file, rpmlint prints errors: postin-without-chkconfig /etc/rc.d/init.d/ypbind preun-without-chkconfig /etc/rc.d/init.d/ypbind Is this just rpmlint problem or should I change %post and %preun sections somehow?
%post and %preun sections in spec file:
%post /bin/systemctl enable %{name}.service || :
%preun if [ $1 -eq 0 ] ; then /bin/systemctl stop %{name}.service >/dev/null 2>&1 || : /bin/systemctl disable %{name}.service >/dev/null 2>&1 || : fi
Sounds like you have the /etc/rc.d/init.d/ypbind file in the same package as the systemd service file. Change that and this will likely go away.
-Toshio
On Wed, 13.04.11 19:55, Honza Horak (hhorak@redhat.com) wrote:
Hi,
I'm working on systemd unit file for ypbind and found some problems, that I'm not sure about:
- if I use systemctl enable/disable instead of chkconfig in %post and
%preun sections in spec file, rpmlint prints errors: postin-without-chkconfig /etc/rc.d/init.d/ypbind preun-without-chkconfig /etc/rc.d/init.d/ypbind Is this just rpmlint problem or should I change %post and %preun sections somehow?
Yes, this looks like something that needs to be fixed in rpmlint eventually.
- there is some code before and after starting the daemon in former
SysV init script, which should be executed even when using systemd unit file. I created two scripts, placed them to /usr/lib/ypbind/ and add them to "ExecStartPre:" in ypbind.service file. Is this correct solution or there is a better one to execute more complicated scripts before/after daemon script itself?
In an ideal world the daemon binary itself does what is needed to start up. In the real world ExecStartPre= is indeed what you should be using, if your daemon isn't ideal (yet).
Lennart
On 04/13/2011 05:55 PM, Honza Horak wrote:
Hi,
I'm working on systemd unit file for ypbind and found some problems, that I'm not sure about:
It would be good if maintainers could take their time and assign themselves to their components here [1] if they have the time to convert old sysv to a native systemd native one so those of us that are helping out and converting old sysv can better focus our efforts on those maintainers that dont have that time.
It also would be good if maintainers that have received native systemd service files would package and push them into rawhide as soon as possible.
Thanks
JBG
1.http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability
2011/4/13 "Jóhann B. Guðmundsson" johannbg@gmail.com:
It would be good if maintainers could take their time and assign themselves to their components here [1] if they have the time to convert old sysv to a native systemd native one so those of us that are helping out and converting old sysv can better focus our efforts on those maintainers that dont have that time.
It also would be good if maintainers that have received native systemd service files would package and push them into rawhide as soon as possible.
"It would be good if" the packaging guidelines were finalized first. Mirek
On Wed, 13.04.11 22:55, Miloslav Trmač (mitr@volny.cz) wrote:
2011/4/13 "Jóhann B. Guðmundsson" johannbg@gmail.com:
It would be good if maintainers could take their time and assign themselves to their components here [1] if they have the time to convert old sysv to a native systemd native one so those of us that are helping out and converting old sysv can better focus our efforts on those maintainers that dont have that time.
It also would be good if maintainers that have received native systemd service files would package and push them into rawhide as soon as possible.
"It would be good if" the packaging guidelines were finalized first.
The basic guidelines for packaging of systemd services have been approved by the FPC.
Lennart
On Wed, Apr 13, 2011 at 11:00:18PM +0200, Lennart Poettering wrote:
On Wed, 13.04.11 22:55, Miloslav Trmač (mitr@volny.cz) wrote:
2011/4/13 "Jóhann B. Guðmundsson" johannbg@gmail.com:
It would be good if maintainers could take their time and assign themselves to their components here [1] if they have the time to convert old sysv to a native systemd native one so those of us that are helping out and converting old sysv can better focus our efforts on those maintainers that dont have that time.
It also would be good if maintainers that have received native systemd service files would package and push them into rawhide as soon as possible.
"It would be good if" the packaging guidelines were finalized first.
The basic guidelines for packaging of systemd services have been approved by the FPC.
But very explicitly, not the guidelines for converting a service from sysv to systemd.
-Toshio
On 04/13/2011 09:17 PM, Toshio Kuratomi wrote:
On Wed, Apr 13, 2011 at 11:00:18PM +0200, Lennart Poettering wrote:
On Wed, 13.04.11 22:55, Miloslav Trmač (mitr@volny.cz) wrote:
2011/4/13 "Jóhann B. Guðmundsson"johannbg@gmail.com:
It would be good if maintainers could take their time and assign themselves to their components here [1] if they have the time to convert old sysv to a native systemd native one so those of us that are helping out and converting old sysv can better focus our efforts on those maintainers that dont have that time.
It also would be good if maintainers that have received native systemd service files would package and push them into rawhide as soon as possible.
"It would be good if" the packaging guidelines were finalized first.
The basic guidelines for packaging of systemd services have been approved by the FPC.
But very explicitly, not the guidelines for converting a service from sysv to systemd.
Is this something that we that are converting the sysv init file to a native systemd one have to follow?
Is there a draft for that guidline somewhere?
Note I was refering to rawhide and as soon as possible.
With my QA hat on it's arguably to late in the F15 release cycle to introduce any native systemd service file at this point.
Thanks
JBG
On Wed, Apr 13, 2011 at 09:41:58PM +0000, "Jóhann B. Guðmundsson" wrote:
On 04/13/2011 09:17 PM, Toshio Kuratomi wrote:
On Wed, Apr 13, 2011 at 11:00:18PM +0200, Lennart Poettering wrote:
On Wed, 13.04.11 22:55, Miloslav Trmač (mitr@volny.cz) wrote:
2011/4/13 "Jóhann B. Guðmundsson"johannbg@gmail.com:
It would be good if maintainers could take their time and assign themselves to their components here [1] if they have the time to convert old sysv to a native systemd native one so those of us that are helping out and converting old sysv can better focus our efforts on those maintainers that dont have that time.
It also would be good if maintainers that have received native systemd service files would package and push them into rawhide as soon as possible.
"It would be good if" the packaging guidelines were finalized first.
The basic guidelines for packaging of systemd services have been approved by the FPC.
But very explicitly, not the guidelines for converting a service from sysv to systemd.
Is this something that we that are converting the sysv init file to a native systemd one have to follow?
If asked, I would say yes. However, read my comment at the end.
Is there a draft for that guidline somewhere?
Yep.
https://fedoraproject.org/wiki/User:Toshio/Systemd_scriptlet_options
Note I was refering to rawhide and as soon as possible.
With my QA hat on it's arguably to late in the F15 release cycle to introduce any native systemd service file at this point.
It's possible that any conversions done before the guidelines have been finalized would have to be redone (or even reverted) as they haven't been tested yet and there could be cornercases that will rquire them to be updated (there's definitely been cornercases encountered before we got the current form). However, for rawhide, I don't think that we'll hit the worst case (reversion) -- there's just the chance that we'd have to find every package that's doing an upgrade from sysv to systemd and change what it's doing to match the final form. From the problems that have shown themselves with past versions of these scriptlets, the bugs that we're likely to encounter will won't leave us the luxury of grandfathering packages that are using prior versions of the scriptlets -- we'll likely have to make any package using old versions of the scriptlets change to using a new, fixed version.
With that in mind, I think that selective updating in rawhide could be helpful to finalizing the guidelines. Just be sure to be on the lookout for corner cases, if you find something wrong, vaguely not the way you think it should be, etc, report it to the FPC with as close to what you did to make the problem reproducible, and finally, be sure to keep track of what packages you've converted as they may need to be updated to use the latest version of the scriptlets.
-Toshio
Hi,
I have similar question (sorry for stealing this thread). I have package that has 3 services (they somehow depend on each other). Based on configuration in /etc/sysconfig/.. file it starts 2 or 3 services. This is handled by init script, but I don't know how to do it in systemd service file. AFAIK: a) EnvironmentFile=... ExecStart=[ -n "$DRIVER" ] && /start/driver/... ExecStart=[ -n "$BACKEND" ] && /start/backend/... ExecStart=[ -n "$MONITOR" ] && /start/monitor/...
won't work, because ExecStart must be path, not shell command
b) ExecStart=/usr/libexec/%{name}/startifset "$DRIVER" /start/driver ExecStart=/usr/libexec/%{name}/startifset "$BACKEND" /start/backend ExecStart=/usr/libexec/%{name}/startifset "$MONITOR" /start/monitor
won't work, because there ExecStart can't be used more than once, except with type=oneshot, which does not work here
c) ExecStart=/usr/libexec/nut/startthemall
this is only workable solution I know (for now), but I don't know if it's the best one
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do, because dependency can change with configuration
Is there a good solution for this?
Michal
On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote:
Is there a good solution for this?
Which service ( file ) is this.
I can take a look at to see which way is best to approach it.
It's package nut : /etc/init.d/ups, there are 3 services: driver, upsd and upsmon. All three services usually run on the same machine, but it's not the only use case. There is going to be slight change for yet another use case. Better not to get inspired by init script, but think about situation where there are three services and some/all of them should be started based on variable in config file (so existing configuration works).
On Thu, 14.04.11 12:55, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote:
Is there a good solution for this?
Which service ( file ) is this.
I can take a look at to see which way is best to approach it.
It's package nut : /etc/init.d/ups, there are 3 services: driver, upsd and upsmon. All three services usually run on the same machine, but it's not the only use case. There is going to be slight change for yet another use case. Better not to get inspired by init script, but think about situation where there are three services and some/all of them should be started based on variable in config file (so existing configuration works).
I think it is a good idea to enable/disable services only at once place, the init system, instead of adding additional per-service layers of disabling. An admin should not have to know how each service is specifically configured in detail just to enable or disable it.
That means: if the admin enabels a service in systemd, the startup script should not refuse starting just because it is disabled in another config layer. That would be very confusing.
Lennart
On Thu, 14 Apr 2011 15:28:28 +0200 Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 14.04.11 12:55, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 09:54:59 Jóhann B. Guðmundsson wrote:
Is there a good solution for this?
Which service ( file ) is this.
I can take a look at to see which way is best to approach it.
It's package nut : /etc/init.d/ups, there are 3 services: driver, upsd and upsmon. All three services usually run on the same machine, but it's not the only use case. There is going to be slight change for yet another use case. Better not to get inspired by init script, but think about situation where there are three services and some/all of them should be started based on variable in config file (so existing configuration works).
I think it is a good idea to enable/disable services only at once place, the init system, instead of adding additional per-service layers of disabling. An admin should not have to know how each service is specifically configured in detail just to enable or disable it.
While this make sense in abstract, it may fall short when it comes to specific cases.
It really comes down to defining "service". For an admin "service" is generally a (set of) program(s) that performs a function. Whether the service requires one or three daemons is generally not really interesting for the admin unless he wants to dig the details.
In particular having to know which of three daemons to enable given a specific configuration is burdensome, as the admin now have to learn which one is required depending on the configuration. For some services this may be straightforward, for others not. And being forced to learn that is not really nice, esp. if it was not necessary before.
It is particularly obnoxious if you have to remember to change a different configuration (the init system) if you are just changing your service configuration.
That means: if the admin enabels a service in systemd, the startup script should not refuse starting just because it is disabled in another config layer. That would be very confusing.
And yet the contrary is also true, see above.
Systemd needs to offer a way to handle these situation until most distributions decide to adopt systemd. Because upstream has to deal primarily with sysvinit, and many will not care about systemd until it is widespread. You cannot expect package maintainers to heavily patch software and even change how it behaves or how it is configured just because Fedora decided to use systemd.
Where it is possible to easily switch to systmed, I am all for providing specific configuration and adaptation, but systemd needs to cater for the needs of software that is developed primarily on sysvinit based systems.
Simo.
On Thu, 14.04.11 09:51, Simo Sorce (ssorce@redhat.com) wrote:
Systemd needs to offer a way to handle these situation until most distributions decide to adopt systemd. Because upstream has to deal primarily with sysvinit, and many will not care about systemd until it is widespread.
The way it looks from the big names only Ubuntu ist left which is not working on systemd adoption in their distro.
You cannot expect package maintainers to heavily patch software and even change how it behaves or how it is configured just because Fedora decided to use systemd.
Well, you can always continue to use sysv scripts if you want sysv behaviour.
Lennart
On 04/14/2011 11:14 AM, Michal Hlavinka wrote:
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do,
Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for. I can imagine a %triggerun script looking at the old configuration file and then enabling the new services as required.
because dependency can change with configuration
Can you elaborate on this?
What kind of dependencies exist between the three services? Are they 3 separate daemons? How exactly do they communicate with each other? Can they be patched to use socket activation? Because then you could simply stop thinking about expressing the dependencies manually.
Also note that there are two distinct kinds of dependencies: requirements and ordering. I don't think ordering dependencies change depending on the configuration, or do they?
Michal
On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote:
On 04/14/2011 11:14 AM, Michal Hlavinka wrote:
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do,
Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for.
Upstream has their cross-distribution packaging "guidelines" / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way.
because dependency can change with configuration
Can you elaborate on this?
a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one
What kind of dependencies exist between the three services? Are they 3 separate daemons? How exactly do they communicate with each other?
upsd requires ups driver, upsmon requires upsd (but can be upsd from different machine), on machine where upsd and ups driver run there usualy is upsmon, but it can be on different machine.
Can they be patched to use socket activation? Because then you could simply stop thinking about expressing the dependencies manually.
Somehow, but you still need to decide whether to start upsmon (which maybe starts upsd and the driver) or start just upsd and driver "manualy" without upsmon.
And as I said above, this must be done the way that won't break existing configuration.
Also note that there are two distinct kinds of dependencies: requirements and ordering. I don't think ordering dependencies change depending on the configuration, or do they?
Somehow. Upsmon can require upsd or not based on configuration, but it does not say anything whether upsd should run or not (if it is not required).
On Thu, 14.04.11 14:51, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote:
On 04/14/2011 11:14 AM, Michal Hlavinka wrote:
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do,
Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for.
Upstream has their cross-distribution packaging "guidelines" / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way.
I presume their guidelines just cover SysV-style bootups?
Ideally the systemd unit files are shipped with the upstream packages. In this case if upstream is interested in keeping things identical among distributions it might be easy to convince them to integrate such a patch which gets things right?
because dependency can change with configuration
Can you elaborate on this?
a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one
What kind of dependencies exist between the three services? Are they 3 separate daemons? How exactly do they communicate with each other?
upsd requires ups driver, upsmon requires upsd (but can be upsd from different machine), on machine where upsd and ups driver run there usualy is upsmon, but it can be on different machine.
If upsd strictly requires ups driver, then a Requires= directive in its unit file is a good idea.
Somehow, but you still need to decide whether to start upsmon (which maybe starts upsd and the driver) or start just upsd and driver "manualy" without upsmon.
Levae that to the user by invoking "systemctl enable" on either both or just one of the units.
Lennart
On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote:
On Thu, 14.04.11 14:51, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote:
On 04/14/2011 11:14 AM, Michal Hlavinka wrote:
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do,
Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for.
Upstream has their cross-distribution packaging "guidelines" / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way.
I presume their guidelines just cover SysV-style bootups?
It's not only about SysV, but also says something like: when user starts nut, it should start exactly those services that are needed based on /etc/sysconfig/nut MODE=? option
In old script one just say he wants to use mode foo and script starts required services (one of the free).
Also I don't see how is this different from for example dovecot (pop3 and imap server) where master process starts auth, imapd, pop3d,... there just is no master process. This was handled by init script, because it was sufficient for this job. So it seems that systemd is not capable of doing this and "master" script will solve this.
What kind of dependencies exist between the three services? Are they 3 separate daemons? How exactly do they communicate with each other?
upsd requires ups driver, upsmon requires upsd (but can be upsd from different machine), on machine where upsd and ups driver run there usualy is upsmon, but it can be on different machine.
If upsd strictly requires ups driver, then a Requires= directive in its unit file is a good idea.
If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops?
On 04/14/2011 02:35 PM, Michal Hlavinka wrote:
If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops?
I think that you would use BindTo= instead of Requires= in upsd.service ( that is if uspd is depend upon them being running = ) along with ExecStop=
In man systemd.unit
BindTo= Configures requirement dependencies, very similar in style to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd.
ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service
JBG
On Thu, 14.04.11 14:57, "Jóhann B. Guðmundsson" (johannbg@gmail.com) wrote:
On 04/14/2011 02:35 PM, Michal Hlavinka wrote:
If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops?
I think that you would use BindTo= instead of Requires= in upsd.service ( that is if uspd is depend upon them being running = ) along with ExecStop=
In man systemd.unit
BindTo= Configures requirement dependencies, very similar in style to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd.
ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service
Why ExecStop= here?
Lennart
On 04/14/2011 03:36 PM, Lennart Poettering wrote:
In man systemd.unit
BindTo= Configures requirement dependencies, very similar in style
to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd.
ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service
Why ExecStop= here?
It was meant as an either or.
The BindTo= reference in the man page does not mention that it will take down with it any service bound to it when the service is stop.
The man page only states that if any of the service bound to it for one reason or another fails the service will be stopped at least that's the meaning I get when reading the BindTo= section in systemd.unit
JBG
On Thu, 14.04.11 16:15, "Jóhann B. Guðmundsson" (johannbg@gmail.com) wrote:
On 04/14/2011 03:36 PM, Lennart Poettering wrote:
In man systemd.unit
BindTo= Configures requirement dependencies, very similar in style
to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd.
ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service
Why ExecStop= here?
It was meant as an either or.
The BindTo= reference in the man page does not mention that it will take down with it any service bound to it when the service is stop.
Requires= and BindTo= both do that.
The difference between the two switches is mostly an ordering issue:
Let's say you have a unit A and a unit B. B requires A, and should be started after A is up. So in B you say:
Requires=A After=A
now, if you shut down A with "systemctl stop A", this will also stop B, and it will do so in the inverse starting order. i.e. stop B first, stop A second. BindTo= would do exactly the same here. The difference now comes if for some reason A dies independently of anybody running "systemctl stop A": should we then shut down B retroactviely? The ordering would normally suggest that B goes down before A, but if A just goes away on its own, then should we still shut down B? If you use BindTo= that's what would happen. If you use Requires= it wouldn't.
So where is this interesting? If A is a device and B is a service, then normally B should start after A is plugged in and be killed before A is unplugged. By using BindTo= you can also make it be killed if A is unplugged with B still running.
Lennart
On Thursday, April 14, 2011 19:54:36 Lennart Poettering wrote:
On Thu, 14.04.11 16:15, "Jóhann B. Guðmundsson" (johannbg@gmail.com) wrote:
On 04/14/2011 03:36 PM, Lennart Poettering wrote:
In man systemd.unit
BindTo= Configures requirement dependencies, very similar in style
to Requires=, however in addition to this behaviour it also declares that this unit is stopped when any of the units listed suddenly disappears. Units can suddenly, unexpectedly disappear if a service terminates on its own choice, a device is unplugged or a mount point unmounted without involvement of systemd.
ExecStop=-/bin/systemctl stop upsd-device.service ExecStop=-/bin/systemctl stop upsd-monitor.service
Why ExecStop= here?
It was meant as an either or.
The BindTo= reference in the man page does not mention that it will take down with it any service bound to it when the service is stop.
Requires= and BindTo= both do that.
The difference between the two switches is mostly an ordering issue:
Let's say you have a unit A and a unit B. B requires A, and should be started after A is up. So in B you say:
Requires=A After=A
Why is "After=" required here? If B Requires A it seem obvious that B should be started After A (if there is no socket magic).
now, if you shut down A with "systemctl stop A", this will also stop B, and it will do so in the inverse starting order. i.e. stop B first, stop A second. BindTo= would do exactly the same here. The difference now comes if for some reason A dies independently of anybody running "systemctl stop A": should we then shut down B retroactviely? The ordering would normally suggest that B goes down before A, but if A just goes away on its own, then should we still shut down B? If you use BindTo= that's what would happen. If you use Requires= it wouldn't.
That's not exactly what I'd like to know. Lets say there are services A and B. When B is started, A must be running, so B requires A, but when B is stopped, it should stop A. So A is started only on demand, but it should not be running if there is nothing that requires it.
On Fri, 15.04.11 07:03, Michal Hlavinka (mhlavink@redhat.com) wrote:
It was meant as an either or.
The BindTo= reference in the man page does not mention that it will take down with it any service bound to it when the service is stop.
Requires= and BindTo= both do that.
The difference between the two switches is mostly an ordering issue:
Let's say you have a unit A and a unit B. B requires A, and should be started after A is up. So in B you say:
Requires=A After=A
Why is "After=" required here? If B Requires A it seem obvious that B should be started After A (if there is no socket magic).
Requirement and ordering dependencies in systemd are orthogonal.
This is useful at various places.
For example, you can have req deps without ordering, which is for example handy for cases like this: think CK and gdm. gdm uses CK, but due to bus activation doesn't need to be started after it. In fact we can get away without not having any dep between the two, because bus activation would start CK as soon as it is needed. However, if we add a Wants dep without any ordering from gdm to CK we can optimize things a little: CK would be started as soon as possible, but gdm not delayed for it. There's a big chance then that CK might already be ready to process requests at the time gdm needs it.
Or you can have a req dep with a Before ordering. Think an sql server plus a monitoring service for the sql server. The monitoring service should always be started when your SQL server is started, too. But the monitoring service should be started after the SQL server, since it connects to it.
And thus you have use cases for all three cases: Wants/Requires plus After, Wants/Requires with no ordering, and Wants/Requires plus Before.
And of course, very often an After/Before without Wants/Requires also makes sense.
If you put all this together then it is easy to see why ordering and requirement are made orthogonal in systemd.
now, if you shut down A with "systemctl stop A", this will also stop B, and it will do so in the inverse starting order. i.e. stop B first, stop A second. BindTo= would do exactly the same here. The difference now comes if for some reason A dies independently of anybody running "systemctl stop A": should we then shut down B retroactviely? The ordering would normally suggest that B goes down before A, but if A just goes away on its own, then should we still shut down B? If you use BindTo= that's what would happen. If you use Requires= it wouldn't.
That's not exactly what I'd like to know. Lets say there are services A and B. When B is started, A must be running, so B requires A, but when B is stopped, it should stop A. So A is started only on demand, but it should not be running if there is nothing that requires it.
In general we try to avoid work if we can. That includes that we don't stop services unless we have to. Often it is nicer to just leave a service running when it hangs in a poll() and is swapped out than to start/stop it all the time.
That said, systemd wouldn't be systemd if it wouldn't cover your case too, if you really want. Set "StopWhenUnneeded=yes" in a unit and it will be stopped as soon as nothing runs anymore that needs it. Defaults to "no".
But I think in the general case this isn't really something you want to use much.
Lennart
now, if you shut down A with "systemctl stop A", this will also stop B, and it will do so in the inverse starting order. i.e. stop B first, stop A second. BindTo= would do exactly the same here. The difference now comes if for some reason A dies independently of anybody running "systemctl stop A": should we then shut down B retroactviely? The ordering would normally suggest that B goes down before A, but if A just goes away on its own, then should we still shut down B? If you use BindTo= that's what would happen. If you use Requires= it wouldn't.
That's not exactly what I'd like to know. Lets say there are services A and B. When B is started, A must be running, so B requires A, but when B is stopped, it should stop A. So A is started only on demand, but it should not be running if there is nothing that requires it.
In general we try to avoid work if we can. That includes that we don't stop services unless we have to. Often it is nicer to just leave a service running when it hangs in a poll() and is swapped out than to start/stop it all the time.
That said, systemd wouldn't be systemd if it wouldn't cover your case too, if you really want. Set "StopWhenUnneeded=yes" in a unit and it will be stopped as soon as nothing runs anymore that needs it. Defaults to "no".
But I think in the general case this isn't really something you want to use much.
There is a good reason for case where service need exclusive access to some resources (device,port,...), because you can't start different service until first one stops. For example with nut (ups daemon) driver must release ups device so when you want to try different ups daemon (for example apcupsd) ups device is not used by anything
On Thu, 14.04.11 16:35, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote:
On Thu, 14.04.11 14:51, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote:
On 04/14/2011 11:14 AM, Michal Hlavinka wrote:
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do,
Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for.
Upstream has their cross-distribution packaging "guidelines" / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way.
I presume their guidelines just cover SysV-style bootups?
It's not only about SysV, but also says something like: when user starts nut, it should start exactly those services that are needed based on /etc/sysconfig/nut MODE=? option
/etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure the Debian version of the boot scripts do not honour this request.
Also I don't see how is this different from for example dovecot (pop3 and imap server) where master process starts auth, imapd, pop3d,... there just is no master process. This was handled by init script, because it was sufficient for this job. So it seems that systemd is not capable of doing this and "master" script will solve this.
Dovecot upstream actually comes with systemd support including socket activation. I haven't tried it myself but it sounds as if dovecot is perfectly compatible with systemd ;-)
If upsd strictly requires ups driver, then a Requires= directive in its unit file is a good idea.
If I use Requires= directive, it starts driver for upsd, but is it possible to specify to stop the driver when upsd stops?
Yes, as was pointed out BindTo= can do that for you.
Lennart
On Thu, Apr 14, 2011 at 05:31:35PM +0200, Lennart Poettering wrote:
On Thu, 14.04.11 16:35, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote:
On Thu, 14.04.11 14:51, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote:
On 04/14/2011 11:14 AM, Michal Hlavinka wrote:
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do,
Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for.
Upstream has their cross-distribution packaging "guidelines" / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way.
I presume their guidelines just cover SysV-style bootups?
It's not only about SysV, but also says something like: when user starts nut, it should start exactly those services that are needed based on /etc/sysconfig/nut MODE=? option
/etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure the Debian version of the boot scripts do not honour this request.
Debian has mostly identical /etc/default/xxx.
Also I don't see how is this different from for example dovecot (pop3 and imap server) where master process starts auth, imapd, pop3d,... there just is no master process. This was handled by init script, because it was sufficient for this job. So it seems that systemd is not capable of doing this and "master" script will solve this.
Dovecot upstream actually comes with systemd support including socket activation. I haven't tried it myself but it sounds as if dovecot is perfectly compatible with systemd ;-)
I'm using F15 dovecot package on F14. Works perfectly. (F14 dovecot package omits unit files).
On 04/14/2011 04:19 PM, Tomasz Torcz wrote:
/etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure
the Debian version of the boot scripts do not honour this request.
Debian has mostly identical /etc/default/xxx.
Perhaps the same team that look at /run changes can come back together and discuss this problem reach consciousness amongst distro about the right path and everbody fix it accordingly...
JBG
2011/4/14 "Jóhann B. Guðmundsson" johannbg@gmail.com:
On 04/14/2011 04:19 PM, Tomasz Torcz wrote:
/etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure
the Debian version of the boot scripts do not honour this request.
Debian has mostly identical /etc/default/xxx.
Perhaps the same team that look at /run changes can come back together and discuss this problem reach consciousness amongst distro about the right path and everbody fix it accordingly...
I am afraid that something like that will not be possible in this case - I expect much resistance from the users :)
Of course, one common directory i.e /etc/services_config (or anything else with a better name) in all major distributions would be nice thing.
JBG
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, 14.04.11 18:40, Michał Piotrowski (mkkp4x4@gmail.com) wrote:
2011/4/14 "Jóhann B. Guðmundsson" johannbg@gmail.com:
On 04/14/2011 04:19 PM, Tomasz Torcz wrote:
/etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure
the Debian version of the boot scripts do not honour this request.
Debian has mostly identical /etc/default/xxx.
Perhaps the same team that look at /run changes can come back together and discuss this problem reach consciousness amongst distro about the right path and everbody fix it accordingly...
I am afraid that something like that will not be possible in this case
- I expect much resistance from the users :)
Of course, one common directory i.e /etc/services_config (or anything else with a better name) in all major distributions would be nice thing.
The place for system configuration is /etc. I have yet to see a really convincing example why /etc/sysconfig/ or /etc/default would win us anything. I am pretty sure that the vast majority of files in there are pretty much unnecessary and their configuration could be solved in a different way much nicer.
So yeah, I'd push for phasing /etc/sysconfig out for most services, not standardize it.
Lennart
Once upon a time, Lennart Poettering mzerqung@0pointer.de said:
The place for system configuration is /etc. I have yet to see a really convincing example why /etc/sysconfig/ or /etc/default would win us anything.
/etc/sysconfig is essentially configuration for the init system managing daemons. Command-line options, which sub-bits to run, etc. that are not settable in the daemon configuration files themselves.
I think having them in a sub-directory is much cleaner (and makes them easier to distinguish from the "regular" daemon config files). I don't think /etc/default is a good name (if that indeed is what Debian uses), because they are options you change to get non-default behavior.
I am pretty sure that the vast majority of files in there are pretty much unnecessary and their configuration could be solved in a different way much nicer.
I've used a bunch of them to change the ways various daemons run, so I would definately say they are not "pretty much unnecessary". They are also shell scripts that are sourced by init scripts, so there is flexibility to make changes that may not have even been anticipated by the init script authors.
Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either.
So yeah, I'd push for phasing /etc/sysconfig out for most services, not standardize it.
I'd be 180 degrees from that.
On Thu, 14.04.11 13:05, Chris Adams (cmadams@hiwaay.net) wrote:
Once upon a time, Lennart Poettering mzerqung@0pointer.de said:
The place for system configuration is /etc. I have yet to see a really convincing example why /etc/sysconfig/ or /etc/default would win us anything.
/etc/sysconfig is essentially configuration for the init system managing daemons. Command-line options, which sub-bits to run, etc. that are not settable in the daemon configuration files themselves.
Yes, but all of that can be configured in a much nicer way in systemd:
Copy /lib/systemd/system/foobar.service to /etc/systemd/system/foobar.service, and edit it there. You will have a short, easy to understand, super-flexible, very well documented way to edit service defaults. You can edit command lines, you may set a specific user id to run something as, you may set the CPU affinity or you can adjust the capability bounding set as you wish (among a lot of other stuff). You have the full range of configuration options systemd offers you, all in a very simple ini file.
Now, let's look at /etc/sysconfig/xxx. What you see is that only options that the init script explicitly supports you can change. On one service you might be able to change the command line arguments with this, on a different one you may change the user id, on a third one you may change the CPU affinity and a fourht one might allow you to the caps bounding set. But you do not find a single sysconfig file where you could actually configure all of these options. Also, the options tend to have different names even if they do the same, and slightly different behaviour.
systemd streamlines this. If you want to change the configuration of a specific service, you can do so with very minimal effort and great flexibility, and all of that without creating a completely new configuration language for it, or without needing specific support in the service startup logic. The configuration language for the admin and for upstream is the *same*.
Looking at the history of this: the reason /etc/sysconfig/xxx was created in the first place is that while /etc/init.d/xxx was initially more like configuration (and thus located in /etc) it ended up being more like actual code (which it is after all). So in order to avoid having to edit code to make configuration changes, and to not confuse the package manager /etc/sysconfig/xxx was split out of the actual sysv init scripts. In systemd that split is not necessary, and we should just embrace that instead of keeping /etc/sysconfig/xxx alive without need.
I think having them in a sub-directory is much cleaner (and makes them easier to distinguish from the "regular" daemon config files). I don't think /etc/default is a good name (if that indeed is what Debian uses), because they are options you change to get non-default behavior.
I have trouble seeing in which way /etc/nsswitch.conf was in any way more "regular" than /etc/nsswitch.conf,
I am pretty sure that the vast majority of files in there are pretty much unnecessary and their configuration could be solved in a different way much nicer.
I've used a bunch of them to change the ways various daemons run, so I would definately say they are not "pretty much unnecessary". They are also shell scripts that are sourced by init scripts, so there is flexibility to make changes that may not have even been anticipated by the init script authors.
Yeah, and that's the nice thing in systemd, if you want to make a change to a service file, just take it, edit it and enjoy the full power that systemd puts in your hands!
Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either.
Yupp, and this is much much prettier in systemd. After you copied the service file from /lib to /etc they are out of the package manager territory and will always override what has been configured by the distro packager. And if you want to return to the default settings you can just remove your file from /etc again and voila!
Lennart
On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 14.04.11 13:05, Chris Adams (cmadams@hiwaay.net) wrote:
Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either.
Yupp, and this is much much prettier in systemd. After you copied the service file from /lib to /etc they are out of the package manager territory and will always override what has been configured by the distro packager.
Separating the program that integrates software into the distribution (/etc/init.d/*) and user's configuration that is managed via .rpm{save,new} is actually valuable.
If upstream changes how the program should be invoked and the Fedora packager updates /etc/init.d/*, this change is transparent to users, as long as the chang doesn't affect the specifics of user's configuration in /etc/sysconfig - and even if it does, the user has .rpm{save,new} and can figure out what has happened.
Copying the service file from /lib to /etc seems to lose this property - if the /etc file "hides" the /lib file, the service will just break with no indication that something needs to be updated. Or does systemd support "inheritance" of configuration from /lib to /etc so that the user can only make the minimal changes necessary? Mirek
On Thu, 14 Apr 2011 20:35:07 +0200 Miloslav Trmač mitr@volny.cz wrote:
On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 14.04.11 13:05, Chris Adams (cmadams@hiwaay.net) wrote:
Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either.
Yupp, and this is much much prettier in systemd. After you copied the service file from /lib to /etc they are out of the package manager territory and will always override what has been configured by the distro packager.
Separating the program that integrates software into the distribution (/etc/init.d/*) and user's configuration that is managed via .rpm{save,new} is actually valuable.
If upstream changes how the program should be invoked and the Fedora packager updates /etc/init.d/*, this change is transparent to users, as long as the chang doesn't affect the specifics of user's configuration in /etc/sysconfig - and even if it does, the user has .rpm{save,new} and can figure out what has happened.
Copying the service file from /lib to /etc seems to lose this property
- if the /etc file "hides" the /lib file, the service will just break
with no indication that something needs to be updated. Or does systemd support "inheritance" of configuration from /lib to /etc so that the user can only make the minimal changes necessary? Mirek
I was going to make exactly the same objection. Now rpm scripts will have to check and possibly have to muck with the copies in /etc or risk that the service in question will fail to work after a major update.
Sounds like trading one set of issues for another set of potentially bigger issues.
Simo.
On Thu, 14.04.11 15:48, Simo Sorce (ssorce@redhat.com) wrote:
On Thu, 14 Apr 2011 20:35:07 +0200 Miloslav Trmač mitr@volny.cz wrote:
On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 14.04.11 13:05, Chris Adams (cmadams@hiwaay.net) wrote:
Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either.
Yupp, and this is much much prettier in systemd. After you copied the service file from /lib to /etc they are out of the package manager territory and will always override what has been configured by the distro packager.
Separating the program that integrates software into the distribution (/etc/init.d/*) and user's configuration that is managed via .rpm{save,new} is actually valuable.
If upstream changes how the program should be invoked and the Fedora packager updates /etc/init.d/*, this change is transparent to users, as long as the chang doesn't affect the specifics of user's configuration in /etc/sysconfig - and even if it does, the user has .rpm{save,new} and can figure out what has happened.
Copying the service file from /lib to /etc seems to lose this property
- if the /etc file "hides" the /lib file, the service will just break
with no indication that something needs to be updated. Or does systemd support "inheritance" of configuration from /lib to /etc so that the user can only make the minimal changes necessary? Mirek
I was going to make exactly the same objection. Now rpm scripts will have to check and possibly have to muck with the copies in /etc or risk that the service in question will fail to work after a major update.
Sounds like trading one set of issues for another set of potentially bigger issues.
Well, it's quite a bit different. Because an init script is a complex fragile beast you probably end up updating it quite often. OTOH a systemd unit file is just a few lines usually, which means there is much less to update. And due to magic stuff like socket and bus activation most deps don't have to be configured, so things are much more robus anyway...
Lennart
On Thu, 14.04.11 20:35, Miloslav Trmač (mitr@volny.cz) wrote:
On Thu, Apr 14, 2011 at 8:21 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Thu, 14.04.11 13:05, Chris Adams (cmadams@hiwaay.net) wrote:
Since they are config files (unlike the init scripts themselves), changing them doesn't leave you with RPM wanting to replace them on every package update either.
Yupp, and this is much much prettier in systemd. After you copied the service file from /lib to /etc they are out of the package manager territory and will always override what has been configured by the distro packager.
Separating the program that integrates software into the distribution (/etc/init.d/*) and user's configuration that is managed via .rpm{save,new} is actually valuable.
If upstream changes how the program should be invoked and the Fedora packager updates /etc/init.d/*, this change is transparent to users, as long as the chang doesn't affect the specifics of user's configuration in /etc/sysconfig - and even if it does, the user has .rpm{save,new} and can figure out what has happened.
Well, the simple fact is that systemd unit files aren't really code. They are just config. So doing code updates on a sysv init script does not really translate to systemd, because there is nothing to update.
Copying the service file from /lib to /etc seems to lose this property
- if the /etc file "hides" the /lib file, the service will just break
with no indication that something needs to be updated. Or does systemd support "inheritance" of configuration from /lib to /etc so that the user can only make the minimal changes necessary?
Yes, you can use ".include /lib/systemd/system/foo.service" to import another file, and then override selected settings.
Note however that while some settings override others some act as additions. Example: A later User=foo will override an earlier User=bar, but a later Requires=foo will be added to an earlier Requires=bar, so that you effectively have "Requires=foo bar". But I think it's kinda obvious in most cases which settings are those with work as an addition and which ones override.
Lennart
On Fri, 2011-04-15 at 00:23 +0200, Lennart Poettering wrote:
Note however that while some settings override others some act as additions. Example: A later User=foo will override an earlier User=bar, but a later Requires=foo will be added to an earlier Requires=bar, so that you effectively have "Requires=foo bar". But I think it's kinda obvious in most cases which settings are those with work as an addition and which ones override.
Is that as obvious as: 1. If the parameter can be used only once (single value), a later usage will override it 2. If the parameter can be used multiple times (list of values), a later usage will be appended
Or is there some special inclusion/inheritance magic?
On Fri, 15.04.11 09:59, Mathieu Bridon (bochecha@fedoraproject.org) wrote:
On Fri, 2011-04-15 at 00:23 +0200, Lennart Poettering wrote:
Note however that while some settings override others some act as additions. Example: A later User=foo will override an earlier User=bar, but a later Requires=foo will be added to an earlier Requires=bar, so that you effectively have "Requires=foo bar". But I think it's kinda obvious in most cases which settings are those with work as an addition and which ones override.
Is that as obvious as: 1. If the parameter can be used only once (single value), a later usage will override it 2. If the parameter can be used multiple times (list of values), a later usage will be appended
Yes, precisely.
Lennart
On 04/14/2011 12:51 PM, Michal Hlavinka wrote:
Can you elaborate on this?
a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one
Looking at the old sysv it only does 2 things...
if the $SERVER = yes in /etc/sysconfig/ups then start upsd driver upsd and upsd monitor.
If the $SERVER != yes in /etc/sysconfig/ups then only start the monitor service
start() { if [ "$SERVER" = "yes" ]; then echo -n $"Starting UPS driver controller: " daemon /sbin/upsdrvctl start > /dev/null 2>&1 && success || failure RETVAL=$? echo
prog="upsd" echo -n $"Starting $prog: " daemon /usr/sbin/upsd $UPSD_OPTIONS > /dev/null 2>&1 && success || failure if [ "$RETVAL" = 0 ]; then RETVAL=$? fi echo
echo -n $"Starting UPS monitor (master): " daemon --pidfile /var/run/nut/upsmon.pid /usr/sbin/upsmon > /dev/null 2>&1 && success || failure if [ "$RETVAL" = 0 ]; then RETVAL=$? fi echo else echo -n $"Starting UPS monitor (slave): " daemon --pidfile /var/run/nut/upsmon.pid /usr/sbin/upsmon > /dev/null 2>&1 && success || failure echo fi
[ "$RETVAL" = 0 ] && touch /var/lock/subsys/ups }
The only difference between usps-monitor in master mode and slave mode is the "echo (master)"/"echo (slave)"
Now I've splitted this into three systemd services upsd.service upsd-driver.service and upsd-monitor
upsd.service which if run will start uspd upsd-driver and the upsd-monitor this is the same behavior as if $SERVER = yes
upsd-driver.service is stand alone and can be started stopped etc all by it self
upsd-monitor.service is stand alone and can be started stopped etc all by it self.
Starting this service on it's own is the exact same behaviour if $SERVER != yes
This is as close and as correct transfer to systemd as it gets.
The $SERVER variable in /etc/sysconfig/ups is obsoleted
If end users wants the uspd server ( which by the way defaulted to yes so this even is not a breakage in default behaviour ) they only need to run
service upsd start or systemctl start upsd.service just ast they did before.
If they just want to use the monitor they just start the UPS Monitor service
And now they can even start the UPS driver controller only which they could not before.
JBG
On Thursday, April 14, 2011 14:46:01 Jóhann B. Guðmundsson wrote:
On 04/14/2011 12:51 PM, Michal Hlavinka wrote:
Can you elaborate on this?
a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one
Looking at the old sysv it only does 2 things...
As I said above - don't look at init script for analyzation because there are some options missing right now, there was going to be some change to support other use cases. It's better to focus on theoretical situation where you have 3 daemons started by one script based on one option in config file. That's all
Hi,
2011/4/14 Michal Hlavinka mhlavink@redhat.com:
On Thursday, April 14, 2011 14:46:01 Jóhann B. Guðmundsson wrote:
On 04/14/2011 12:51 PM, Michal Hlavinka wrote:
Can you elaborate on this?
a) ups driver - runs when you have ups attached to that host b) upsd - runs when you have ups attached to that host c) upsmon (master/slave mode) - usualy runs on machine where you have ups, but it can run on machine without ups or work with different ups than the attached one
Looking at the old sysv it only does 2 things...
As I said above - don't look at init script for analyzation because there are some options missing right now, there was going to be some change to support other use cases. It's better to focus on theoretical situation where you have 3 daemons started by one script based on one option in config file. That's all
I had such situation when I worked on shorewall scripts conversion. I just didn't converted main shorewall-init script. At that time, I just did not have idea how to run bash loop in systemd service :)
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 04/14/2011 03:14 PM, Michał Piotrowski wrote:
I had such situation when I worked on shorewall scripts conversion. I just didn't converted main shorewall-init script. At that time, I just did not have idea how to run bash loop in systemd service:)
Using bash loop within systemd is and should be only done because of absolute necessity for oddball cases and is a clear indicator if used that something needs fixing.
If upstream is unwilling to do the necessary work to fix the broken behaviour in their service then it's better to not convert the files to systemd et all and just use continue to use the sysv script as is.
JBG
On 04/14/2011 09:14 AM, Michal Hlavinka wrote:
Is there a good solution for this?
The right solution is to split this into three service files as I have done in bug 696611
then simply run
systemctl start/stop/restart/reload/enable upsd-master.service # for master ( which start the upsd-master and the upsd-driver service as was being done in the init script it will conflict with upsd-slave if it's running )
systemct start/stop/restart/reload/enable upsd-slave.service # for slave ( which will not start the upsd-driver service as was being done in the init script )
The upsd-driver should have been a seperate sysv service from the start from my pov but this is not the worst oddball I've come across...
JBG
On Thu, 14.04.11 11:14, Michal Hlavinka (mhlavink@redhat.com) wrote:
Hi,
I have similar question (sorry for stealing this thread). I have package that has 3 services (they somehow depend on each other). Based on configuration in /etc/sysconfig/.. file it starts 2 or 3 services. This is handled by init script, but I don't know how to do it in systemd service file. AFAIK: a) EnvironmentFile=... ExecStart=[ -n "$DRIVER" ] && /start/driver/... ExecStart=[ -n "$BACKEND" ] && /start/backend/... ExecStart=[ -n "$MONITOR" ] && /start/monitor/...
In a systemd world we try to normalize how services are maintained and managed. Ideally that means that you have a 1:1 mapping between service files and actual daemons. So instead of having three daemons spawned from a single sysv init script I'd encourage you to have three unit files spawning three daemons.
This normalizes behaviour in many ways, for example the user can individually enable/disable them, without an extra layer of enabling in an extra config file.
We want a single place where services can be enabled/disabled, not multiple at different layers.
Also, stuff like automatic restart and so on can only work correctly if you maintain each daemon in a seperate systemd service.
won't work, because ExecStart must be path, not shell command
b) ExecStart=/usr/libexec/%{name}/startifset "$DRIVER" /start/driver ExecStart=/usr/libexec/%{name}/startifset "$BACKEND" /start/backend ExecStart=/usr/libexec/%{name}/startifset "$MONITOR" /start/monitor
won't work, because there ExecStart can't be used more than once, except with type=oneshot, which does not work here
Yes, ExecStart= is for the "main" process of a service, the one which determines the lifetime of it.
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do, because dependency can change with configuration
Yes, d)!
Our primary goal with systemd is to get things right and normalized. Support the exact same behaviour as in SysV is not our top goal, because well, we aren't sysvinit and to sport 100% identical behaviour you'd have to be sysvinit.
Lennart