FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-08-2011, 02:57 AM
Steve Dickson
 
Default systemd: Is it wrong?

Hello,

One of the maintainers of systemd and I have been working
together on trying to convert the NFS SysV init scripts
into systemd services. Here is the long trail...

https://bugzilla.redhat.com/show_bug.cgi?id=699040

The point is this, with fairly complicated system,
some events need to have happen, like loading modules,
before other events happen, like setting parameters of
those loaded modules.

Currently the ExecStart commands can be started and end
before the ExecStartPre even start. This means setting
modules parameters within the same service file are
impossible.

I suggested that a boundary be set that all ExecStartPre
commands finish before any ExecStart commands start,
which would allow complicated subsystems, like NFS,
to start in a very stable way...

So is it wrong? Shouldn't there away to allow certain
parts of a system to synchronously configure some
things so other parts will come up as expected?

tia,

steved.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 10:47 AM
Neil Horman
 
Default systemd: Is it wrong?

On Thu, Jul 07, 2011 at 10:57:54PM -0400, Steve Dickson wrote:
> Hello,
>
> One of the maintainers of systemd and I have been working
> together on trying to convert the NFS SysV init scripts
> into systemd services. Here is the long trail...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=699040
>
> The point is this, with fairly complicated system,
> some events need to have happen, like loading modules,
> before other events happen, like setting parameters of
> those loaded modules.
>
> Currently the ExecStart commands can be started and end
> before the ExecStartPre even start. This means setting
> modules parameters within the same service file are
> impossible.
>
I would have though intuitively that Pre commands would complete prior to
ExecStart command in the same service file. To not do so seems like a bug to
me.
Neil

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 11:42 AM
JB
 
Default systemd: Is it wrong?

Steve Dickson <SteveD <at> redhat.com> writes:

> ...

Hi,

you are right about the synchronization problem within a service file exec
environment, at least as you showed it in that particular Bugzilla case.

Let's review it once again here (I am on F15), but I reserve the right to be
wrong as I have mostly ignored systemd for the time being :-)

Your nfslock.service file:

[Unit]
Description=NFS file locking service.
After=syslog.target network.target rpcbind.service
ConditionPathIsDirectory=/sys/module/sunrpc

[Service]
Type=forking
PIDFile=/var/run/sm-notify.pid
EnvironmentFile=/etc/sysconfig/nfsservices
ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStartPre=/sbin/rm -f /var/run/sm-notify.pid
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT
ExecStart=/sbin/rpc.statd $RPCSTATDARS
ExecStartPost=/sbin/sysctl -w fs.nfs.nlm_tcpport=0
ExecStartPost=/sbin/sysctl -w fs.nfs.nlm_udpport=0

[Install]
WantedBy=multi-user.target
Also=rpcbind.socket

or a variation of the above:

...
ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
...
ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
...

and the failure is:

$ systemctl status nfslock.service
nfslock.service - NFS file locking service.
Loaded: loaded (/lib/systemd/system/nfslock.service)
Active: failed since Thu, 07 Jul 2011 14:35:39 -0400; 28s ago
Process: 2186 ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
(code=exited, status=255)
Process: 2184 ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG (code=exited,
status=0/SUCCESS)
$

Yes, there is a potential problem as jobs can be created for execution in one
order, but actually scheduled for execution or executed in a different order.

So, what are the solutions ?

- in this particular case
There is a service file for that purpose already ?
$ cat /lib/systemd/system/systemd-modules-load.service
...
[Unit]
Description=Load Kernel Modules
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target
ConditionDirectoryNotEmpty=/etc/modules-load.d

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/systemd/systemd-modules-load
$

and this service file too ?
$ cat /lib/systemd/system/systemd-sysctl.service
...
[Unit]
Description=Apply Kernel Variables
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target
ConditionPathExists=|/etc/sysctl.conf
ConditionDirectoryNotEmpty=|/etc/sysctl.d

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/systemd/systemd-sysctl
$

