systemd: Is it wrong?

JB jb.1234abcd at gmail.com
Mon Jul 11 11:08:48 UTC 2011


Michal Schmidt <mschmidt <at> redhat.com> writes:

> ... 
> > 1.
> > 
> > main-service-1.service:
> > [Unit]
> > Description=Main service 1
> > Requires= ... sub-service-1.service sub-service-2.service
> > After= ... sub-service-1.service sub-service-2.service
> > ...
> > [Service]
> > Type=forking    <---------------------- any other type too ?      
> > ExecStartPre=
> > ExecStartPre=
> > ExecStart=
> > ExecStart= /usr/sbin/some-service
> 
> Nitpick: You can have only one ExecStart= in a forking unit. Only
> oneshot units can have more.
> 
> > ExecStartPost=
> > ExecStartPost=
> > ...
> 
> > sub-service-1.service:
> > [Unit]
> > Description=Sub service 1
> > ...
> > [Service]
> > ...
> > 
> > sub-service-2.service:
> > [Unit]
> > Description=Sub service 2
> > ...
> > [Service]
> > ...
> 
> First, sub-service-1.service and sub-service-2.service will be started
> in parallel. When they're running, main-service-1.service will be
> started by processing its ExecStart* commands sequentially.
> ...

OK.
Q: The sub-service-1.service and sub-service-2.service will be run as stand-
   alone processes (of whatever kind they are: daemon, master/slave,
   multithreaded), with no back references or dependecies of any kind
   (parent-child like, shared resources, etc) to main-service-1.service ?
 
> > 2.
> > 
> > main-service-2.service:
> > [Unit]
> > Description=Main service 2
> > After= ...
> > ...
> > [Service]
> > Type=forking    <---------------------- any other type too ?      
> > ExecStartPre= sub-service-1.service 
> > ExecStartPre= sub-service-2.service
> 
> This is incorrect. ExecStartPre= expects a command to run, not a unit
> name.
> 

OK. Yes, I goofed here ... I meant some executable ...
Let me repeat example 2:

2.
main-service-2.service:
[Unit]
Description=Main service 2
After= ...
...
[Service]
Type=forking    <---------------------- any other type too ?      
ExecStartPre= exec /etc/init.d/sub-service-1
ExecStartPre= exec /etc/init.d/sub-service-2
ExecStart= /usr/sbin/some-service
ExecStartPost=
ExecStartPost=
...

Would the above be correct setup-wise ?
Are there any restrictions on those Pre (and Post) commands ?

> > What if sysadmin wants to execute them in parallel because she knows
> > they can be executed this way (no conflict and no races) ?
> > How, if by definition, systemd executes them sequentially only ?
> > Can they be grouped and execution-parallelized in the whole service
> > file, or at least in subgroups Pre-, regular, and Post- ?
> 
> Parallelism in systemd happens between multiple units, but never between
> ExecStart* commands of one unit.
> Requesting parallelism within one unit seems like over-engineering to
> me. You can always split your unit to smaller ones if you want
> parallelism.

But this is what Steve, I believe, wants to do with nfs (to have a bunch of
services started from the main one, as under current SysV init system, so his
users are not confused by the startup of all these individual service files).

> ... 
> > Can you give us a working example of a services setup (or something
> > else) in systemd where execution-parallelism would be present or at
> > least theoretically exploitable ?
> 
> Take a look at 'systemd-analyze plot' where you can clearly see
> services starting in parallel.

Well, I wish I could (I am on F15) ...

$ systemd-analyze plot
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" width="1793pt" height="2290pt"
viewBox="0 0 1793 2290" version="1.1">
<defs>
<g>
<symbol overflow="visible" id="glyph0-0">
<path style="stroke:none;" d="M 3.8125 -7.96875 C 3.207031 -7.96875 2.746094 -7
...
  <use xlink:href="#glyph0-32" x="493.898438" y="2211.25"/>
</g>
</g>
</svg>
$
$ systemd-analyze plot |less
Traceback (most recent call last):
  File "/usr/bin/systemd-analyze", line 221, in <module>
    surface.finish()
IOError: [Errno 32] Broken pipe
$

> This Lennart's blog post has an example:
> http://0pointer.de/blog/projects/blame-game.html
> 
> Michal

Thanks.
JB




More information about the devel mailing list