systemd: Yet Another Init Replacement

benneque · 2011-03-21 10:36:30

Hmm... then still a few questions:
Have your /lib/systemd/system/plymouth-*.service files those [Install] sections ?
When you're in Gnome: open your taskmanager and look if plymouth is still runnning.

On shutdown it's strange here, too: KDE exits, then I see the console and after 1-2 seconds plymouth starts to display.
On reboot: KDE exits and plymouth is there with animation, no console inbetween.
Maybe you shuld try reboot instead of shutdown

falconindy · 2011-03-21 13:09:01

Reboot and shutdown work just the same. My .service files do not use [Install] sections, they're just triggered by ordered dependencies in systemd.You'll have to wait until tonight for me to see if plymouth still runs after gnome comes up (i suspect it does not).

benneque · 2011-03-21 15:24:59

Humm.. Then I don't understand why plymouth won't get triggered for me ?

GogglesGuy · 2011-03-21 15:47:02

Congrats on making it to [Community]!

falconindy · 2011-03-21 16:43:10

benneque wrote:

Humm.. Then I don't understand why plymouth won't get triggered for me ?

You are building this into the initcpio, right? I had to add a little to the plymouth install hook (/lib/initcpio/install/plymouth):

  add_file /etc/passwd
  add_file /etc/nsswitch.conf
  add_binary /lib/libnss_files-2.13.so
  add_binary /lib/libnss_files.so.2

Doesn't matter too much where these lines go in the hook, just as long as they're processed. Add 'plymouth' to HOOKS in /etc/mkinitcpio.conf and rebuild either with the plymouth theme setter that's mentioned on plymouth install, or just 'mkinitcpio -p kernel26'.

GogglesGuy wrote:

Congrats on making it to [Community]!

thanks! been a long time in the works... lots of people (particularly Tom) who helped make it happen.

Last edited by falconindy (2011-03-21 16:45:14)

benneque · 2011-03-21 16:50:52

Does it maybe matter WHERE plymouth is in the HOOKS ?
i've got: base, udev, plymouth, autodetect, sata, filesystems

i've added now those 4 lines to the file and rebuild initcpio. what are those 4 line for? i don't know anything about mkinitcpio and those things.

i'll reboot in a couple of minutes and will tell if plymouth gets killed and works at shutdown and reboot

EDIT: reboot done: NO SUCCESS!!!
I have an idea: Maybe it's my systemd configuration and at the end there's no service that pulls in plymouth ?!
Can you tell me which files (and symlinks!) you have in /etc/systemd/ ?

