systemd: Is it wrong?

[Steve Dickson]

On 07/08/2011 08:23 AM, Lennart Poettering wrote:
> On Thu, 07.07.11 22:57, Steve Dickson (SteveD at 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:
I didn't know it existed... 

> 
> 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).
Thank you for this explanation. It appears your definition of a
service might be a bit too simple for many subsystems. You seem
to think that on service will only start one system daemon, which
is not the case in the more complex subsystems. 
 
> 
> 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.
Boy... What I would give for a shell!! 8-)

> 
> 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.
If they are not for forking off process, what are the for? It seems
quite logical that one would use a number of ExecStartPre= commands
to do some set up and then use the ExecStart= to start the daemon.

> 
> ExecStartPre= is executed strictly in order, and in the order they
> appear in the unit file.
True, but there is no synchronization. Meaning first process can 
end after the second process, which think is a problem.
 
> 
> 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)
In a simple subsystem maybe, but many subsystems have a large number
of configuration knobs that are needed so the subsystem can function
in a large number of different environments. So in the past its
been very handy and straightforward to be able to tweak one file
to set configurations on different, but related, subsystems. 

> 
> 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.
I agree unloading modules is unnecessary, but, IMHO, its much
similar to manage one start up file that loads multiple modules 
than one start up script and multiple  modules-load.d files..

> 
> 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.
Spawning different binaries to do set up, like exporting directories 
before the a system daemon is started seems very reasonable and expected
practice.

> 
> 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. 
I don't understand this generalization. For a very long time subsystems 
have used /etc/sysconfig to store there configuration files and now they
are broken because they do? Plus they are not "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=.
Perfect... I will used this "hacky" to do all the system setup and configuration
that is needed... 

Thanks for taking the time....

steved.

> 
> 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
>