The sys admin would:
- add a required lockd.conf to /etc/modules-load.d/
- edit /etc/sysctl with required param settings

I guess you could modify the nfslock.service file like this:
...
Requires=systemd-modules-load.service systemd-sysctl.service
...
After=syslog.target network.target rpcbind.service ystemd-modules-load.service
systemd-sysctl.service
...

and without these:
...
ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT
...

I hope that the env variables used by modprobe and 'sysctl -w' as used here
($LOCKDARG, $LOCKD_TCPPORT, $LOCKD_UDPPORT) would be available in the above
corresponding service execution envs as being "required" "sub-services"
(see Requires=... and After=...) to nfslock.service, which provides for
EnvironmentFile=/etc/sysconfig/nfsservices .

I hope that would work as desired, that is, synchronously.

- systemd has to manipulate SYSTEMD.EXEC(5) scheduling environment to make
sure that sequential execution as in a service file *means* synchronous
execution, with internal completion code checking and error processing.
Warning:
manipulating scheduling environment is always tricky and can cause
problems and complications, in particular in real-time environment, as
multithreading programming shows.
- perhaps systemd needs some conditional constructs to check for completion
code of commands executed (sequentially) in a service file.
e.g.
ExecStartPre="/sbin/modprobe -q lockd $LOCKDARG",SetOnError=error1
ExecStartPre="/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT",IfError=error1= 0

This would be useful here, but it appears to duplicate options from
systemd.unit(5) and systemd.service(5).

Well, systemd was supposed to simplify those silly and primitive bash-based
SysV and LSB system init environments, cure the lack of parallelism, etc ...
Sorry, just having a bad hair day :-)

JB

Maria Callas - Bellini - Il Pirata - Part 2 (Final Scene)
http://www.youtube.com/watch?v=KDQkgjzky44


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 11:42 AM
JB
 
Default systemd: Is it wrong?

Steve Dickson <SteveD <at> redhat.com> writes:

> ...

Hi,

you are right about the synchronization problem within a service file exec
environment, at least as you showed it in that particular Bugzilla case.

Let's review it once again here (I am on F15), but I reserve the right to be
wrong as I have mostly ignored systemd for the time being :-)

Your nfslock.service file:

[Unit]
Description=NFS file locking service.
After=syslog.target network.target rpcbind.service
ConditionPathIsDirectory=/sys/module/sunrpc

[Service]
Type=forking
PIDFile=/var/run/sm-notify.pid
EnvironmentFile=/etc/sysconfig/nfsservices
ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStartPre=/sbin/rm -f /var/run/sm-notify.pid
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT
ExecStart=/sbin/rpc.statd $RPCSTATDARS
ExecStartPost=/sbin/sysctl -w fs.nfs.nlm_tcpport=0
ExecStartPost=/sbin/sysctl -w fs.nfs.nlm_udpport=0

[Install]
WantedBy=multi-user.target
Also=rpcbind.socket

or a variation of the above:

...
ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
...
ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
...

and the failure is:

$ systemctl status nfslock.service
nfslock.service - NFS file locking service.
Loaded: loaded (/lib/systemd/system/nfslock.service)
Active: failed since Thu, 07 Jul 2011 14:35:39 -0400; 28s ago
Process: 2186 ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
(code=exited, status=255)
Process: 2184 ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG (code=exited,
status=0/SUCCESS)
$

Yes, there is a potential problem as jobs can be created for execution in one
order, but actually scheduled for execution or executed in a different order.

So, what are the solutions ?

- in this particular case
There is a service file for that purpose already ?
$ cat /lib/systemd/system/systemd-modules-load.service
...
[Unit]
Description=Load Kernel Modules
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target
ConditionDirectoryNotEmpty=/etc/modules-load.d

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/systemd/systemd-modules-load
$

and this service file too ?
$ cat /lib/systemd/system/systemd-sysctl.service
...
[Unit]
Description=Apply Kernel Variables
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target
ConditionPathExists=|/etc/sysctl.conf
ConditionDirectoryNotEmpty=|/etc/sysctl.d

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/systemd/systemd-sysctl
$