I have system.conf (there's everything commented out, only [Manager] is active.
folder "user" is empty
folder "system":
- default.target (symlink to runlevel5.target and runlevel5.target is a symlink to graphical.target)
- default.target.wants: microcode
- getty.target.wants: getty 1-6
- graphical.target.wants: console-kit-daemon, kdm
- halt.target.wants: is empty
- local-fs.target.wants: quotacheck, quotaon (I'll remove those 2 in the future, I don't need quota)
- multi-user.target.wants: networkmanager, remote-fs.target (will remove remote-fs, I think I don't need it)
- poweroff.target.wants: is empty
- reboot.target.wants: is empty
- socket.target.wants: cups.socket
- sysinit.target.wants: hwclock-load

I think there MUST be somewhere somethink like "requires=plymouth", else there's no reason for systemd to execute plymouth services?!

Last edited by benneque (2011-03-21 17:19:00)

falconindy · 2011-03-21 17:34:34

But that's the magic of systemd (and why I hate it sometimes). All unit files are read in at bootup and ordered accordingly. I've recreated this on my VM at work (though plymouth never quites because i don't have a DM installed). Nothing explicitly requires plymouth.

Here's /etc/systemd/systemd:

/etc/systemd/system
├── default.target.wants
│   ├── systemd-readahead-collect.service -> /lib/systemd/system/systemd-readahead-collect.service
│   └── systemd-readahead-replay.service -> /lib/systemd/system/systemd-readahead-replay.service
├── getty.target.wants
│   ├── getty@tty1.service -> /lib/systemd/system/getty@.service
│   ├── getty@tty2.service -> /lib/systemd/system/getty@.service
│   ├── getty@tty3.service -> /lib/systemd/system/getty@.service
│   ├── getty@tty4.service -> /lib/systemd/system/getty@.service
│   ├── getty@tty5.service -> /lib/systemd/system/getty@.service
│   └── getty@tty6.service -> /lib/systemd/system/getty@.service
├── graphical.target.wants
│   └── console-kit-daemon.service -> /lib/systemd/system/console-kit-daemon.service
├── local-fs.target.wants
├── multi-user.target.wants
│   ├── alsa.service -> /lib/systemd/system/alsa.service
│   ├── dcron.service -> /lib/systemd/system/dcron.service
│   ├── network.service -> /lib/systemd/system/network.service
│   ├── remote-fs.target -> /lib/systemd/system/remote-fs.target
│   └── syslog-ng.service -> /lib/systemd/system/syslog-ng.service
├── network.target.wants
│   └── network.service -> /lib/systemd/system/network.service
├── shutdown.target.wants
│   └── arch-persistent-settings.service -> /lib/systemd/system/arch-persistent-settings.service
└── sysinit.target.wants
    └── hwclock-load.service -> /lib/systemd/system/hwclock-load.service

As for mkinitcpio, yes order of HOOKS matters, but yours looks okay. The 4 additional files added in the install hook are to get around the error at boottime when plymouth tries to resolve UID 0 to a user name (think the function throwing the error is getpwuid_r). In any case, this requires an /etc/passwd and enough of an nsswitch stack to be able to point plymouth to it.

benneque · 2011-03-21 22:42:45

I've reinstalled my whole arch (after destroying whole systemd, etc. ) and now I can say: plymouth runs and gets killed when KDM gets up. really fine!!!

Tomorrow I'll find out if those arch service files and script are making it work Hope I won't kill whole systemd again.

Good night

EDIT: I can say that prefdm.service is not needed. I have only kdm.service enabled
And I get no reboot splash, too... I'll check tomorrow if it needs to be installed

Last edited by benneque (2011-03-21 22:50:19)

frankieboy · 2011-03-22 06:18:46

Hi!

I can't boot with dmraid ssd device, it all hangs at fscking the root fs. I have a software raid non root fs (home, var). Does anybody have a clue?
And how to turn off fsck at every boot? It's harmful for a ssd.

Thanks for any help.

Frankieboy

benneque · 2011-03-22 08:54:26

I don't know if fsck with dmraid is handled normally, then you'll see in /etc/fstab at the end of each line TWO numbers. The last one is for fsck. If it's 1, fsck is enabled for that device. To turn it off set it to "0". But maybe it's different for mdraid

W.F.Cody · 2011-03-22 09:05:29

Does anyone know how systemd measures up to

runit (https://aur.archlinux.org/packages.php?ID=6783 , https://aur.archlinux.org/packages.php?ID=42728) or 9mk-init (https://aur.archlinux.org/packages.php?ID=47529 , https://aur.archlinux.org/packages.php?ID=47530) in terms of simplicity and performance?

Is there a way to experiment with those things safely?

Last edited by W.F.Cody (2011-03-22 09:06:11)

tomegun · 2011-03-22 09:19:45

frankieboy wrote:

I can't boot with dmraid ssd device, it all hangs at fscking the root fs. I have a software raid non root fs (home, var). Does anybody have a clue?
And how to turn off fsck at every boot? It's harmful for a ssd.

You are the first person I've heard of to use systemd with dmraid, so this might be a problem with the unit files I wrote.

Did you try disabling fsck like suggested above? If you managed to boot in this way, could you have a look at "systemctl" to see if there were any failures? If you are not able to boot, you could you add a kernel parameter "verbose" to get some more info.

Cheers,

Tom

Naaduun · 2011-03-22 11:55:23

Hi,

i've been playing around with this the last few days. But i'm wondering about the cgroups. doesn't it conflicts with CONFIG_SCHED_AUTOGROUP in kernel 2.6.38?

my system doesn't boot right now with systemd. but last time it did, make -j 20 foo made my system way less responsive than with the old init.

did anyone noticed this too? a responsive system under heavy load is more important than fast boot time imho.

falconindy · 2011-03-22 12:25:02

Naaduun wrote:

Hi,
i've been playing around with this the last few days. But i'm wondering about the cgroups. doesn't it conflicts with CONFIG_SCHED_AUTOGROUP in kernel 2.6.38?
my system doesn't boot right now with systemd. but last time it did, make -j 20 foo made my system way less responsive than with the old init.
did anyone noticed this too? a responsive system under heavy load is more important than fast boot time imho.

If you think the autogrouper is in conflict with systemd (and i don't), then turn it off via the 'kernel.sched_autogroup_enabled' sysctl.

tomegun · 2011-03-22 14:00:56

falconindy wrote:

If you think the autogrouper is in conflict with systemd (and i don't), then turn it off via the 'kernel.sched_autogroup_enabled' sysctl.

If I understand correctly, systemd does not put user sessions in separate cpu cgroups by default, so there should be no interaction here at all between the autogruping and systemd. The best way to find out is of course to have a look in the /sys/fs/cgroup/cpu folder to see how your processes are grouped.

falconindy · 2011-03-22 14:06:17

tasks by default are grouped per user (with additional cgroups created per service). This is pretty clearly shown by /usr/bin/systemd-cgls.

Last edited by falconindy (2011-03-22 14:06:37)

tomegun · 2011-03-22 15:10:27

falconindy wrote:

tasks by default are grouped per user (with additional cgroups created per service). This is pretty clearly shown by /usr/bin/systemd-cgls.

Yes, but this is just in the named systemd hierarchy, not in the cpu hierarchy.

To compare, have a look in /sys/fs/cgroup/systemd that has two folders, system and user, and have a look in /sys/fs/cgroup/cpu that only has the system folder (assuming you are running systemd with the kernel autogroup disabled. If you enable autogroup there will presumedly be other folders in /sys/fs/cgroup/cpu as well...).

If you want systemd to put users in the cpu hiearchy as well, then this can be enabled by pam_systemd, but this does not play nicely with CONFIG_RT_GROUP_SCHED (there is a worakround in the kernel to make the autogrouping work, but it is not exposed to userspace so systemd cannot use it (afaik)). In short, any process that needs to make itself RT (pulseaudio, jack, etc) will fail.

frankieboy · 2011-03-22 18:37:32

tomegun wrote:

frankieboy wrote:
I can't boot with dmraid ssd device, it all hangs at fscking the root fs. I have a software raid non root fs (home, var). Does anybody have a clue?
And how to turn off fsck at every boot? It's harmful for a ssd.
You are the first person I've heard of to use systemd with dmraid, so this might be a problem with the unit files I wrote.
Did you try disabling fsck like suggested above? If you managed to boot in this way, could you have a look at "systemctl" to see if there were any failures? If you are not able to boot, you could you add a kernel parameter "verbose" to get some more info.
Cheers,
Tom

Hi!

The error message is:
md-assemble.service main process exited code=exited, status=1
seems like the problem is with the non root fs, it's simple fake raid fs (home and var)
Anybody has a clue?

Thx

Frankieboy

falconindy · 2011-03-22 19:45:39

Two things... md-assemble is the old name. It was switched to mdadm.service prior to being moved into [community]. Might explain a few things...

Also, I'm not familiar with dmraid, but isn't mdassemble the wrong util to be using here? Seems to me like dmraid(8) is more appropriate based on /etc/rc.sysinit. Tom, I don't think we even have support for this...

benneque · 2011-03-22 20:04:39

Again plymouth and systemd:

How can I see which services systemd started automatically at boot?
plymouth gets killed and plymouth-quit.service should be the reason for this. So shouldn't it be possible to see it with status "exited" in systemctl?

tomegun · 2011-03-22 22:11:18

falconindy wrote:

Two things... md-assemble is the old name. It was switched to mdadm.service prior to being moved into [community]. Might explain a few things...
Also, I'm not familiar with dmraid, but isn't mdassemble the wrong util to be using here? Seems to me like dmraid(8) is more appropriate based on /etc/rc.sysinit. Tom, I don't think we even have support for this...

Very good points. FakeRAID was just added to the Arch initscripts, so I did not yet add it to our initscripts. I added it to my private repo.

@frankieboy: could you try putting this file <https://github.com/teg/initscripts-syst … id.service> in /lib/systemd/system and running "systemctl --system daemon-reload && systemctl enable dmraid.service"?

@falconindy: feel free to pull if it works for frankieboy and/or you think it looks reasonable.

Naaduun · 2011-03-22 23:01:05

tomegun wrote:

falconindy wrote:
tasks by default are grouped per user (with additional cgroups created per service). This is pretty clearly shown by /usr/bin/systemd-cgls.
Yes, but this is just in the named systemd hierarchy, not in the cpu hierarchy.
To compare, have a look in /sys/fs/cgroup/systemd that has two folders, system and user, and have a look in /sys/fs/cgroup/cpu that only has the system folder (assuming you are running systemd with the kernel autogroup disabled. If you enable autogroup there will presumedly be other folders in /sys/fs/cgroup/cpu as well...).
If you want systemd to put users in the cpu hiearchy as well, then this can be enabled by pam_systemd, but this does not play nicely with CONFIG_RT_GROUP_SCHED (there is a worakround in the kernel to make the autogrouping work, but it is not exposed to userspace so systemd cannot use it (afaik)). In short, any process that needs to make itself RT (pulseaudio, jack, etc) will fail.

well, i googled a bit and found this: http://www.gossamer-threads.com/lists/l … ed#1326224

autogroup is transparent to /sys/fs/cgroup. it certaintly doen't mess up systemd cgroups. but i'm not sure if autogroup does something useful at all in this enviromnent.

Last edited by Naaduun (2011-03-22 23:03:10)

Zom · 2011-03-23 19:44:35

I'd rather use fgetty than the default agetty. What's the best way of doing this? For now, I just edited /lib/systemd/system/getty@.service and switched the exec line to

ExecStart=-/sbin/fgetty %I

(fgetty doesn't need the 38400).

Seems like there should be a cleaner way though. Any recommendations?

tomegun · 2011-03-23 20:20:22

Zom wrote:

I'd rather use fgetty than the default agetty. What's the best way of doing this? For now, I just edited /lib/systemd/system/getty@.service and switched the exec line to
ExecStart=-/sbin/fgetty %I
(fgetty doesn't need the 38400).
Seems like there should be a cleaner way though. Any recommendations?

There is.

Never edit /lib/systemd/system, as it will be overwritten on the next update.

Just copy the file you want to edit to /etc/systemd/system and edit it there.

HTH,

Tom

frankieboy · 2011-03-23 21:51:38

tomegun wrote:

falconindy wrote:
Two things... md-assemble is the old name. It was switched to mdadm.service prior to being moved into [community]. Might explain a few things...
Also, I'm not familiar with dmraid, but isn't mdassemble the wrong util to be using here? Seems to me like dmraid(8) is more appropriate based on /etc/rc.sysinit. Tom, I don't think we even have support for this...
Very good points. FakeRAID was just added to the Arch initscripts, so I did not yet add it to our initscripts. I added it to my private repo.
@frankieboy: could you try putting this file <https://github.com/teg/initscripts-syst … id.service> in /lib/systemd/system and running "systemctl --system daemon-reload && systemctl enable dmraid.service"?
@falconindy: feel free to pull if it works for frankieboy and/or you think it looks reasonable.

I'm using arch with fakeraid since december 2007 with the normal initscripts, in this summer I bought this ocz revodrive with a builtin raid controller, and this is only working with dmraid with the normal initscripts, however with systemd I've no luck with or without dmraid.service or with or without md-assemble.service or both. With dmraid.service it stops at assembling fakeraid arrays.

Any clue?

Thank you for your help

Frankieboy

Arch Linux

#251 2011-03-21 10:36:30

Re: systemd: Yet Another Init Replacement

#252 2011-03-21 13:09:01

Re: systemd: Yet Another Init Replacement

#253 2011-03-21 15:24:59

Re: systemd: Yet Another Init Replacement

#254 2011-03-21 15:47:02

Re: systemd: Yet Another Init Replacement

#255 2011-03-21 16:43:10

Re: systemd: Yet Another Init Replacement

#256 2011-03-21 16:50:52

Re: systemd: Yet Another Init Replacement

#257 2011-03-21 17:34:34

Re: systemd: Yet Another Init Replacement

#258 2011-03-21 22:42:45

Re: systemd: Yet Another Init Replacement

#259 2011-03-22 06:18:46

Re: systemd: Yet Another Init Replacement

#260 2011-03-22 08:54:26

Re: systemd: Yet Another Init Replacement

#261 2011-03-22 09:05:29

Re: systemd: Yet Another Init Replacement

#262 2011-03-22 09:19:45

Re: systemd: Yet Another Init Replacement

#263 2011-03-22 11:55:23

Re: systemd: Yet Another Init Replacement

#264 2011-03-22 12:25:02

Re: systemd: Yet Another Init Replacement

#265 2011-03-22 14:00:56

Re: systemd: Yet Another Init Replacement

#266 2011-03-22 14:06:17

Re: systemd: Yet Another Init Replacement

#267 2011-03-22 15:10:27

Re: systemd: Yet Another Init Replacement

#268 2011-03-22 18:37:32

Re: systemd: Yet Another Init Replacement

#269 2011-03-22 19:45:39

Re: systemd: Yet Another Init Replacement

#270 2011-03-22 20:04:39

Re: systemd: Yet Another Init Replacement

#271 2011-03-22 22:11:18

Re: systemd: Yet Another Init Replacement

#272 2011-03-22 23:01:05

Re: systemd: Yet Another Init Replacement

#273 2011-03-23 19:44:35

Re: systemd: Yet Another Init Replacement

#274 2011-03-23 20:20:22

Re: systemd: Yet Another Init Replacement

#275 2011-03-23 21:51:38

Re: systemd: Yet Another Init Replacement

Board footer