systemd

How to boot into a non-standard runlevel/target to rescue a Linux system

/ bronto / Leave a comment

Recently, while testing a configuration of Linux on a Lenovo laptop, I messed up. I had rebooted the laptop and there were some leftovers around from an attempted installation of the proprietary Nvidia driver. The system booted fine and was functional, but those leftovers where enough to make the screen go blank. The fix is easy, if you can enter the system in some other way: log in and remove anything related to the Nvidia driver. But unfortunately the only way to log in was from the console, so I was “de facto” locked out.

The first attempt to get out of the mud was to force a reboot of the system and in rescue mode. The system booted well, but after I typed the root password the  boot process went a bit too far, loaded the infamous leftovers of the driver and here we go again, with a blank screen.

Continue reading →

Advertisement

An init system in a Docker container

/ bronto / 10 Comments

DockerHere’s another quick post about docker, sorry again if it will come out a bit raw.

In my previous post I talked about my first experiments with docker. There was a number of unanswered questions at first, which got an answer through updates to the blog post during the following days. All but one. When talking about a containerized process that needs to log through syslog to an external server, the post concluded:

if the dockerized process itself needs to communicate with a syslog service “on board”, this may not be enough…

Continue reading →

systemd unit files for CFEngine

/ bronto / Leave a comment

systemd logoLearning more of systemd has been on my agenda since the release of Debian 8 “Jessie”. With the new year I decided that I had procrastinated enough, I made a plan and started to study according to the plan. Today it was time for action: to verify my understanding of the documentation I read up to now, I decided to put together unit files for CFEngine. It was an almost complete success and the result is now on GitHub for everyone to enjoy. I would appreciate if you’d give them a shot and report back.

Main goals achieved:

  1. I successfully created three service unit files, one for each of CFEngine’s daemons: cf-serverd, cf-execd and cf-monitord; the units are designed so that if any of the daemon is killed for any reason, systemd will bring it back immediately.
  2. I successfully created a target unit file that puts together the three service units. When the cfengine3 target is started, the three daemons are requested to start; when the cfengine3 target is stopped, the three daemons are stopped. The cfengine3 target completely replaces the init script functionality.

Goal not achieved: I’ve given a shot at socket activation, so that the activation of cf-serverd was delayed until a connection was initiated to port 5308/TCP. That didn’t work properly: systemd tried to start cf-serverd but it died immediately, and systemd tried and tried again until it was too much. I’ll have to investigate if cf-serverd needs to support socket activation explicitly or if I was doing something wrong. The socket unit is not part of the distribution on GitHub but its content are reported here below. In case you spot any problem please let me know.

Continue reading →

How to make CFEngine recognize if systemd is used in Debian

/ bronto / Leave a comment

CFEngine 3.6 tries to understand if a Linux is using systemd as init system by looking at the contents of /proc/1/cmdline, that happens in bundle common inventory_linux. That’s indeed a smart thing to do but unfortunately fails on Debian Jessie, where you have:

root@cf-test-v10:~# ls -l /sbin/init
lrwxrwxrwx 1 root root 20 May 26 06:07 /sbin/init -> /lib/systemd/systemd

the pseudo-file in /proc will still report /sbin/init and as a result the systemd class won’t be set. This affects services promises negatively and therefore I needed to make our policies try to outsmart the inventory 😉 These promises, added in a bundle of ours, did the trick:

bundle common debian_info {
  vars:
    init_is_link::
      "init_link_destination"
          string => filestat("/sbin/init","linktarget") ;

  classes:
    init_is_link::
      "systemd"
          expression => regcmp("/lib/systemd/systemd",
                               "$(init_link_destination)"),
          comment => "Check if /sbin/init links to systemd" ;

    debian::
      "init_is_link"
          expression => islink("/sbin/init"),
          comment => "Detect if init is a link" ;
}

Notice that our bundle is actually bigger, I cut off all the promises that were not relevant for this post. Enjoy!

On systemd

/ bronto / 1 Comment

ReligiousWarsUNIX init systems are not a topic people discusses a lot about, usually. There is some buzz when a new one is out, some more buzz when it is adopted in other shops than those where it was born, then most OS keep on with their old solution (usually the System V init system, or sysvinit) and everything falls back to radio silence. Other times, I assume, things cut short from some buzz and directly into the radio silence phase. I’ve been into the Upstart buzz, before that I’ve been into the Solaris SMF buzz and even played with it until our friend OpenSolaris was mercilessly killed by their new father. But, honestly, the heated arguments about systemd took my by surprise.

I really don’t know how I had not heard about systemd before. Maybe I was just looking in another direction, or maybe the fact that it was so controversial suggested systemd’s detractors not to talk about it in the hope that it would be yet another of those attempts that cut short from their offspring to radio silence. I don’t know. Anyway, it didn’t go that way. To me, it’s like systemd flew steadily under the radar and kept growing until the Debian project decided to adopt it as their init system. My brain just filtered the news as yet another thing I could safely ignore for the moment and I’ll have to learn about when it comes. And then the sky fell down.

What happened after that announcement was kind of the burst of a religious war, with people debating harshly, insulting each other, death threats spewed here and there, people resigning from their role in important organizations. Then came the Devuan fork of Debian. For now.

A bit too much for “just another init system”, right?

What follows is the outcome of my Christmastime readings about systemd and my own considerations about what I’ve read. I hope it will help you make up your own opinion on whether or not systemd is a good thing or a bad thing. As an extra, you can read my own opinion (for what is worth).

Continue reading →