systemd: Yet Another Init Replacement

falconindy · 2011-01-25 15:54:27

ngoonee wrote:

Been searching for dovecot info, here's a recent commit for systemd support:-
http://hg.dovecot.org/dovecot-2.0/rev/84eb4afebc95
Looks like we have to wait (and use /etc/rc.d/dovecot for the time being). Shouldn't I be able to systemctl start dovecot.service to start the /etc/rc.d? It just produces a dovecot.service which is 'exited'.

Why do you need to wait? Just like dbus and udev, dovecot needs to be configured with the extra flag --with-systemdsystemunitdir=/lib/systemd/system and the unit files will be available. Feel free to file a feature request in flyspray.

ngoonee · 2011-01-25 16:02:19

falconindy wrote:

ngoonee wrote:
Been searching for dovecot info, here's a recent commit for systemd support:-
http://hg.dovecot.org/dovecot-2.0/rev/84eb4afebc95
Looks like we have to wait (and use /etc/rc.d/dovecot for the time being). Shouldn't I be able to systemctl start dovecot.service to start the /etc/rc.d? It just produces a dovecot.service which is 'exited'.
Why do you need to wait? Just like dbus and udev, dovecot needs to be configured with the extra flag --with-systemdsystemunitdir=/lib/systemd/system and the unit files will be available. Feel free to file a feature request in flyspray.

Cool. I'll first try it out, then file the feature-request.

Also, I found the /lib/systemd/system-generator/arch-daemons script, where's the best place to generate the .service files? /etc/systemd/user? I'm sure there's a reason the script is not run automatically, should I add a note to the wiki that those who need non-implemented services should try that?

falconindy · 2011-01-25 16:09:09

No, the generator directory is magical and it's [supposed to be] run on each boot. This is where things get tricky, ugly, and just plain nasty. Dumping the generator files in /lib/systemd/system probably stomps on any files that already exist there (note to self: don't let the script do that). Putting them in /etc/systemd/system masks any legit unit files in /lib/systemd/system.