The sys admin would:
- add a required lockd.conf to /etc/modules-load.d/
- edit /etc/sysctl with required param settings

I guess you could modify the nfslock.service file like this:
...
Requires=systemd-modules-load.service systemd-sysctl.service
...
After=syslog.target network.target rpcbind.service ystemd-modules-load.service
systemd-sysctl.service
...

and without these:
...
ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT
...

I hope that the env variables used by modprobe and 'sysctl -w' as used here
($LOCKDARG, $LOCKD_TCPPORT, $LOCKD_UDPPORT) would be available in the above
corresponding service execution envs as being "required" "sub-services"
(see Requires=... and After=...) to nfslock.service, which provides for
EnvironmentFile=/etc/sysconfig/nfsservices .

I hope that would work as desired, that is, synchronously.

- systemd has to manipulate SYSTEMD.EXEC(5) scheduling environment to make
sure that sequential execution as in a service file *means* synchronous
execution, with internal completion code checking and error processing.
Warning:
manipulating scheduling environment is always tricky and can cause
problems and complications, in particular in real-time environment, as
multithreading programming shows.
- perhaps systemd needs some conditional constructs to check for completion
code of commands executed (sequentially) in a service file.
e.g.
ExecStartPre="/sbin/modprobe -q lockd $LOCKDARG",SetOnError=error1
ExecStartPre="/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT",IfError=error1= 0

This would be useful here, but it appears to duplicate options from
systemd.unit(5) and systemd.service(5).

Well, systemd was supposed to simplify those silly and primitive bash-based
SysV and LSB system init environments, cure the lack of parallelism, etc ...
Sorry, just having a bad hair day :-)

JB

Maria Callas - Bellini - Il Pirata - Part 2 (Final Scene)
http://www.youtube.com/watch?v=KDQkgjzky44


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 11:57 AM
"Jˇhann B. Gu­mundsson"
 
Default systemd: Is it wrong?

On 07/08/2011 10:47 AM, Neil Horman wrote:
> On Thu, Jul 07, 2011 at 10:57:54PM -0400, Steve Dickson wrote:
>> Hello,
>>
>> One of the maintainers of systemd and I have been working
>> together on trying to convert the NFS SysV init scripts
>> into systemd services. Here is the long trail...
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=699040
>>
>> The point is this, with fairly complicated system,
>> some events need to have happen, like loading modules,
>> before other events happen, like setting parameters of
>> those loaded modules.
>>
>> Currently the ExecStart commands can be started and end
>> before the ExecStartPre even start. This means setting
>> modules parameters within the same service file are
>> impossible.
>>
> I would have though intuitively that Pre commands would complete prior to
> ExecStart command in the same service file. To not do so seems like a bug to
> me.
> Neil
>

What I think got him confused was the order of execution he saw in the
status output which is reversed as in the first run command is at the
bottom and the last run command on the top..

A simple test case show that the commands are correctly ordered and
executed sequentially and after the other one has finished...

[Unit]
Description=Test ordering + time of Exec

[Service]
Type=oneshot
ExecStartPre=/usr/bin/logger 1
ExecStartPre=/bin/sleep 1
ExecStartPre=/usr/bin/logger 2
ExecStartPre=/bin/sleep 2
ExecStart=/usr/bin/logger 3
ExecStart=/bin/sleep 3
ExecStart=/usr/bin/logger 4
ExecStart=/bin/sleep 4
ExecStartPost=/usr/bin/logger 5
ExecStartPost=/bin/sleep 5
ExecStartPost=/usr/bin/logger 6
ExecStartPost=/bin/sleep 6
ExecStartPost=/usr/bin/logger 7
RemainAfterExit=yes

