systemd: Yet Another Init Replacement

falconindy · 2011-03-20 01:28:49

In case anyone wants to give it a run, I tested this on a VM and it works...

#!/bin/bash

modprobeconf=/etc/modprobe.d/rc.conf
declare -a blacklist

[[ $1 ]] || exit 0

# try to rewrite $modprobeconf if rc.conf is newer. root may 
# or may not be mounted read/write at this point.
if [[ /etc/rc.conf -nt $modprobeconf && -w $modprobeconf ]]; then
  . /etc/rc.conf

  for mod in "${MODULES[@]}"; do
    [[ ${mod:0:1} = '!' ]] || continue
    blacklist+=("${mod:1}")
  done

  # update blacklist
  printf '# Autogenerated by load-modules, do not edit\n' > "$modprobeconf"
  if (( ${#blacklist[*]} > 0 )); then
    printf 'install %s /bin/false\n' "${blacklist[@]//-/_}" >> "$modprobeconf"
  fi
fi

# get the real name of the module
resolved=$(modprobe -ni --show-depends $1 2>/dev/null | sed -n '$s#.*/\(.*)\.ko.*#\1#')

exec modprobe ${resolved:-$1}

The only kicker is that you need to add the if/then block to /etc/rc.shutdown as well, to try and avoid a situation where we've got an inaccurate blacklist on bootup before root is writeable. Comments welcome.

Last edited by falconindy (2011-03-20 01:31:53)

benneque · 2011-03-20 11:57:59

Does anybody know sth. about systemd and samba ?
For cups there's a service file, but not for samba. Is it hardcoded into systemd or is there simply no unit-file?
I can't test it atm, 'cause of only one PC, but I want to have samba running just for the case!

EDIT: Just another information regarding cups.service!
I think I have it running (half the way): just do: systemctl enable cups.socket
After reboot "systemctl | grep -i cups" shows "socket" and "service", but no path. Now entering the browser and typing localhost:631 works.
I don't know if cups starts at boot or when I open the webinterface ?! (I have no syslog)

EDIT2: I recognized something funny about boot times:
My pc has heating problems. Means: Sometimes it simply runs at 800MHz instead of 2000 (dual-core). (I can see it at boot if the cpu is throtteled). Now my experience:
2000MHz boot time: 6-6,5 seconds (kernel) + 6,8seconds (userspace)
800MHz boot time: 7 seconds (kernel) + 7,5 seconds (userspace)
As you can see: A faster CPU can't get more out of boot speed. Even 800MHz are nearly fast enough for a 5400RPM hard-drive!
I need to get a SSD with sandforce 2200 and 500MB/sec

Last edited by benneque (2011-03-20 12:24:34)

falconindy · 2011-03-20 13:18:48

benneque wrote:

Does anybody know sth. about systemd and samba ?
For cups there's a service file, but not for samba. Is it hardcoded into systemd or is there simply no unit-file?
I can't test it atm, 'cause of only one PC, but I want to have samba running just for the case!

You're the first person (that I can recall) to ask about a samba unit file.

benneque wrote:

EDIT: Just another information regarding cups.service!
I think I have it running (half the way): just do: systemctl enable cups.socket
After reboot "systemctl | grep -i cups" shows "socket" and "service", but no path. Now entering the browser and typing localhost:631 works.
I don't know if cups starts at boot or when I open the webinterface ?! (I have no syslog)

oh... i assumed you were already doing this. I had heard some strange reports about cups not playing nicely with starting up via the web interface. maybe they were all bogus -- i never did try it myself.

EDIT2: I recognized something funny about boot times:
My pc has heating problems. Means: Sometimes it simply runs at 800MHz instead of 2000 (dual-core). (I can see it at boot if the cpu is throtteled). Now my experience:
2000MHz boot time: 6-6,5 seconds (kernel) + 6,8seconds (userspace)
800MHz boot time: 7 seconds (kernel) + 7,5 seconds (userspace)
As you can see: A faster CPU can't get more out of boot speed. Even 800MHz are nearly fast enough for a 5400RPM hard-drive!
I need to get a SSD with sandforce 2200 and 500MB/sec

systemd[1]: Startup finished in 5s 366ms 717us (kernel) + 1s 461ms 391us (userspace) = 6s 828ms 108us.

That's a sandforce drive. I don't have the motivation to work on getting the kernel time down given how infrequently I reboot. I suppose a laptop user might be more driven.

Last edited by falconindy (2011-03-20 13:19:54)

benneque · 2011-03-20 15:51:55

Yeah, google won't tell me much concerning systemd and samba, too

Kernel time won't get down with standard Arch kernel I think. With Gentoo and my self configured + optimized + compiled zen-kernel I had about 3-4 seconds. Maybe with SSD you could get it down to 1-2 seconds, but I don't know, because the kernel and initrd are mainly 2 files that have to be read from HDD... All those startup services are hunders or thousands of files and so the seek-time of HDD is the limiting speed-factor. Maybe you need a fast SSD an a CPU @ 4GHz to get that speed.

falconindy · 2011-03-20 16:09:43

systemd and friends (initscripts-systemd and systemd-arch-units) are now in [community]!

ngoonee · 2011-03-20 16:28:44

falconindy wrote:

systemd and friends (initscripts-systemd and systemd-arch-units) are now in [community]!

That is terrific news!

benneque · 2011-03-20 16:28:57

yaaaay! Are you still maintaining it (I don't know how this is organized in arch) ?

EDIT: what's the main (means: most up to date) arch mirror ?

Last edited by benneque (2011-03-20 16:34:11)

skunktrader · 2011-03-20 16:38:41

benneque wrote:

EDIT: what's the main (means: most up to date) arch mirror ?

http://www.archlinux.org/mirrors/status/

litemotiv · 2011-03-20 16:54:47

falconindy wrote:

systemd and friends (initscripts-systemd and systemd-arch-units) are now in [community]!

Great stuff, thanks for your work on this.

ianux · 2011-03-20 18:28:19

Hello archers,
after installing (and even reinstalling) systemd-arch-units from community, I get this error after the post-install notice:

error: command failed to execute correctly

pacman.log says nothing and executing manually the .INSTALL file from the package doesn't show this error.
Where does this error come from?

falconindy · 2011-03-20 19:14:03

The error comes from the install scriptlet. I should push a new version... in the mean time, you can run: 'systemctl daemon-reload' if (and only if) systemd is already running. If systemd isn't running, then its harmless. Reboot and everything will be fine.

ianux · 2011-03-20 19:26:29

thanks for your answer, I was thinking it was something like that. I didn't have reboot yet, so didn't test systemd for the moment...

benneque · 2011-03-20 19:35:38

I've got the update from community to version 20-3.
First: Nice to see plymouth service files
Second: plymouth service files are incorrect I think... plymouth gets never quit. Normally plymouth-quit.service must be activated for plymouth to exit. Else it's impossible to use console AND you won't get plymouth at reboot and shutdown, 'cause theres still the old plymouth picture from boot, but this time without any animation.

Hope you could fix this as well

Here's whats need to be done:
plymouth-reboot must be in reboot.target
plymouth-poweroff in poweroff.target
plymouth-halt in halt.target
plymouth-quit is quite a bit problematic. For a really smooth transaction it would be fine if it gets called after KDM got loaded (or gdm, whatever you use). But if you don't have any graphical login it must be called just when getty gets activated.

EDIT: It's getting even worse! If plymouth doesn't get killed it eats your CPU. I have now plymouthd eating 35% CPU!!!

Last edited by benneque (2011-03-20 19:45:32)

falconindy · 2011-03-20 19:49:33

benneque wrote:

I've got the update from community to version 20-3.
First: Nice to see plymouth service files
Second: plymouth service files are incorrect I think... plymouth gets never quit. Normally plymouth-quit.service must be activated for plymouth to exit. Else it's impossible to use console AND you won't get plymouth at reboot and shutdown, 'cause theres still the old plymouth picture from boot, but this time without any animation.
Hope you could fix this as well
Here's whats need to be done:
plymouth-reboot must be in reboot.target
plymouth-poweroff in poweroff.target
plymouth-halt in halt.target
plymouth-quit is quite a bit problematic. For a really smooth transaction it would be fine if it gets called after KDM got loaded (or gdm, whatever you use). But if you don't have any graphical login it must be called just when getty gets activated.

Hmmm... interesting. These units all seem to have the necessary dependencies and ordering to be called the way you say, so it must be linkage somewhere else... could you try creating a symlink called 'prefdm.service' to your DM service file?

benneque · 2011-03-20 19:53:13

you mean "ln -s /lib/systemd/system/kdm.service /lib/systemd/system/prefdm.service " ? I'll try it and will report back in a few minutes (5-10).
And another short Q: Have I to run systemctl daemons-reload everytime I change something by hand in the config ?

EDIT: perfdm.service doesn't exist in this place. I'll create it

EDIT2: I've created that symlink. and what now?
I did "pacman -S systemd" but its still all as said before. plymouth-*.service are missing the Install section...
I'm just 3 days on Arch, I really don't know pacman and yaourt. Have I to use another option to really reinstall a package? Or should I remove and reinstall?

Another information: I have deleted initscripts-systemd yesterday 'cause I think I don't need it anymore. Or might this be the problem?

EDIT3: did a reboot and nothing changed.

Last edited by benneque (2011-03-20 20:04:04)

falconindy · 2011-03-20 20:16:54

benneque wrote:

you mean "ln -s /lib/systemd/system/kdm.service /lib/systemd/system/prefdm.service " ? I'll try it and will report back in a few minutes (5-10).
And another short Q: Have I to run systemctl daemons-reload everytime I change something by hand in the config ?
EDIT: perfdm.service doesn't exist in this place. I'll create it

Yes, you want to create it. I'd suggest creating it in /etc/systemd/system instead of /lib...

So, running daemon-reload will tell systemd to rescan its directories and re-read all its service files. If you make a change to a service, target, mount, whatever file, you should run this to pick up those changes.

benneque wrote:

EDIT2: I've created that symlink. and what now?
I did "pacman -S systemd" but its still all as said before. plymouth-*.service are missing the Install section...
I'm just 3 days on Arch, I really don't know pacman and yaourt. Have I to use another option to really reinstall a package? Or should I remove and reinstall?

the [Install] section is optional to allow users to enable/disable. It shouldn't be necessary here because of the After/Wants/Before ordering directives.

benneque wrote:

Another information: I have deleted initscripts-systemd yesterday 'cause I think I don't need it anymore. Or might this be the problem?

You definitely want to keep initscripts-systemd.

benneque wrote:

EDIT3: did a reboot and nothing changed.

fooey.

Last edited by falconindy (2011-03-20 20:17:33)

benneque · 2011-03-20 20:28:34

sorry. I wrote "perfdm" instead of "prefdm" .. have to recheck it in a few minutes

EDIT: But it's right that I shouldn't "systemctl enable prefdm.service" or should I ?

Last edited by benneque (2011-03-20 20:31:18)

falconindy · 2011-03-20 20:32:35

No, you should not need to.

ianux · 2011-03-20 21:15:43

I juste rebooted and I can say that it's working and it's FRAKKIN' fast! I get a login screen less than 2 sec after fsck! Good job guys!

benneque · 2011-03-20 21:25:23

Still plymouth problem:

I updated to community/systemd-arch-units 20110320-2 and rebooted.

here's prefdm:
dir /lib/systemd/system/prefdm.service -l
lrwxrwxrwx 1 root root 11 20. Mär 20:54 /lib/systemd/system/prefdm.service -> kdm.service

prefdm.service is not enabled as you said, but kdm.service is!

plymouth doesn't get killed after kdm started up.

EDIT: has anyone else recognized that systemd's readahead slows booting down? For me it's from 13-14 seconds (without) to 17-18 seconds (with readahead) and I've rebooted at least 20-30 times

Last edited by benneque (2011-03-20 21:52:39)

falconindy · 2011-03-20 22:24:26

Hmm, I'll have to pick away at this. I've got a VM setup that boots directly to GDM, but plymouth doesn't want to start for me.. 'unexpectedly disconnected from boot status daemon' (right when the initcpio switches root perhaps?) I'm probably missing out on some magic that fedora abuse /dev for.

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

Are you using Arch in your VM? I had the same message. Give plymouth-git a try!

falconindy · 2011-03-20 22:49:18

Of course I'm using Arch in my VM! Actually, plymouth gave me a different error about a failed assertion. plymouth-git is the one who gives me the disconnect error. I've modded the crap out of my mkinitcpio and initscripts on that VM (wheeee playground) so I'll see what happens if I revert those to "sane" versions.

edit: Wheeee, got it working using uvesafb. My solar theme with giant arch linux logo is so fast. I see it for all of about 2 seconds. When I go to shut down, plymouth doesn't come back. I just get kicked to a console for a split second and I'm done.

Last edited by falconindy (2011-03-21 00:39:00)

benneque · 2011-03-21 08:15:25

Yeah, didn't you use a high resolution?
I use grub2 with high-res ans payload=keep. So I have high-res at boot time, but after 2 seconds I get flickering 'cause kernel complains that nouveaufb wants to get control. and then I still have high-res with nouveau and kms with modesettings. Then comes plymouth.

I had asked myself whatfor one needs a splashscreen if the systemd takes 1-2 seconds to boot. It maybe more annoying than fancy

So how got you plymouth running? Have you modded plymouth-quit.service?

falconindy · 2011-03-21 10:18:27

well, turns out that plymouth needs a proper frame buffer device so uvesafb was the only way to get it working on a VM (vga modeline didn't seem to be sufficient). I'm using unmodified installs of the latest systemd-git, initscripts-systemd-git, and systemd-arch-units-git. plymouth-git needed some massaging. I also wrote my own xdm.service but everything here works just the same with gdm.

I'd much rather see boot messages (as much as systemd mangles the crap out of them), but that's pretty nifty. I guess there's supposed to be a similar splash on shutdown, but I never see it. I hit shutdown from Gnome or type init 6/0 and it just goes, no problem.

Arch Linux

#226 2011-03-20 01:28:49

Re: systemd: Yet Another Init Replacement

#227 2011-03-20 11:57:59

Re: systemd: Yet Another Init Replacement

#228 2011-03-20 13:18:48

Re: systemd: Yet Another Init Replacement

#229 2011-03-20 15:51:55

Re: systemd: Yet Another Init Replacement

#230 2011-03-20 16:09:43

Re: systemd: Yet Another Init Replacement

#231 2011-03-20 16:28:44

Re: systemd: Yet Another Init Replacement

#232 2011-03-20 16:28:57

Re: systemd: Yet Another Init Replacement

#233 2011-03-20 16:38:41

Re: systemd: Yet Another Init Replacement

#234 2011-03-20 16:54:47

Re: systemd: Yet Another Init Replacement

#235 2011-03-20 18:28:19

Re: systemd: Yet Another Init Replacement

#236 2011-03-20 19:14:03

Re: systemd: Yet Another Init Replacement

#237 2011-03-20 19:26:29

Re: systemd: Yet Another Init Replacement

#238 2011-03-20 19:35:38

Re: systemd: Yet Another Init Replacement

#239 2011-03-20 19:49:33

Re: systemd: Yet Another Init Replacement

#240 2011-03-20 19:53:13

Re: systemd: Yet Another Init Replacement

#241 2011-03-20 20:16:54

Re: systemd: Yet Another Init Replacement

#242 2011-03-20 20:28:34

Re: systemd: Yet Another Init Replacement

#243 2011-03-20 20:32:35

Re: systemd: Yet Another Init Replacement

#244 2011-03-20 21:15:43

Re: systemd: Yet Another Init Replacement

#245 2011-03-20 21:25:23

Re: systemd: Yet Another Init Replacement

#246 2011-03-20 22:24:26

Re: systemd: Yet Another Init Replacement

#247 2011-03-20 22:39:47

Re: systemd: Yet Another Init Replacement

#248 2011-03-20 22:49:18

Re: systemd: Yet Another Init Replacement

#249 2011-03-21 08:15:25

Re: systemd: Yet Another Init Replacement

#250 2011-03-21 10:18:27

Re: systemd: Yet Another Init Replacement

Board footer