Please, please, please understand that this generator is a filthy hack and its _not_ meant to be used as a permanent solution. It should be used to get yourself a bootable system, at which point you're far better off hooking in native unit files (even if they just wrap a call to the /etc/rc.d script). I can't and won't spend too much time fixing it because it's not what upstream wants us to be doing (and I don't have the time right now).

I also have no idea what this "masked" error message is that you guys are seeing. If you could post the actual error and what leads up to it along with a 'systemctl status' on the unit, that'd be great.

Last edited by falconindy (2011-01-25 16:12:08)

tomegun · 2011-01-25 16:47:53

lucke wrote:

One other thing: on my desktop systemd was booting up in a semibroken single user mode. I guess it was because my / is on btrfs and it couldn't run fsck.btrfs. I symlinked fsck.btrfs to btrfsck and it started booting okay.

This is a known problem. It is in systemds TODO. It will also be fixed when there is a proper fsck available from btrfs (in the works apparently).

A temporary fix is to mark the filesystem to not be fscked in fstab. Symlinking btrfsck does not sound like a good idea as it is not co,patible with fskc (takes different options), and it is not able to fix errors anyway.

lucke · 2011-01-25 17:02:57

falconindy, with your revised arch-daemons, apparently nothing gets created anywhere on the hard disk and no rc.daemon gets started on boot, only in systemctl there appear entries like:

acpid.service             masked inactive dead          acpid.service

acpid.service
      Loaded: masked (/dev/.systemd/generator-ERtQob/acpid.service)
      Active: inactive (dead)

I ran the generator manually, pointing it to /etc/systemd/system, it created service files and arch-daemons.target.wants, I deleted the service files I didn't want and it seems everything is okay on boot now.

tomegun, changing fstab sounds like a good idea. I even pondered about symlinking fsck.btrfs to true or something like that.

tomegun · 2011-01-25 17:06:31

falconindy wrote:

No, the generator directory is magical and it's [supposed to be] run on each boot. This is where things get tricky, ugly, and just plain nasty. Dumping the generator files in /lib/systemd/system probably stomps on any files that already exist there (note to self: don't let the script do that). Putting them in /etc/systemd/system masks any legit unit files in /lib/systemd/system.
Please, please, please understand that this generator is a filthy hack and its _not_ meant to be used as a permanent solution. It should be used to get yourself a bootable system, at which point you're far better off hooking in native unit files (even if they just wrap a call to the /etc/rc.d script). I can't and won't spend too much time fixing it because it's not what upstream wants us to be doing (and I don't have the time right now).
I also have no idea what this "masked" error message is that you guys are seeing. If you could post the actual error and what leads up to it along with a 'systemctl status' on the unit, that'd be great.

Further to falconindys coment, I should clarify the purpose of arch-daemons:

It is meant to start your legacy daemons (from rc.conf) on boot, possibly falling back to /etc/rc.d/ scripts. This to make sure that anything that booted before will continue booting after switching to systmd.

It is not meant to be invoked manually; and it is not meant to let you start legacy daemons manually.

'systemctl start bla.service' does not fall back to /etc/rc.d/bla if bla.service does not exist; you will probably get the masked errors due to this. While nice to have I think this feature is out of scope for our packages.

That said, Ill put it on my TODO to check if supporting it would be trivial, in which case Ill prepare a patch.

tomegun · 2011-01-25 17:13:59

lucke wrote:

falconindy, with your revised arch-daemons, apparently nothing gets created anywhere on the hard disk and no rc.daemon gets started on boot, only in systemctl there appear entries like:
acpid.service             masked inactive dead          acpid.service
acpid.service
      Loaded: masked (/dev/.systemd/generator-ERtQob/acpid.service)
      Active: inactive (dead)

'masked' usually means that there is a symlink from /{etc,lib}/systemd/system/acpid.service to /dev/null (or possibly to a non-existent path). Could this have been the case?

If you have time, it would be great if you could do this little test:
delete all files or symlinks named 'acpid.service' in /lib and /etc.
run: 'systemctl enable arch-daemons.target'
put 'acpid' in you DAEMONS array
reboot
check if the output you gave above still is the same.

lucke · 2011-01-25 17:29:36

The result is as described before indeed - no acpid.service file or symlink gets created anywhere. Additonally, there's "systemd[1]: Cannot add dependency job for unit acpid.service, ignoring: Unit acpid.service is masked." in the logs I failed to mention before. Whatever runs this generator and with whatever argument, it fails. Even the description of the service files created by manually running the generator says "Legacy unit for x.service", not just "x.service".

tomegun · 2011-01-25 17:36:14

lucke wrote:

The result is as described before indeed - no acpid.service file or symlink gets created anywhere. Additonally, there's "systemd[1]: Cannot add dependency job for unit acpid.service, ignoring: Unit acpid.service is masked." in the logs I failed to mention before. Whatever runs this generator and with whatever argument, it fails. Even the description of the service files created by manually running the generator says "Legacy unit for x.service", not just "x.service".

The path of the generated file is given by 'systemctl status acpid.service' (in the above it was '/dev/.systemd/generator-ERtQob/acpid.service').

Could you look at the contents of this file ('cat /dev/.systemd/generator-*/acpid.service')? It sounds like it is empty; which would be weird... Ill look tonight when I get home to try and reproduce.

Just to clarify: this happens to all your legacy daemons, or just some?

lucke · 2011-01-25 17:42:57

It's empty all right.

-rw-rw-rw- 1 root root 0 Jan 25 18:22 /dev/.systemd/generator-rWc11d/acpid.service

It happens to all the legacy daemons indeed. I said before that only privoxy got started, but it turns out it wasn't started by systemd.

tomegun · 2011-01-25 18:00:23

Doh, I see it now (I think).

Could you edit /lib/systemd/system-generators/arch-daemons (or whatever the path is; I dont have systemd on this computer) to change 'cat' to '/bin/cat'?

If this works; then maybe I was wrong earlier and that manually calling 'systemctl start bla.service' should work even if there is no native service file; as long as /etc/rc.d/bla exists (irrespective of whether or not bla is in DAEMONS). Would be great if someone can check this.

lucke · 2011-01-25 18:28:26

Doesn't change a thing.

lucke · 2011-01-25 18:46:26

Those service files are empty after boot, but when I run "systemctl --system daemon-reload", a new generator-* directory gets created, with proper files - and I can start and stop those services nicely.

-edit-

And starting/stopping daemons without service files works (then?).

Last edited by lucke (2011-01-25 18:49:24)

ngoonee · 2011-01-26 00:34:47

Same behaviour here as lucke. Could someone recommend me some documentation on writing *.service files? Would like to get at least net-auto-wire{d,less} working...

EDIT: my flyspray report requesting dovecot systemd support was rejected. Fair enough, I'll just have bauerbill auto-patch it. Doubt very many people run dovecot locally anyway.

Last edited by ngoonee (2011-01-26 00:52:02)

tomegun · 2011-01-26 01:29:31

ngoonee wrote:

Same behaviour here as lucke. Could someone recommend me some documentation on writing *.service files? Would like to get at least net-auto-wire{d,less} working...

The man pages of systemd are quite good. Try 'man systemd.service'.

ngoonee wrote:

EDIT: my flyspray report requesting dovecot systemd support was rejected. Fair enough, I'll just have bauerbill auto-patch it. Doubt very many people run dovecot locally anyway.

That's a shame. I didn't get the reasoning for refusing it, but I guess we might have more luck once systemd is in [community]...

ngoonee · 2011-01-26 01:50:13

tomegun wrote:

ngoonee wrote:
Same behaviour here as lucke. Could someone recommend me some documentation on writing *.service files? Would like to get at least net-auto-wire{d,less} working...
The man pages of systemd are quite good. Try 'man systemd.service'.

Okay, will read through. For arch-specific (net-auto-wired, net-auto-wireless) would it be good for those to be added to systemd-arch-units?

tomegun wrote:

ngoonee wrote:
EDIT: my flyspray report requesting dovecot systemd support was rejected. Fair enough, I'll just have bauerbill auto-patch it. Doubt very many people run dovecot locally anyway.
That's a shame. I didn't get the reasoning for refusing it, but I guess we might have more luck once systemd is in [community]...

Their call, and yes if its not in the repos (even community may have a problem, maybe once its in [extra]) I can understand not wanting an additional source of problems/bugs. The suggestion for dovecot-systemd doesn't appeal though, just for one extra configure line.

EDIT: for the record, this is the bug report https://bugs.archlinux.org/task/22601#comment71307

Last edited by ngoonee (2011-01-26 01:50:33)

vostok4 · 2011-01-26 03:00:52

ngoonee wrote:

Okay, will read through. For arch-specific (net-auto-wired, net-auto-wireless) would it be good for those to be added to systemd-arch-units?

Yeah falconindy said to fork his repo on github and submit a pull request (for systemd-arch-units).

tomegun · 2011-01-26 13:14:39

ngoonee, lucke and anyone else who experienced the "masked" bug,

Could you try replacing your /lib/systemd/system-generators/arch-daemons file with this one: <https://github.com/teg/initscripts-syst … ch-daemons>.

I was able to reproduce the problem, and the above version fixes it for me. Would be great if you can confirm that it fixes it for you too.

lucke · 2011-01-26 14:01:07

Works okay.

lucke · 2011-01-26 15:27:01

I've been trying to enable pam_systemd, but putting the systemd/loginuid lines specified in pam_systemd(8) in /etc/pam.d/login prohibits me from logging in. Did anyone play with pam_systemd?

tomegun · 2011-01-26 16:02:00

lucke wrote:

I've been trying to enable pam_systemd, but putting the systemd/loginuid lines specified in pam_systemd(8) in /etc/pam.d/login prohibits me from logging in. Did anyone play with pam_systemd?

I don't think we have auditd support in Arch, so try doing it without the loginuid line (it works fine here).

lucke · 2011-01-26 16:13:28

I tried without loginuid first, the result was the same. Can you paste your /etc/pam.d/login file? Perhaps you've done something more than just putting the pam_systemd line there?

tomegun · 2011-01-26 16:30:47

lucke wrote:

I tried without loginuid first, the result was the same. Can you paste your /etc/pam.d/login file? Perhaps you've done something more than just putting the pam_systemd line there?

Quite possible, I did this a very long time ago. Could you post the error messages (possibly by adding the systemd line to something less essential than login, so you are able to get at your logs :-) )?