[root@valhalla system]# grep logger /var/log/messages
Jul 8 11:37:30 valhalla logger: 1
Jul 8 11:37:31 valhalla logger: 2 <-- waited for 1s
Jul 8 11:37:33 valhalla logger: 3 <-- waited for 2s
Jul 8 11:37:36 valhalla logger: 4 <-- waited for 3s
Jul 8 11:37:40 valhalla logger: 5 <-- waited for 4s
Jul 8 11:37:45 valhalla logger: 6 <-- waited for 5s
Jul 8 11:37:51 valhalla logger: 7 <-- waited for 6s
[root@valhalla system]#

test.service
Loaded: loaded (/lib/systemd/system/test.service)
Active: active (exited) since Fri, 08 Jul 2011 11:54:13 +0000; 3s ago
Process: 8754 ExecStartPost=/usr/bin/logger 7 (code=exited,
status=0/SUCCESS) <-- last
Process: 8752 ExecStartPost=/bin/sleep 6 (code=exited,
status=0/SUCCESS)
Process: 8750 ExecStartPost=/usr/bin/logger 6 (code=exited,
status=0/SUCCESS)
Process: 8748 ExecStartPost=/bin/sleep 5 (code=exited,
status=0/SUCCESS)
Process: 8746 ExecStartPost=/usr/bin/logger 5 (code=exited,
status=0/SUCCESS)
Process: 8743 ExecStart=/bin/sleep 4 (code=exited, status=0/SUCCESS)
Process: 8741 ExecStart=/usr/bin/logger 4 (code=exited,
status=0/SUCCESS)
Process: 8739 ExecStart=/bin/sleep 3 (code=exited, status=0/SUCCESS)
Process: 8737 ExecStart=/usr/bin/logger 3 (code=exited,
status=0/SUCCESS)
Process: 8735 ExecStartPre=/bin/sleep 2 (code=exited,
status=0/SUCCESS)
Process: 8733 ExecStartPre=/usr/bin/logger 2 (code=exited,
status=0/SUCCESS)
Process: 8731 ExecStartPre=/bin/sleep 1 (code=exited,
status=0/SUCCESS)
Process: 8729 ExecStartPre=/usr/bin/logger 1 (code=exited,
status=0/SUCCESS) <--- first
CGroup: name=systemd:/system/test.service


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 11:57 AM
"Jˇhann B. Gu­mundsson"
 
Default systemd: Is it wrong?

On 07/08/2011 10:47 AM, Neil Horman wrote:
> On Thu, Jul 07, 2011 at 10:57:54PM -0400, Steve Dickson wrote:
>> Hello,
>>
>> One of the maintainers of systemd and I have been working
>> together on trying to convert the NFS SysV init scripts
>> into systemd services. Here is the long trail...
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=699040
>>
>> The point is this, with fairly complicated system,
>> some events need to have happen, like loading modules,
>> before other events happen, like setting parameters of
>> those loaded modules.
>>
>> Currently the ExecStart commands can be started and end
>> before the ExecStartPre even start. This means setting
>> modules parameters within the same service file are
>> impossible.
>>
> I would have though intuitively that Pre commands would complete prior to
> ExecStart command in the same service file. To not do so seems like a bug to
> me.
> Neil
>

What I think got him confused was the order of execution he saw in the
status output which is reversed as in the first run command is at the
bottom and the last run command on the top..

A simple test case show that the commands are correctly ordered and
executed sequentially and after the other one has finished...

[Unit]
Description=Test ordering + time of Exec

[Service]
Type=oneshot
ExecStartPre=/usr/bin/logger 1
ExecStartPre=/bin/sleep 1
ExecStartPre=/usr/bin/logger 2
ExecStartPre=/bin/sleep 2
ExecStart=/usr/bin/logger 3
ExecStart=/bin/sleep 3
ExecStart=/usr/bin/logger 4
ExecStart=/bin/sleep 4
ExecStartPost=/usr/bin/logger 5
ExecStartPost=/bin/sleep 5
ExecStartPost=/usr/bin/logger 6
ExecStartPost=/bin/sleep 6
ExecStartPost=/usr/bin/logger 7
RemainAfterExit=yes

