systemd: Yet Another Init Replacement

unikum · 2012-04-15 19:58:18

graysky wrote:

algorythm wrote:
Otherwise it's just as fast as the default init, despite its "aggressive parallelization capabilities" and all that shit, which was a bit disappointing.
Faster on an SSD.

I use btrfs with compression on the SSD with systemd and this is really fast. Boot (xbmc standalone) about 10 seconds after press power button:)

litemotiv · 2012-04-15 19:59:12

algorythm wrote:

Otherwise it's just as fast as the default init, despite its "aggressive parallelization capabilities"

How are you measuring this?

algorythm · 2012-04-15 23:07:16

graysky wrote:

algorythm wrote:
Otherwise it's just as fast as the default init, despite its "aggressive parallelization capabilities" and all that shit, which was a bit disappointing.
Faster on an SSD.

Yeah. Just so goddamn expensive those things.

litemotiv wrote:

How are you measuring this?

Just used my cell phone's stopwatch. Bootchart(2) wouldn't do.

ron9 · 2012-04-16 07:56:25

algorythm wrote:

Bootchart(2) wouldn't do.

Have you tryed bootchart from extra repository?

Her is mine bootchart without SSD. If I do understand it correctly, it is 8.7sec to login....

http://ompldr.org/vZGU2Yw/bootchart-20120415-1200.svg

algorythm · 2012-04-16 09:48:06

I'm assuming it starts too slow and ends too fast.

By the way, even your X starts at 15.7s.

ron9 · 2012-04-16 10:17:50

algorythm wrote:

By the way, even your X starts at 15.7s.

Yes, after my slow login...

If you want to try to bootchart from the extra repository, replace init=/bin/systemd with init=/usr/bin/bootchartd in the kernel command line.
Then copy /usr/share/doc/bootchartd.conf.example to /etc/bootchartd.conf
Edit as desired, but insert init=/bin/systemd after # path to non-standard init. Save and create a new boot entry in grub or edit grub on the run.

Happy testing!

algorythm · 2012-04-16 10:47:43

Yeah, I mean, I know how it works it just wouldn't work well enough.

PReP · 2012-04-16 15:23:28

Mainly I find dhcp-leases and "bloated"-DMs/Login-managers to be the most time-consuming tasks,
neither of which i use personally.

Besides that, daemons and other init-stuff is so fast already, on recent and moderately-recent hardware.

I haven't bothered with measuring my grub-to-login-prompt, but it is close to about 5-6 seconds most probable on my Intel 2500k,
and around 7-9 seconds on an older AMD phenom 2x.

Autostarting X, semi-manually (non login-manager) to openbox, might add 2-3 seconds more on top of that.

That is a small difference, and i do not know what i would do with some saved seconds from that
- type in a character or two more/earlier then before?, or move the mouse across the screen some second earlier?

Last edited by PReP (2012-04-16 15:24:37)

litemotiv · 2012-04-26 15:46:08

tomegun wrote:

Da_Coynul wrote:
MartinZ wrote:
I just updated my box (haven't done that in about a week) and now I can't boot. I'm currently running from a liveUSB. I use testing repo (because I need Libreoffice 3.5) and linux-ck.
Trying to boot gives me this:
Welcome to emergency mode. Use "systemctl default" or ^D to activate default mode.
However, I cannot log in nor write anything, just rebooting with ctrl+alt+supr works. This seems to be because of an update which overwrote my /etc/inittab thus misconfiguring fgetty, will test in next reboot.
Same thing happened here so I reverted to a pre-update backup, changed back to initscripts from systemd, updated and then changed back to systemd. Now everything is working but I would like to know the cause / fix just in case it happens again and I am caught without a recent backup.
I have not seen this behavior. You mention fgetty, might that be the cause? Do you have any other non-standard packages installed that might be related? Changes to /etc/inittab should not be related, as systemd ignores that file.

I'm also seeing the above intermittently after a system update or non-clean shutdown, rebooting results in getting stuck in emergency mode. Although system-fsck seems to fix any errors or orphan inodes, each consecutive boot then keeps dropping to emergency mode. I have to boot from an usbstick and do a manual fsck from there to get things running again. I haven't really found a consistent pattern here because sometimes systemd does boot through cleanly after a bad shutdown, so i'm not sure what's triggering this...

darkfeline · 2012-05-01 19:13:34

Hi everyone.

I recently picked up systemd, and I've got it working somehow, but I'm only marginally acquainted with how arch linux does its BSD wrapped sysv and the current state of systemd in arch linux. I'd just like to confirm some points:

The MODULES and DAEMONS line in rc.conf are equivalent to systemctl enable <unit file>.

rc.conf, inittab and related files are not used by systemd, and their configuration options are scattered in various systemd files (e.g. /etc/hostname, /etc/locale.conf, manually linking /etc/localtime, etc.)

/etc/rc.d and /etc/fstab are used as fallback configuration/init files by systemd.

Currently, systemd-arch-units provides unit files for many services (but this should ideally be split into their respective packages).

Currently, intiscripts-systemd is a "hackish" fix for wrapping systemd around rc.conf and other arch config files (and includes unit files too)

Are all of those about right?

65kid · 2012-05-01 19:33:55

darkfeline wrote:

The MODULES and DAEMONS line in rc.conf are equivalent to systemctl enable <unit file>.

the MODULES equivelant is actually /etc/modules-load.d/ (see wiki).

darkfeline wrote:

rc.conf, inittab and related files are not used by systemd, and their configuration options are scattered in various systemd files (e.g. /etc/hostname, /etc/locale.conf, manually linking /etc/localtime, etc.)

sounds about right to me.

darkfeline wrote:

/etc/rc.d and /etc/fstab are used as fallback configuration/init files by systemd.

/etc/rc.d is kind of a fallback, but afaik you can only start rc.d service with "systemctl start", but not actually enable them to start at boot. Not sure about this though..
/etc/fstab isn't exactly fallback, afaik it's officially supported and will be. After all a line in /etc/fstab is way simpler than creating a separate .mount file.

darkfeline wrote:

Currently, systemd-arch-units provides unit files for many services (but this should ideally be split into their respective packages).

As far as I know the unit files from systemd-arch-units are currently being moved into the acorrding packages one by one, so systemd-arch-units will be basically empty and therefore obsolete eventually.

darkfeline wrote:

Currently, intiscripts-systemd is a "hackish" fix for wrapping systemd around rc.conf and other arch config files (and includes unit files too)

yes. I actually don't know if there is still a good reason to use this package since unit files for most services are available by now. And even if not it's imho pretty easy to write one yourself.

tomegun · 2012-05-01 20:04:41

Hi darkfeline,

Seems you got it more or less right, I'll add some clarifications just in case:

darkfeline wrote:

The MODULES and DAEMONS line in rc.conf are equivalent to systemctl enable <unit file>.

Listing "cups" in DAEMONS is equivalent to "systemctl enable cups.service". Listing "kvm_intel" in MODULES is equivalent to adding a line containing "kvm_intel" to a file /etc/modules-load.d/kvm.conf. (you can of course call the file anything you want ending in .conf). Installing iniscripts-systemd allows systemd to read MODULES and DAEMONS just like before (though it is probably a better idea to just stick with pure systemd configuration if you can).

rc.conf, inittab and related files are not used by systemd, and their configuration options are scattered in various systemd files (e.g. /etc/hostname, /etc/locale.conf, manually linking /etc/localtime, etc.)
/etc/rc.d and /etc/fstab are used as fallback configuration/init files by systemd.

rc.conf is used as a fallback configuration file for many options (though not all make sense in systemd). /etc/fstab should be used to configure mounts just as before (though you could also use systemd's .mount files, but that is mostly for packagers/distro's to use, and not admins). If you install initscripts-systemd you can use /etc/rc.d/* as fallback files, otherwise it is ignored.

Currently, systemd-arch-units provides unit files for many services (but this should ideally be split into their respective packages).

Correct, and this is slowly, but surely happening.

Currently, intiscripts-systemd is a "hackish" fix for wrapping systemd around rc.conf and other arch config files (and includes unit files too)

It is mainly to wrap DAEMONS (possibly using rc scripts in /etc/rc.d if native systemd units are not installed) and MODULES.

Leonid.I · 2012-05-01 21:10:03

Hi,

I've been playing with systemd in the recent days, and it works quite well -- very nicely ported to arch. However, I have a problem with sound playback, namely:

* sound.service is loaded and active, there are sound controls for all users while in console (default.target -> multi-user.target). This is true even if no consolekit is running. systemd-loginctl reports 1 user logged in, at seat 0.

* After starting xfce via startx (exec ck-launch-session startxfce4), there is no sound available. alsamixer reports that there are no mixers... Again, this is irrespective of CK, but w/o CK I can't also shutdown. WHen CK is running, ck-list-sessions returns active, local as it should.

This looks like premission problem to me, because with initscripts, CK handled access to /dev/snd/* just fine. But the only discrepance which I found is that CK reports seat1, while loginctl -- seat0, don't know if that's relevant.

Also I wonder, is it possible to get rid of CK, as loginctl is supposed to manage permissions now.

Any ideas are appreciated.... TIA

tomegun · 2012-05-01 23:48:34

Leonid: my guess would be that you don't have pam_systemd.so in your xfce pam file. I'll have to get back to details tomorrow, as i have to run :-)

Leonid.I · 2012-05-02 18:58:30

Hmm, xfce4 doesn't hook into pam directly -- only through CK. I have a stock pam.d/login which ends with

-session	optional	pam_ck_connector.so nox11
-session	optional	pam_systemd.so

otherwise I wouldn't be able to play sounds in console. I'll take a look at Fedora's xfce spin...

tomegun · 2012-05-02 19:10:09

Leonid: system-logind takes over for consolekit, and for the purposes of ACL (permissions) consolekit is no longer needed (and in fact not used even when running) if you boot with systemd. That said, you probably can't remove consolekit entirely, as it still provides some API's that might be in use by your DE (e.g. to shut down the machine).

The pam.d/login snippet is correct, in that it contains pam_systemd.so. However, you'd need something similar for xfce to get a pam session started for that too (and hence pam_systemd activated).

To debug, I suggest systemd-loginctl both when logged in on the console, and when logged in to xfce.

PS: I have never used xfce, so there might be something obvious that I'm missing... Maybe someone else have used xfce with systemd?

65kid · 2012-05-03 11:58:38

I had a similiar experience when I tried to start XFCE without a display manager with a service file ( https://wiki.archlinux.org/index.php/Sy … rvice_file ). Sound didn't work and shutdown etc. were greyed out.
I also tried to use systemd's User= property instead of using /bin/su and some other things, but nothing worked. I eventually gave up and am using LXDM autologin now, but I think I'm going to look into it again, I would love to get rid of my display manager...

65kid · 2012-05-03 12:57:31

found something, see the second comment on this page: http://utcc.utoronto.ca/~cks/space/blog … owcomments
so systemd doesn't support starting X on a new VT. the mentioned -noswitchvt is actually -novtswitch and for some reason this doesn't work, seems like X simply ignores it. I forced X to start on vt01 instead.

/etc/X11/xinit/xserverrc

exec /usr/bin/X vt01 -nolisten tcp "$@"

If I then simply put "exec startxfce4" (without ck-launch-session) in my .xinitrc, I can "startx" from tty1 and sound, shutdown etc. works. My locale isn't set in this case, but this may be another issue.

This still doesn't work with a service file though.

Leonid.I · 2012-05-03 19:34:52

tomegun wrote:

Leonid: system-logind takes over for consolekit, and for the purposes of ACL (permissions) consolekit is no longer needed (and in fact not used even when running) if you boot with systemd. That said, you probably can't remove consolekit entirely, as it still provides some API's that might be in use by your DE (e.g. to shut down the machine).
The pam.d/login snippet is correct, in that it contains pam_systemd.so. However, you'd need something similar for xfce to get a pam session started for that too (and hence pam_systemd activated).

RIght. xfce-session still needs CK, even in F17: https://bugzilla.redhat.com/show_bug.cgi?id=797328.

tomegun wrote:

To debug, I suggest systemd-loginctl both when logged in on the console, and when logged in to xfce.

OK, here it goes. xfce4 is started via startx with xinitrc containing "exec ck-launch-session startxfce4", so the dbus session is initiated. While still in console:

> tail -n2 /etc/pam.d/login
-session	optional	pam_ck_connector.so nox11
-session	optional	pam_systemd.so
> ps -e u | grep kit
root       304  0.0  0.6  29060  3184 ?        Ssl  14:09   0:00 /usr/sbin/console-kit-daemon --no-daemon
root       371  0.0  0.5  24680  2828 ?        Sl   14:09   0:00 /usr/lib/polkit-1/polkitd --no-debug
> ck-list-sessions
Session1:
	unix-user = '1000'
	realname = '(null)'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ''
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-05-03T19:09:55.941555Z'
	login-session-id = '1'
> systemd loginctl
SESSION        UID USER            SEAT
            1       1000 lisaev           seat0
> amixer info
Card default 'Intel'/'HDA Intel at 0xfebf0000 irq 43'
  Mixer name	: 'Generic 1af4 ID 20'
  Components	: 'HDA:1af40020,1af40020,00100101'
  Controls      : 2
  Simple ctrls  : 2

(yeah, generic sound card, since it's a KVM guest), speaker-test/audio playback works as expected. When inside xfce:

> ck-list-sessions
Session2:
	unix-user = '1000'
	realname = '(null)'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/tty2'
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-05-03T19:16:28.839795Z'
	login-session-id = '1'
Session1:
	unix-user = '1000'
	realname = '(null)'
	seat = 'Seat1'
	session-type = ''
	active = FALSE
	x11-display = ''
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-05-03T19:09:55.941555Z'
	login-session-id = '1'
	idle-since-hint = '2012-05-03T19:16:55.808919Z'
> systemd loginctl
SESSION        UID USER            SEAT
            1       1000 lisaev           seat0
> amixer info
amixer: Control device default open error: No such file or directory

Of course, the sound is broken at this point. However, I can shutdown, reboot, ...

tomegun wrote:

PS: I have never used xfce, so there might be something obvious that I'm missing... Maybe someone else have used xfce with systemd?

Basically, xfce-session uses CK directly w/o a login manager (in 4.8 I have to call ck-launch-session explicitly, in 4.10 startxfce4 has a CLI switch). I haven't tried GDM, which is supposed to have a native systemd functionality. FOr all practical purposes, starting xfce via startx is equivalent to using XDM (it reads $HOME/.xsession).

Thanks for your time.

tomegun · 2012-05-03 19:35:33

@65kid: the issue is that you need something (typically your display manager) to create a new PAM session for you. If you use startx you'll just be using the pam session created for your console login, so that's fine.

Maybe at some point there will be support for systemd itself doing this (using systemd --user), and it might even work now, but I have not looked into it, and it is not really tested/documented. For the time being I recommend using a display manager, unless you want to really get your feet wet :-)

Leonid.I · 2012-05-03 19:48:45

65kid wrote:

found something, see the second comment on this page: http://utcc.utoronto.ca/~cks/space/blog … owcomments
so systemd doesn't support starting X on a new VT. the mentioned -noswitchvt is actually -novtswitch and for some reason this doesn't work, seems like X simply ignores it. I forced X to start on vt01 instead.
/etc/X11/xinit/xserverrc
exec /usr/bin/X vt01 -nolisten tcp "$@"
If I then simply put "exec startxfce4" (without ck-launch-session) in my .xinitrc, I can "startx" from tty1 and sound, shutdown etc. works. My locale isn't set in this case, but this may be another issue.
This still doesn't work with a service file though.

So you can just do "startx -- vt1", yes? This b0rks CK because:

Session9:
	unix-user = '1000'
	realname = '(null)'
	seat = 'Seat5'
	session-type = ''
	active = FALSE
	x11-display = ':0'
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-05-03T19:45:38.151634Z'
	login-session-id = '1'
Session1:
	unix-user = '1000'
	realname = '(null)'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ''
	x11-display-device = ''
	display-device = '/dev/tty1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2012-05-03T19:09:55.941555Z'
	login-session-id = '1'
	idle-since-hint = '2012-05-03T19:46:07.786574Z'

Now sound works because I am connected to the 1st CK session (console) which was OK initially. However, I don't have shutdown ability any more...

tomegun · 2012-05-03 19:54:53

@Leonid: so it seems pretty clear. consolekit creates a new session when you enter xfce, but according to systemd you still only have one session (and my guess is that if you now do "systemd-loginctl session-status <your session id>" it is no longer active). A login manager would sort this out for you (until systemd has proper support for this kind of stuff (which, by the way, i believe will be awesome!)).

65kid · 2012-05-03 20:16:59

thanks, this clears things up a little. It has always been a little confusing to me how this whole PAM/ConsoleKit/PolicyKit etc stuff works. So I'm gonna stick with LXDM for now, at least it works well with systemd and doesn't pull in half gnome like GDM does.

Another thing: I noticed that my locale isn't set when I login via SSH into another machine of mine which is running systemd as well. I'm pretty sure my locale was set before with initscripts.

/etc/locale.conf on the remote machine:

LANG=de_DE.UTF-8
LC_COLLATE=C

these variables are both not set when I login with SSH. I'm using sshd.socket from systemd-arch-units btw.

tomegun · 2012-05-03 20:23:55

@65kid: check "man 5 ssh_config" for SendEnv (if you want the locale on your local machine to be set in the session on the remote machine).

In principle the ssh daemon on the server should inherit the locale from systemd, but it might be unset before it reaches your login shell, I have not looked into exactly how ssh deal with that.

The way it used to work was that we put a file /etc/profile.d/locale.sh that would be called by bash to set the locale when you logged in. This was in my view always a hack, and I'd much prefer if we manage to do without that. However, if you can't figure it out, one option is to just get that file from the initscripts package and things should just work as before.

65kid · 2012-05-03 20:38:58

yep, SendEnv works, also had to specify AcceptEnv on the server. thanks.

Arch Linux

#1351 2012-04-15 19:58:18

Re: systemd: Yet Another Init Replacement

#1352 2012-04-15 19:59:12

Re: systemd: Yet Another Init Replacement

#1353 2012-04-15 23:07:16

Re: systemd: Yet Another Init Replacement

#1354 2012-04-16 07:56:25

Re: systemd: Yet Another Init Replacement

#1355 2012-04-16 09:48:06

Re: systemd: Yet Another Init Replacement

#1356 2012-04-16 10:17:50

Re: systemd: Yet Another Init Replacement

#1357 2012-04-16 10:47:43

Re: systemd: Yet Another Init Replacement

#1358 2012-04-16 15:23:28

Re: systemd: Yet Another Init Replacement

#1359 2012-04-26 15:46:08

Re: systemd: Yet Another Init Replacement

#1360 2012-05-01 19:13:34

Re: systemd: Yet Another Init Replacement

#1361 2012-05-01 19:33:55

Re: systemd: Yet Another Init Replacement

#1362 2012-05-01 20:04:41

Re: systemd: Yet Another Init Replacement

#1363 2012-05-01 21:10:03

Re: systemd: Yet Another Init Replacement

#1364 2012-05-01 23:48:34

Re: systemd: Yet Another Init Replacement

#1365 2012-05-02 18:58:30

Re: systemd: Yet Another Init Replacement

#1366 2012-05-02 19:10:09

Re: systemd: Yet Another Init Replacement

#1367 2012-05-03 11:58:38

Re: systemd: Yet Another Init Replacement

#1368 2012-05-03 12:57:31

Re: systemd: Yet Another Init Replacement

#1369 2012-05-03 19:34:52

Re: systemd: Yet Another Init Replacement

#1370 2012-05-03 19:35:33

Re: systemd: Yet Another Init Replacement

#1371 2012-05-03 19:48:45

Re: systemd: Yet Another Init Replacement

#1372 2012-05-03 19:54:53

Re: systemd: Yet Another Init Replacement

#1373 2012-05-03 20:16:59

Re: systemd: Yet Another Init Replacement

#1374 2012-05-03 20:23:55

Re: systemd: Yet Another Init Replacement

#1375 2012-05-03 20:38:58

Re: systemd: Yet Another Init Replacement

Board footer