auth            required        pam_securetty.so
auth            requisite       pam_nologin.so
auth            required        pam_unix.so nullok
auth            required        pam_tally.so onerr=succeed file=/var/log/faillog
# use this to lockout accounts for 10 minutes after 3 failed attempts
#auth           required        pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog
account         required        pam_access.so
account         required        pam_time.so
account         required        pam_unix.so
#password       required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
#password       required        pam_unix.so md5 shadow use_authtok
session         required        pam_unix.so
session         required        pam_env.so
session         required        pam_motd.so
session         required        pam_limits.so
session         required        pam_systemd.so kill-user=1
session         optional        pam_mail.so dir=/var/spool/mail standard
session         optional        pam_lastlog.so
# install consolekit and uncomment the line below
#   to have ACL handle non-standard udev permissions
session         optional        pam_ck_connector.so

lucke · 2011-01-26 16:54:12

With a login file apparently like yours, I get System Error while logging. If I add that line to sshd or passwd, I can use them without a problem. Somewhat fishy. I don't know how to debug it. Oh well.

-edit-

Yay, I get "[login] pam_systemd(login:session): Failed to create runtime directory: No such file or directory"
in the logs. There is /var/run/user/. Maybe it needs some cgroups stuff.

Last edited by lucke (2011-01-26 17:07:20)