[root@valhalla system]# grep logger /var/log/messages
Jul 8 11:37:30 valhalla logger: 1
Jul 8 11:37:31 valhalla logger: 2 <-- waited for 1s
Jul 8 11:37:33 valhalla logger: 3 <-- waited for 2s
Jul 8 11:37:36 valhalla logger: 4 <-- waited for 3s
Jul 8 11:37:40 valhalla logger: 5 <-- waited for 4s
Jul 8 11:37:45 valhalla logger: 6 <-- waited for 5s
Jul 8 11:37:51 valhalla logger: 7 <-- waited for 6s
[root@valhalla system]#

test.service
Loaded: loaded (/lib/systemd/system/test.service)
Active: active (exited) since Fri, 08 Jul 2011 11:54:13 +0000; 3s ago
Process: 8754 ExecStartPost=/usr/bin/logger 7 (code=exited,
status=0/SUCCESS) <-- last
Process: 8752 ExecStartPost=/bin/sleep 6 (code=exited,
status=0/SUCCESS)
Process: 8750 ExecStartPost=/usr/bin/logger 6 (code=exited,
status=0/SUCCESS)
Process: 8748 ExecStartPost=/bin/sleep 5 (code=exited,
status=0/SUCCESS)
Process: 8746 ExecStartPost=/usr/bin/logger 5 (code=exited,
status=0/SUCCESS)
Process: 8743 ExecStart=/bin/sleep 4 (code=exited, status=0/SUCCESS)
Process: 8741 ExecStart=/usr/bin/logger 4 (code=exited,
status=0/SUCCESS)
Process: 8739 ExecStart=/bin/sleep 3 (code=exited, status=0/SUCCESS)
Process: 8737 ExecStart=/usr/bin/logger 3 (code=exited,
status=0/SUCCESS)
Process: 8735 ExecStartPre=/bin/sleep 2 (code=exited,
status=0/SUCCESS)
Process: 8733 ExecStartPre=/usr/bin/logger 2 (code=exited,
status=0/SUCCESS)
Process: 8731 ExecStartPre=/bin/sleep 1 (code=exited,
status=0/SUCCESS)
Process: 8729 ExecStartPre=/usr/bin/logger 1 (code=exited,
status=0/SUCCESS) <--- first
CGroup: name=systemd:/system/test.service


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 12:12 PM
"Jˇhann B. Gu­mundsson"
 
Default systemd: Is it wrong?

On 07/08/2011 11:42 AM, JB wrote:
> Hi,
>
> you are right about the synchronization problem within a service file exec
> environment, at least as you showed it in that particular Bugzilla case.
>

<snip>

No he did not and you are wrong the problem has nothing to do with order
timing and execution but everything to do with this..
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT <----

Further explanation can be found on the bug report and a correct working
native systemd nfslock service is attached to that report along with the
necessary modification he needs to do in the sysconfig file he is using.

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 12:12 PM
"Jˇhann B. Gu­mundsson"
 
Default systemd: Is it wrong?

On 07/08/2011 11:42 AM, JB wrote:
> Hi,
>
> you are right about the synchronization problem within a service file exec
> environment, at least as you showed it in that particular Bugzilla case.
>

<snip>

No he did not and you are wrong the problem has nothing to do with order
timing and execution but everything to do with this..
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT <----

Further explanation can be found on the bug report and a correct working
native systemd nfslock service is attached to that report along with the
necessary modification he needs to do in the sysconfig file he is using.

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 12:23 PM
Lennart Poettering
 
Default systemd: Is it wrong?

On Thu, 07.07.11 22:57, Steve Dickson (SteveD@redhat.com) wrote:

