Hello everyone,

Today I read about the problem with one assertion in systemd, I read it in the amazing blog of Andrew Ayer (Click here), Right now is necessary document this problem using the Proof of Concept published in the systemd github page.

For documentation purposes I use screenshots but the final report for the systemd bug tracking is in plain text :).

screenshot-from-2016-09-29-10-35-05

screenshot-from-2016-09-29-10-40-08

 

screenshot-from-2016-09-29-10-44-46

The calls to systemd based commands (systemd-nspaw, systemctl, etc) hangs and later shows a timeout message. No general system degradation.

Ok, Andrew Ayer has a very clever point but my opinion is better help to debugging and improve systemd.

Cheers.

 

systemd is a system and service manager for Linux.It is (retro) compatible with systemV and LSB init scripts. It is relatively new but has been widely accepted by major Linux distributions.

Frankly, at first,  I did not like it,  I saw it too complex, bulky and don’t see any shell script on the service management, but remembering the wisdom of  Master Foo Discourses on the Two Paths, i give it one opportunity and I just fell in love.

I’ll outline a few things that I find awesome about systemd, In no particular order:

1.- It don’t use Shell scripts

Ok it is not clear but systemd is faster and scale better in bootup, when we use scripts they call many times commands like grep, awk, cd, ls and others, so this execution is slow (but easy to hack).

2.-Use the units concept

One unit is a file than encodes information about a service (.service),a mount point (.mount),a device(.device), a socket (.socket), a timer (.timer) and other abstract entities, we can enable, disable, start, stop , restart, mask units. See   man systemd.unit for details.

$ sudo systemctl start unit
$ sudo systemctl stop unit
$ sudo systemctl enable unit
$ sudo systemctl disable unit

3.- We can check the system state

Just with this commands:

$ systemctl status

and list running and failed units

$ systemctl list-units
$ systemctl --failed

4.- It is hotplug capable

systemd assumes that all resources may appear and dissapear at any time, this is one of the reasons because systemd depends of dbus but right now, our systems become dynamic systems with lowest downtime when adding or removing hardware.

5.- It is modular

All of what is now rc.sysinit is split out into many independent services, each of which is well documented and easy to understand.

6.- Can deploy containers with systemd-nspawn

I talk about it in this post.

7.- The systemd timers

Timers have built-in support for calendar time events, monotonic time events, and can be run asynchronously.Timers Timers can be used as an alternative to CRON and “at command”  but timers have a more complex syntax than crontab entries but our duty as sysadmins is learn it.

8.- systemd is a cross-distro project

Every major and many, many minor distros have had people contributing to systemd, it is the default in Debian 8, Fedora, OpenSuse, Ubuntu (Leaving Upstart for systemd) and many many others distros use systemd.

9.- systemd do power management

You can poweroff, restart, suspend or hibernate using systemd. (for unprivileged users you need polkit)

$ sudo systemctl poweroff
$ sudo systemctl reboot
$ sudo systemctl suspend
$ sudo systemctl hibernate

10.- Have a build-in logging system

systemd has its own logging system called the journal; therefore, running a syslog daemon is no longer required. To read the log, use:

# journalctl

The systemd journal event notification message logging classification corresponds to classical BSD syslog protocol style (RFC 5424).

For more information about systemd:

Cheers!!!