systemd: Yet Another Init Replacement

denisfalqueto · 2011-01-23 22:08:59

falconindy wrote:

This is supposed to be triggered by arch-daemons.target. We may still have some bugs to hunt down...

I've noted that arch-daemons.target doesn't have a ExecStart section. Indeed, it just have a Description and a WantedBy=multi-user.target. Shouldn't it have some connection to a script to really start the entries in DAEMONS array?

Thanks for your work. It is really great! I'm enjoying systemd in Arch very well.

falconindy · 2011-01-23 23:49:27

No. A service has an Exec{Start,Stop,Restart,Reload} section. A target is a logical grouping. systemd.{unit,service,target}(5) explain these in a fair amount of detail.

markbabc · 2011-01-24 00:08:23

any reason why i cant replace util-linux-ng with util-linux-git? Clyde is failing to replace it

ngoonee · 2011-01-24 00:45:46

markbabc wrote:

any reason why i cant replace util-linux-ng with util-linux-git? Clyde is failing to replace it

That's a clyde issue. Please learn to use makepkg, helpers are just that, good for convenience but you should know how to do without them if necessary.

markbabc · 2011-01-24 00:47:34

ngoonee wrote:

markbabc wrote:
any reason why i cant replace util-linux-ng with util-linux-git? Clyde is failing to replace it
That's a clyde issue. Please learn to use makepkg, helpers are just that, good for convenience but you should know how to do without them if necessary.

yea i did it manually, i ment to edit my post here but i forgot to

tomegun · 2011-01-24 12:24:40

AugustePop wrote:

falconindy wrote:
Systemd understands dependencies. Unit files have settings like 'After=network.target', meaning that a unit won't start until the network.target dependency has been satisfied. It's simple enough to just reverse this for shutdown.
that means the dependency of daemons in systemd is also a DAG?

In systemd there are two kinds of dependencies. The "Requires/Wants" which is a (possibly cyclic) graph; and "After" which is a DAG.

lucke · 2011-01-24 16:11:10

The problems I've encountered:

1) many things from the DAEMONS array which don't have native systemd units don't get started: in my case it's metalog, acpid, autofs, net-profiles and iptables; only privoxy and laptop-mode are started; every now and then "systemd[1]: //lib/systemd/system-generators/arch-daemons exited with exit status 1." pops out in the logs.
2) starting cups.socket, as someone already mentioned, doesn't spawn cups properly on demand, because cups complains the address/port is already in use.
3) I had to rm /etc/mtab and symlink it to /proc/self/mounts to avoid having double entries in df.

tomegun · 2011-01-24 16:31:26

Hi lucke,

Thanks for testing, your comments are very helpful.

lucke wrote:

1) many things from the DAEMONS array which don't have native systemd units don't get started: in my case it's metalog, acpid, autofs, net-profiles and iptables; only privoxy and laptop-mode are started; every now and then "systemd[1]: //lib/systemd/system-generators/arch-daemons exited with exit status 1." pops out in the logs.

Ooops, this is bad. Dave just sent me a new version of the arch-daemons script for review. Ill do it tonight after work.

lucke wrote:

2) starting cups.socket, as someone already mentioned, doesn't spawn cups properly on demand, because cups complains the address/port is already in use.

Thanks for pointing this out again, I think we have to just disable the socket activation for the time being (until this is fixed upstream), Ill make a patch tonight.

lucke wrote:

3) I had to rm /etc/mtab and symlink it to /proc/self/mounts to avoid having double entries in df.

Yes, this is a known issue. We dont do this by default because it would cause regressions for a few users (I believe /proc/self/mounts cant deal properly with fuse or something along those lines). This will be fixed upstream (in util-linux) in the near future, and then everyone (both systemd and the rest of Arch) can move to useing the symlink. I belive keeping mtab as a normal feel is harmless (except for the annotance you describe and the warnings from systemd).

I will update the wiki tonight (unless someone beat me to it ;-) ).

lucke · 2011-01-24 17:36:52

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.