> Hello,
>
> One of the maintainers of systemd and I have been working
> together on trying to convert the NFS SysV init scripts
> into systemd services. Here is the long trail...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=699040
>
> The point is this, with fairly complicated system,
> some events need to have happen, like loading modules,
> before other events happen, like setting parameters of
> those loaded modules.
>
> Currently the ExecStart commands can be started and end
> before the ExecStartPre even start. This means setting
> modules parameters within the same service file are
> impossible.
>
> I suggested that a boundary be set that all ExecStartPre
> commands finish before any ExecStart commands start,
> which would allow complicated subsystems, like NFS,
> to start in a very stable way...
>
> So is it wrong? Shouldn't there away to allow certain
> parts of a system to synchronously configure some
> things so other parts will come up as expected?

I am pretty sure systemd-devel is the better place to discuss this. But
here are a few comments after reading throught the bug report:

Yes, we want that people place each service in an individual service
file. Only then we can supervise the services properly. It is possible
to spawn multiple high-level processes from a single service, but that
is mostly intended as compat kludge to support SysV init scripts where
this is possible. In general however, we want people to do have a 1:1
mapping. Only then we can restart services if needed, we can catch
crashes, and show proper information about your service.

So, I'd suggest strongly not to try starting all services from a single
file. There's a reason why we explicitly forbid having more than one
ExecStart= in a unit file (except for Type=oneshot services).

Note that systemd unit files are not a programming language. And that
for a reason. If you want shell, then use shell, but don't try to misuse
the purposefully simple service file syntax for that.

Also, you should not spawn forking processes in ExecStartPre=, that's
not what it is for. In fact I am pretty sure I will change systemd now
to kill off all remaining processes after each ExecStartPre= command now
that I am aware that people are misusing it like this.

ExecStartPre= is executed strictly in order, and in the order they
appear in the unit file.

I believe that services should be enabled/disabled at one place only,
and that is where you can use "systemctl enable" and "systemctl
disable". Adding a service-specific second-level of disabling in
/etc/sysconfig/ is confusing to the user, and not necessary. You'll do a
great service to your users if they can enable/disable all individual
services the same way. (And UI writers will be thankful for that too)

There's no point in ever unloading kernel modules, unless you do it for
debugging or testing reasons. No init script should ever include an
"rmmod" or "modprobe -r". And we try to make static module loading
unnecessary. There's nowadays auto-loading for most modules in one way
or another, using MODALIAS and similar constructs in the kernel
modules. If you really need to load a module statically, then please do
so via /etc/modules-load.d/ so that the user has centralized control on
this.

This is not going to work:

ExecStart=$FOO bar waldo

I.e. variable substitution for the binary path (it will work for the
arguments, just not for the binary path). This limitation is necessary
due to some SELinux innerworkings in systemd. It's a limitation we
probably could fix if we wanted to, but tbh I find it quite questionable
if you spawn two completely different binaries and still call it by the
same service file.

In general if services use a lot of /etc/sysconfig/ settings then this
is probably an indication that the service code should be fixed and
should just get proper configuration files. If you need to interpret
these files, outside of the daemon, and the simple variable substitution
is not sufficient, and you need a programming language to interpret the
settings, then use a programming language, for example shell. You can
start shell scripts from systemd, like any other executable, and then
exec the real binary in the end. Of course, these solutions are somewhat
hacky, and I think in the long run binaries should be stand-alone and
should be able to read their own configuration themselves. But if you
really need a shell script, then go for it, stick it in
/usr/lib/<yourpackage>/scripts/ or so, and execute that from ExecStart=.

I will probably blog about sysconfig in a systemd world soon.

Type=oneshot is for one shot services, not continously running
services. Type=oneshot is for stuff like fsck, that runs once at boot
and finishes, and only after it finished boot will continue.

I am aware that some things I point out above are not how people used to
do things on SysV, but well, we want to get things right, and if you use
systemd natively, then we ask you to clean up things and not just
translate things 1:1.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 12:23 PM
Lennart Poettering
 
Default systemd: Is it wrong?

On Thu, 07.07.11 22:57, Steve Dickson (SteveD@redhat.com) wrote:

