systemd in Exherbo – what’s happened so far…

It has been quite a while since I last wrote something about my work on systemd in Exherbo, so here’s an update:

What has been accomplished so far:

  • The Exherbo patches are done. Do NOT try to submit them upstream yet, though. I’ll take care of that when the time is ripe.
  • Lots of services are done.
  • You can boot and run most systems using systemd now.
  • I’ve built new amd64 and x86 stages without any init system so you can start out without the baselayout-1/sysvinit cruft.
  • The installation guide has been updated.

Every systemd service is implemented natively and we’re not using anything from baselayout-1 or sysvinit anymore. Instead, all the important stuff has been moved to skeleton-filesystem-layout. systemd’s dependencies have been updated accordingly.

Thus, for people using systemd, baselayout-1 and sysvinit are now obsolete. YAY!

What still needs to be done:

  • Improve existing service definitions for systemd.
  • Create socket definitions for several of the existing service definitions. (And new ones, of course.)
  • Create systemd service files for missing services.

Rules for new service files:

  • Please make sure they’re implemented natively. I won’t accept non-native service files unless you can convince me there’s definitely no other solution.
  • If you convinced me, scripts go to /usr/${LIBDIR}/systemd.
  • EnvironmentFiles (configuration) go to /etc/conf.d and end in .conf. We do NOT create a configuration file for every single service but create (grep-able) logical units, e. g. now-obsolete font@.service and keymap@.service used to use console.conf).
  • You can reference environment variables from configuration files in service. If you have to quote the values in the configuration file, you need to use $FOO; if you don’t quote them (preferred), you use ${FOO}. This is probably a bug (and known to upstream) but for now that’s how it is.
  • Services and their (potentially) accompanying files must not collide with baselayout-1.


  • You have to run Linux kernel >=2.6.36-rc1 (I’m using 2.6.36-rc6; latest NVidia-Drivers work fine and there are patches for the VMWare modules available.).

How to get started with systemd:

Read this.


Since both systemd and its exheres have now reached an acceptable degree of stability, I don’t intend on breaking things anymore as I’ve done over the last months from time to time.

In fact, systemd is so usable these days, I’m writing this on a systemd-initialised system! This means as well that I can live without baselayout-1 and sysvinit. YAY! 🙂

I am and have been working on quite a few F/OSS projects:
  • Exherbo (Nick: Philantrop)
  • Gentoo (Nick: Philantrop)
  • Calibre plugin iOS reader applications
  • Calibre plugin Marvin XD
  • chroot-manager
  • stuff on github
  • Lots of other projects
  • If you like my work, feel free to donate. 🙂

    5 thoughts on “systemd in Exherbo – what’s happened so far…

    1. Hello,

      I’m CzP from syslog-ng upstream, and would like to ask, if there is any way I could help you.

      About your remarks about syslog-ng:
      – rfc3195: (not even rsyslog cares about it…)
      – logging to database works and documenteted:
      – etc.
      And obviously we would like to see your bugs reported upstream, as without reports we can’t fix them.

      CzP / syslog-ng upstream

      1. Hello Peter,

        thanks for your comment. First of all, let me admit that I was rather frustrated with syslog-ng when I wrote that post because I had spent days debugging both syslog-ng and systemd to find the issue I described.

        Especially since the systemd code is fairly simple: (lines 135 to 182)

        I kept getting either “connection refused” or “file does not exist”. This simply doesn’t happen with rsyslog which just works (which I will gladly admit has been true for syslog-ng for many years, too).

        If you have any ideas what the issue could be, I’ll gladly take advice.

        As for logging to databases with syslog-ng – I was aware of
        and an adaption of Example 3.22 to MySQL succeeded to connect to the database, created the tables but the logging failed. (Unfortunately, I don’t have the details anymore as it’s been quite a while since I tried it.)

        Anyway, I didn’t mean to offend and I’d like to apologise if I did.

        Best regards, Wulf

    2. Hello,

      Personally I don’t have much experience with systemd, but I can check. I contributed the syslog-ng 3.1 packages for Fedora, and AFAIK it worked fine after the switch to systemd. I don’t personally use Fedora on a daily basis, and after the latest update I can’t even boot it, but I will reinstall it and check if it works there, and if yes, what settings are used there.

      MySQL: I started out also from the same config sample 🙂 It works fine over here. I must say, that gave all permissions to the database for the logging user, which might be a bit too much, on the other hand I suspect, that you gave too little permissions.

      Anyway: do you have a download location for your Linux distribution and instructions how to install syslog-ng on it?

      Best regards,

      1. Hello Peter,

        thanks for that link. Actually, the problem is not within systemd but syslog-ng:

        /dev/log has indeed once been a SOCK_STREAM but in 1999, it was switched to SOCK_DGRAM.
        systemd actively works around that but the real fix should be done in syslog-ng.

        I’m aware of (btw, the link to the reference manual there is broken) but as seen with systemd, it’s not really a choice but rather wrong to use SOCK_STREAM.

        Nevertheless, syslog-ng now works with systemd.

        Best regards, Wulf

    Leave a Reply