ngoonee · 2011-01-25 00:13:17

Anyone have experience hibernating on a systemd-based system?

Also, I tend to use 'telinit 3' and then 'telinit 5' pretty often, is it possible to change 'targets' without rebooting and changing the grub line?

falconindy · 2011-01-25 01:03:08

ngoonee wrote:

Anyone have experience hibernating on a systemd-based system?
Also, I tend to use 'telinit 3' and then 'telinit 5' pretty often, is it possible to change 'targets' without rebooting and changing the grub line?

Sure can.

systemctl isolate foo.target

No experience with hibernation.

Last edited by falconindy (2011-01-25 01:03:22)

ngoonee · 2011-01-25 01:55:16

Thanks falconindy. Final question - wiki mentions dmesg/syslog spamming. Is there any current 'solution' to that other than waiting for syslong-ng/rsyslog to update?

falconindy · 2011-01-25 02:01:04

boot with the 'quiet' parameter. that'll sanitize most of your console output. otherwise, we need to get off our duffs and write the necessary patchwork for syslog-ng.

Last edited by falconindy (2011-01-25 02:01:38)

denisfalqueto · 2011-01-25 03:11:23

Just a heads-up for thos using kdm: it has changed from kdm@.service to kdm.service. So, you need to rm the old symlink from /etc/systemd/system/graphical.target.wants and enable the new service. I've just got bitten by that right now

ngoonee · 2011-01-25 03:19:40

@falconindy, I can't find gdm.service (this is mentioned previously a page or so back but no comment given). Was this removed from the arch-units? I tried to copy kdm.service to /etc/systemd/system/gdm.service and renaming the executable, but it fails to load.

falconindy · 2011-01-25 03:36:24

Can you be a little more specific than 'fails to load'? Did you reload systemd after adding it? Did you enable it? Does it throw an error? Can you start it manually? I don't use GDM so it's hard for me to know the difference in invocation between kdm and gdm (which looks to be null based on /etc/inittab).

Last edited by falconindy (2011-01-25 03:36:43)

denisfalqueto · 2011-01-25 03:37:08

It would be good if wicd.service could have a Requires=network.target and After=network.target, just like remote-fs.target. That way, I could disable remote-fs.target.

falconindy · 2011-01-25 03:39:54

wicd.service can't require network.target. When network.target is satisfied, its assumed that the OS now has a network connection. It would only make sense to have wicd.service have a 'Before=network.target' property. But, since we can't count on everyone using wicd, we use an install section. You enable the wicd.service unit, and it's then WantedBy network.target which is more or less the same as the Before= property.

denisfalqueto · 2011-01-25 04:19:05

