Systemd service life cycle

[Tom H]

On Thu, Apr 7, 2016 at 1:44 PM, Ralf Mardorf <silver.bullet at zoho.com> wrote:
> On Thu, 7 Apr 2016 13:15:38 +0200, Tom H wrote:
>>
>> The systemd developers have had to add more and more options to units
>> to allow accurate ordering and maintainers of various packages have
>> had to use new stanzas and/or refine dependencies so there may have
>> been races (and may even be races still) but it's definitely not a
>> common "misfeature."
>
> Due to all that options it's not easy to understand. Fortunately I
> don't experience a race condition, but I remember that I read a lot
> about this issue. Perhaps user errors, perhaps systemd bugs or missing
> features that nowadays are fixed.
>
> https://www.google.de/#q=systemd+race+condition
> https://www.google.de/#q=ubuntu+systemd+race+condition
> https://www.google.de/#q=arch+systemd+race+condition
> https://www.google.de/#q=arch+general+mailing+list+systemd+race+condition
>
> Sure, there are hits for
>
> https://www.google.de/q=sysvinit+race+condition
>
> too, but I can't remember reported race conditions on mailing lists.

I followed the first search and the first link was

https://github.com/systemd/systemd/issues/2615

I don't have the time to check other links today - maybe this weekend
- but if they're anything like this one, I'd say that this isn't
really a systemd problem.

The bug above's about a custom unit to bond a wired and wireless
interface, bring them up, run wpa_supplicant on the wireless one, and
run a dhcp client on the bond. All in the same unit. And the
reporter's quite aggressive and he seems to expect systemd in a way
that it's not designed to behave. Perhaps he's hit a real bug (I doubt
it) or pointed out a deficiency that might need to be corrected
(possibly), but it's not something that I'd hold against systemd.

There have been units with problems that were written by upstreams or
by distro maintainers but they were fixed, with or without a
newfangled option.

Writing an upstart job wasn't straightforward and writing a systemd
unit isn't straightforward (as evidenced by Karl's email to this list)
even if they're not long and complex sysvinit scripts.


> If a user edit units that cause unresolvable before/after conflicts, how
> does systemd behave?

It's the same as anything else. If a user screws up the config of
apache, iptables, nfs, nginx, postfix, smb, ssh, tomcat, etc, it's his
or her problem.