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.
Requirements:
- 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.
Conclusion:
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: |
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: http://www.rsyslog.com/doc/im3195.html (not even rsyslog cares about it…)
– logging to database works and documenteted: http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-v3.1-guide-admin-en.html/reference_destination_sql.html
– etc.
And obviously we would like to see your bugs reported upstream, as without reports we can’t fix them.
CzP / syslog-ng upstream
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: http://paste.pocoo.org/show/261471/ (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 http://www.balabit.com/sites/default/files/documents/syslog-ng-v3.0-guide-admin-en.html/index.html-single.html#configuring_destinations_sql
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
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,
CzP
Hello,
Please take a look at this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=630401 The problem was fixed by systemd upstream, so an update seems to address your problems too.
Best regards,
CzP
Hello Peter,
thanks for that link. Actually, the problem is not within systemd but syslog-ng:
http://cgit.freedesktop.org/systemd/commit/?id=c31e14954b158351b11f886332229a61fff2e5d1
/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 http://www.campin.net/syslog-ng/faq.html#AEN191 (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