systemd: Is it wrong?

[JB]

JB <jb.1234abcd <at> gmail.com> writes:

> 
> Michal Schmidt <mschmidt <at> redhat.com> writes:
> 
> > ... 
> > > 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=
> > > ...
> > > Are there any restrictions on those Pre (and Post) commands ?
> > 
> > One limitation was already mentioned somewhere in this thread - these 
> > commands must not fork off daemons.
> 
> This is interesting. Or perhaps I read too much into your above statement ?
> We know already that ExecStartPre must contain a command to be executed.
> > > ExecStartPre= exec /etc/init.d/sub-service-1
> Note the 'exec' command, which means "Replace the shell with the given
> command." with immediate return.
> How does systemd know what's in the "/etc/init.d/sub-service-1" process, to be
> able to figure out if any daemon is to be forked off ?
> 
> > ... 
> > >> 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.
> > > ...

Regarding your statement on Parallelism.
Let's consider these two ExecStartPre with 'exec':
Is that still considered sequential execution, or parallel execution and
a violation of the previous principle ?

Actually, this question has a general ramification, as it applies to any of
Pre, regular, and Post sequential execution principle within unit file.

What is the meaning and purpose of "serial execution" within systemd ?
- mechanical
  submit for execution,
  wait for return code,
  iterate
- or more involved
  submit for execution,
  wait for command (job) completion, presumably to avoid ... parallelism and
  its potential side effects like any conflicts, races, etc; with return code,
  iterate

JB