Hmm, the thing is that whenever I disable remote-fs.target (which I don't need), wicd.service is not started, even though it is enabled. I compared with NetworkManager.service and its WantedBy is multi-user.target. Shouldn't it be a similar situation for wicd.service?

ngoonee · 2011-01-25 05:41:51

falconindy wrote:

Can you be a little more specific than 'fails to load'? Did you reload systemd after adding it? Did you enable it? Does it throw an error? Can you start it manually? I don't use GDM so it's hard for me to know the difference in invocation between kdm and gdm (which looks to be null based on /etc/inittab).

Sorry, user idiocy, /usr/bin instead of /usr/sbin (kdm is in /usr/bin but gdm is /usr/sbin). Seems to work now.

I see acpid and dovecot are not implemented. For dovecot in particular, a question:-

Dovecot provides a service to a port, is it therefore possible to have dovecot not start until something tries to access it? Evolution, in my case. I'd presume this would not be as simple as just writing a service file?

Otherwise my system seems booted, so will test things out and get used to them .

falconindy · 2011-01-25 11:47:01

denisfalqueto wrote:

Hmm, the thing is that whenever I disable remote-fs.target (which I don't need), wicd.service is not started, even though it is enabled. I compared with NetworkManager.service and its WantedBy is multi-user.target. Shouldn't it be a similar situation for wicd.service?

The opposite. NetworkManager should be fixed because its wrong. I'm using a static IP via network.service and it comes up just fine as a wantedby. Ill see if I can duplicate the issue with wife.

Ignore this and my phone's hillarious autocorrect of 'wicd' to 'wife'. I see why remote-fs.target is "needed" to get network started... i'll figure out a solution to this.

Last edited by falconindy (2011-01-25 14:55:31)

falconindy · 2011-01-25 11:51:11

ngoonee wrote:

falconindy wrote:
Can you be a little more specific than 'fails to load'? Did you reload systemd after adding it? Did you enable it? Does it throw an error? Can you start it manually? I don't use GDM so it's hard for me to know the difference in invocation between kdm and gdm (which looks to be null based on /etc/inittab).
Sorry, user idiocy, /usr/bin instead of /usr/sbin (kdm is in /usr/bin but gdm is /usr/sbin). Seems to work now.
I see acpid and dovecot are not implemented. For dovecot in particular, a question:-
Dovecot provides a service to a port, is it therefore possible to have dovecot not start until something tries to access it? Evolution, in my case. I'd presume this would not be as simple as just writing a service file?
Otherwise my system seems booted, so will test things out and get used to them .

Acpid has an AF_UNIX socket of its own as well. We could probably declare socket files for both and trigger activation on demand. May not make sense for acpid depending on its behavior.

ngoonee · 2011-01-25 11:54:15

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'.

lucke · 2011-01-25 12:52:35

arch-daemons still doesn't seem to work after your revision, falconindy. I don't see "arch-daemons.wants" anywhere, rc,conf daemons are "masked" in systemctl and only privoxy got started.

ngoonee · 2011-01-25 15:49:31

Yes, the same here. systemctl start *.service where * exists in /etc/rc.d but not in /lib/systemd/system gives the 'masked' warning.

Arch Linux

#101 2011-01-23 22:08:59

Re: systemd: Yet Another Init Replacement

#102 2011-01-23 23:49:27

Re: systemd: Yet Another Init Replacement

#103 2011-01-24 00:08:23

Re: systemd: Yet Another Init Replacement

#104 2011-01-24 00:45:46

Re: systemd: Yet Another Init Replacement

#105 2011-01-24 00:47:34

Re: systemd: Yet Another Init Replacement

#106 2011-01-24 12:24:40

Re: systemd: Yet Another Init Replacement

#107 2011-01-24 16:11:10

Re: systemd: Yet Another Init Replacement

#108 2011-01-24 16:31:26

Re: systemd: Yet Another Init Replacement

#109 2011-01-24 17:36:52

Re: systemd: Yet Another Init Replacement

#110 2011-01-25 00:13:17

Re: systemd: Yet Another Init Replacement

#111 2011-01-25 01:03:08

Re: systemd: Yet Another Init Replacement

#112 2011-01-25 01:55:16

Re: systemd: Yet Another Init Replacement

#113 2011-01-25 02:01:04

Re: systemd: Yet Another Init Replacement

#114 2011-01-25 03:11:23

Re: systemd: Yet Another Init Replacement

#115 2011-01-25 03:19:40

Re: systemd: Yet Another Init Replacement

#116 2011-01-25 03:36:24

Re: systemd: Yet Another Init Replacement

#117 2011-01-25 03:37:08

Re: systemd: Yet Another Init Replacement

#118 2011-01-25 03:39:54

Re: systemd: Yet Another Init Replacement

#119 2011-01-25 04:19:05

Re: systemd: Yet Another Init Replacement

#120 2011-01-25 05:41:51

Re: systemd: Yet Another Init Replacement

#121 2011-01-25 11:47:01

Re: systemd: Yet Another Init Replacement

#122 2011-01-25 11:51:11

Re: systemd: Yet Another Init Replacement

#123 2011-01-25 11:54:15

Re: systemd: Yet Another Init Replacement

#124 2011-01-25 12:52:35

Re: systemd: Yet Another Init Replacement

#125 2011-01-25 15:49:31

Re: systemd: Yet Another Init Replacement

Board footer