Viper_Scull · 2011-01-27 18:49:11

After finally gotten rid of hal (now using upower and udisks) with KDE 4.6 i finally tried systemd.

It boots, kdm starts, i can see the desktop and the mouse pointer. But mouse won't move, and keyboard won't work (both are usb devices). I cant get to a tty so i have to do a hard reboot.
Then I booted with verbose option, but as far i could see no errors were reported. Similar behavior.

kernel is 2.6.37-ck. I checked the options needed in config and they are all met.

Services enabled are:

services wrote:

default.target.wants/systemd-readahead-collect.service local-fs.target.wants/quotaon.service
default.target.wants/systemd-readahead-replay.service multi-user.target.wants/alsa.service
getty.target.wants/getty@tty1.service multi-user.target.wants/network.service
getty.target.wants/getty@tty2.service multi-user.target.wants/rc-local.service
graphical.target.wants/console-kit-daemon.service sysinit.target.wants/hwclock-load.service
graphical.target.wants/kdm@tty7.service syslog.target.wants/syslog-ng.service
local-fs.target.wants/quotacheck.service

Is a log file created? I have /var/log mounted on a tmpfs partition so it's gone after a reboot. I could change that if it'd help.

Are udisks.service and upower.services needed to be enabled? I thought they'd be called anyway.

Last edited by Viper_Scull (2011-01-27 20:57:24)

Arch Linux

#126 2011-01-25 15:54:27

Re: systemd: Yet Another Init Replacement

#127 2011-01-25 16:02:19

Re: systemd: Yet Another Init Replacement

#128 2011-01-25 16:09:09

Re: systemd: Yet Another Init Replacement

#129 2011-01-25 16:47:53

Re: systemd: Yet Another Init Replacement

#130 2011-01-25 17:02:57

Re: systemd: Yet Another Init Replacement

#131 2011-01-25 17:06:31

Re: systemd: Yet Another Init Replacement

#132 2011-01-25 17:13:59

Re: systemd: Yet Another Init Replacement

#133 2011-01-25 17:29:36

Re: systemd: Yet Another Init Replacement

#134 2011-01-25 17:36:14

Re: systemd: Yet Another Init Replacement

#135 2011-01-25 17:42:57

Re: systemd: Yet Another Init Replacement

#136 2011-01-25 18:00:23

Re: systemd: Yet Another Init Replacement

#137 2011-01-25 18:28:26

Re: systemd: Yet Another Init Replacement

#138 2011-01-25 18:46:26

Re: systemd: Yet Another Init Replacement

#139 2011-01-26 00:34:47

Re: systemd: Yet Another Init Replacement

#140 2011-01-26 01:29:31

Re: systemd: Yet Another Init Replacement

#141 2011-01-26 01:50:13

Re: systemd: Yet Another Init Replacement

#142 2011-01-26 03:00:52

Re: systemd: Yet Another Init Replacement

#143 2011-01-26 13:14:39

Re: systemd: Yet Another Init Replacement

#144 2011-01-26 14:01:07

Re: systemd: Yet Another Init Replacement

#145 2011-01-26 15:27:01

Re: systemd: Yet Another Init Replacement

#146 2011-01-26 16:02:00

Re: systemd: Yet Another Init Replacement

#147 2011-01-26 16:13:28

Re: systemd: Yet Another Init Replacement

#148 2011-01-26 16:30:47

Re: systemd: Yet Another Init Replacement

#149 2011-01-26 16:54:12

Re: systemd: Yet Another Init Replacement

#150 2011-01-27 18:49:11

Re: systemd: Yet Another Init Replacement

Board footer