Detect Linux Runlevel

Marko Rauhamaa marko at
Mon Dec 5 18:37:41 EST 2016

Michael Torrie <torriem at>:

> On 12/05/2016 03:29 PM, Marko Rauhamaa wrote:
>> In fact, systemd is not an init system for Linux. Linux is the kernel of
>> the systemd operating system. Systemd is the
>>       One Ring to rule them all, One Ring to find them,
>>    One Ring to bring them all and in the darkness bind them
> Well I for one am glad of the systemd init system inside of my Linux
> operating system. I would far rather deal with service ini files than
> long arcane bash scripts that often re-implement (poorly) things like
> pid files, and attempts to prevent more than one instance from
> running.

The situation before systemd *was* atrocious. Most of the protests
against systemd were misplaced. They advocated the ancient hacker
culture that placed the supreme authority on the System Administrator,
who fashioned the system into his own image.

I appreciate that finally there was a bold soul who took the point of
view of an Architect and laid down some higher-level principles for the
whole system to abide by.

Unfortunately, I am not wholly impressed by the end result. Mogadishu
has been replaced by Pyongyang. Some age-old Unix principles have been
abandoned without clear justification. For example, I was appalled to
find out that a systemd unit can be configured to react on the exit
status of a child process of a daemon.

Also, now D-Bus is a fixture for every daemon writer.

> You were the one that posted earlier today about the many perils of
> programming complicated scripts in bash. Init scripts pretty much hit on
> all of those gotchas!

Guess what -- the unit files come with their own gotchas. For example,
there is no simple way to convert an arbitrary pathname into an
ExecStart entry of a unit file.

The .ini file format was a lousy choice. Why not choose JSON in this day
and age?

Yes, the SysV init system had become a jungle. Still, I wish it had been
replaced with a rigorous protocol. The units should have been programs
that comply with given contracts.


More information about the Python-list mailing list