> Hello,
>
> One of the maintainers of systemd and I have been working
> together on trying to convert the NFS SysV init scripts
> into systemd services. Here is the long trail...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=699040
>
> The point is this, with fairly complicated system,
> some events need to have happen, like loading modules,
> before other events happen, like setting parameters of
> those loaded modules.
>
> Currently the ExecStart commands can be started and end
> before the ExecStartPre even start. This means setting
> modules parameters within the same service file are
> impossible.
>
> I suggested that a boundary be set that all ExecStartPre
> commands finish before any ExecStart commands start,
> which would allow complicated subsystems, like NFS,
> to start in a very stable way...
>
> So is it wrong? Shouldn't there away to allow certain
> parts of a system to synchronously configure some
> things so other parts will come up as expected?

I am pretty sure systemd-devel is the better place to discuss this. But
here are a few comments after reading throught the bug report:

Yes, we want that people place each service in an individual service
file. Only then we can supervise the services properly. It is possible
to spawn multiple high-level processes from a single service, but that
is mostly intended as compat kludge to support SysV init scripts where
this is possible. In general however, we want people to do have a 1:1
mapping. Only then we can restart services if needed, we can catch
crashes, and show proper information about your service.

So, I'd suggest strongly not to try starting all services from a single
file. There's a reason why we explicitly forbid having more than one
ExecStart= in a unit file (except for Type=oneshot services).

Note that systemd unit files are not a programming language. And that
for a reason. If you want shell, then use shell, but don't try to misuse
the purposefully simple service file syntax for that.

Also, you should not spawn forking processes in ExecStartPre=, that's
not what it is for. In fact I am pretty sure I will change systemd now
to kill off all remaining processes after each ExecStartPre= command now
that I am aware that people are misusing it like this.

ExecStartPre= is executed strictly in order, and in the order they
appear in the unit file.

I believe that services should be enabled/disabled at one place only,
and that is where you can use "systemctl enable" and "systemctl
disable". Adding a service-specific second-level of disabling in
/etc/sysconfig/ is confusing to the user, and not necessary. You'll do a
great service to your users if they can enable/disable all individual
services the same way. (And UI writers will be thankful for that too)

There's no point in ever unloading kernel modules, unless you do it for
debugging or testing reasons. No init script should ever include an
"rmmod" or "modprobe -r". And we try to make static module loading
unnecessary. There's nowadays auto-loading for most modules in one way
or another, using MODALIAS and similar constructs in the kernel
modules. If you really need to load a module statically, then please do
so via /etc/modules-load.d/ so that the user has centralized control on
this.

This is not going to work:

ExecStart=$FOO bar waldo

I.e. variable substitution for the binary path (it will work for the
arguments, just not for the binary path). This limitation is necessary
due to some SELinux innerworkings in systemd. It's a limitation we
probably could fix if we wanted to, but tbh I find it quite questionable
if you spawn two completely different binaries and still call it by the
same service file.

In general if services use a lot of /etc/sysconfig/ settings then this
is probably an indication that the service code should be fixed and
should just get proper configuration files. If you need to interpret
these files, outside of the daemon, and the simple variable substitution
is not sufficient, and you need a programming language to interpret the
settings, then use a programming language, for example shell. You can
start shell scripts from systemd, like any other executable, and then
exec the real binary in the end. Of course, these solutions are somewhat
hacky, and I think in the long run binaries should be stand-alone and
should be able to read their own configuration themselves. But if you
really need a shell script, then go for it, stick it in
/usr/lib/<yourpackage>/scripts/ or so, and execute that from ExecStart=.

I will probably blog about sysconfig in a systemd world soon.

Type=oneshot is for one shot services, not continously running
services. Type=oneshot is for stuff like fsck, that runs once at boot
and finishes, and only after it finished boot will continue.

I am aware that some things I point out above are not how people used to
do things on SysV, but well, we want to get things right, and if you use
systemd natively, then we ask you to clean up things and not just
translate things 1:1.

Lennart

--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 11:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org