systemd: Yet Another Init Replacement

Oni · 2011-03-10 19:51:31

I had try with verbose option, it's hang up on shutdown/reboot when/after stopping dhcpcd and I wait 5 minutes and nothing, it still hang up...

Oni · 2011-03-11 09:18:41

More Exactly, I have "Starting save Random Seed" then dhcpcd "kill" and then lock/hang up, I will test with debug to have more informations.

hdhoang · 2011-03-12 13:47:52

In http://lists.freedesktop.org/archives/s … 01570.html upstream says rsyslog.service should not conflict with systemd-kmsg-syslogd.service.

falconindy · 2011-03-12 16:13:37

hdhoang wrote:

In http://lists.freedesktop.org/archives/s … 01570.html upstream says rsyslog.service should not conflict with systemd-kmsg-syslogd.service.

Correct. Doing so actually causes the boot process to hang, which is why I removed it. Stopping the internal kmsg logger has some other bizzare effects noted in that thread, so I've opted to do neither.

Oni · 2011-03-12 19:14:36

Oni wrote:

More Exactly, I have "Starting save Random Seed" then dhcpcd "kill" and then lock/hang up, I will test with debug to have more informations.

I test with debug output (systemd.log_level=debug) and it's hang up on systemd-update-utmp-shutdown if I was read correctly read debug output.

loonyphoenix · 2011-03-12 21:56:09

I've got a wierd problem. When I start with systemd, I've got an empty tray icon which is called org.kde.StatusNotifierItem-1702-1/StatusNotifierItem, and system notification don't work. (I'm using KDE.)

Also, #systemctl enable kdm.service doesn't make it start at startup. However, making graphical.target the default does. It's weird.

Also, I have these services which have the error status on loading:

auditd.service error inactive dead auditd.service
dbus-org....Avahi.service error inactive dead dbus-org.freedesktop.Avahi.service
plymouth...t-wait.service error inactive dead plymouth-quit-wait.service

I don't seem to have any of the .service files in /lib/systemd/system

hdhoang · 2011-03-13 05:26:53

The Conflicts line is still in https://github.com/falconindy/systemd-a … og.service

falconindy · 2011-03-13 20:06:58

You are correct. I don't use rsyslog, so it slipped by me. Thanks!

Viper_Scull · 2011-03-14 23:12:57

Hi.
I was testing now Systemd on my laptop, and i've run into one issue. I wasnt using any display manager, i started directly X from inittab with my user.
Since Systemd doesnt read inittab, is there a way to achieve this behavior?

Coz eventhough target is graphical target, if no display manager service is enabled it prompts to a shell to login.

Maybe another service which runs startx directly??

This was the line i was using in inittab: x:5:once:/bin/su - -- my_user -l -c '/usr/bin/startx </dev/null'

damjan · 2011-03-15 10:06:45

Does anyone use wicd with systemd? Does the daemon start automatically when the client is run? Because it doesn't for me. I had to enable it, and now it's started on boot.

Also, what about an acpid.service anyone has it?

Peterix · 2011-03-18 17:59:09

I'm having some problems with cupsd. For some reason it refuses to die when I want to reboot or shutdown. I looked at the logs and it is sucessfully killed, but restarts immediately.
'sysctl stop cupsd.service' does nothing.
'sysctl disable cupsd.service' works only after a reboot, and even then I had to send a SIGKILL to cupsd just to make it die.

The systemd unit script things don't leave me with enough clues to debug this

Last edited by Peterix (2011-03-18 17:59:56)

Zom · 2011-03-18 22:31:39

damjan wrote:

Does anyone use wicd with systemd? Does the daemon start automatically when the client is run? Because it doesn't for me. I had to enable it, and now it's started on boot.

You need to enable it, yes.

damjan wrote:

Also, what about an acpid.service anyone has it?

I hacked together a quick one based off of dcron.service:
[Unit]
Description=ACPI Daemon
Wants=syslog.target

[Service]
Type=forking
PIDFile=/var/run/acpid.pid
ExecStart=/etc/rc.d/acpid start
ExecStop=/etc/rc.d/acpid stop
Restart=always

[Install]
WantedBy=multi-user.target

You could probably tweak the ExecStart and ExecStop to just run acpid manually with the values from /etc/conf.d/, but I just needed a quick fix.

falconindy · 2011-03-18 23:52:43

acpid now has a unit in systemd-arch-units:

https://github.com/falconindy/systemd-a … id.service

Zom · 2011-03-19 10:15:04

Oh, neat!

Also, I ran into an issue today. I have my pacman database caged, and it doesn't mount on boot. What's the best way for me to fix this?

falconindy · 2011-03-19 13:57:32

don't cage pacman. seriously. That hack is more or less obsolete with pacman 3.5 anyways.

Last edited by falconindy (2011-03-19 14:02:21)

benneque · 2011-03-19 14:22:01

Hi I'm new to Arch. I've used 6 years Gentoo, now a half year with systemd...

Now with arch I have installed systemd, too. And there are 2 small issues:

1. as mentioned before: cups is blocking port 631. Is there still the only fix to delete cups.socket ?

2. I try to delete /etc/rc.conf (I know what I'm doing!). I want to get an original systemd setup!
I've made /etc/mtab a symlink, I've created /etc/hostname, /etc/vconsole.conf, etc...
now there are only a few lines left in /etc/rc.conf:
TIMEZONE="Europe/Berlin"
MOD_AUTOLOAD="yes"
MODULES=( acpi-cpufreq cpufreq_ondemand )

the questions are:
- where reads systemd the timezone information?
- if I delete MOD_AUTOLOAD and MODULES my system boots but there's no mouse and keyboard in kdm. I think the USB-driver isn't loaded... I thought udev would load all modules needed, but it doesn't. How can I get it right?

Hope someone can help me. Thanks!

falconindy · 2011-03-19 14:31:33

benneque wrote:

Hi I'm new to Arch. I've used 6 years Gentoo, now a half year with systemd...
Now with arch I have installed systemd, too. And there are 2 small issues:
1. as mentioned before: cups is blocking port 631. Is there still the only fix to delete cups.socket ?

Yes, cups is broken. It's an upstream issue. I guess I should consider revamping the service/socket to not use socket activation.

benneque wrote:

2. I try to delete /etc/rc.conf (I know what I'm doing!). I want to get an original systemd setup!
I've made /etc/mtab a symlink, I've created /etc/hostname, /etc/vconsole.conf, etc...
now there are only a few lines left in /etc/rc.conf:
TIMEZONE="Europe/Berlin"
MOD_AUTOLOAD="yes"
MODULES=( acpi-cpufreq cpufreq_ondemand )
the questions are:
- where reads systemd the timezone information?
- if I delete MOD_AUTOLOAD and MODULES my system boots but there's no mouse and keyboard in kdm. I think the USB-driver isn't loaded... I thought udev would load all modules needed, but it doesn't. How can I get it right?
Hope someone can help me. Thanks!

The work Tom and I have done on systemd leaves /etc/rc.conf in the picture to ease integration with Arch. This is backed by upstream patchwork we submitted very early on. If you want to go the route of removing rc.conf, I suggest you recompile systemd and change the --with-distro flag (there'll be some others you'll need to set in exchange) to avoid pulling in the arch specific features.

Also note that literally deleting rc.conf will cause problems for things like /lib/udev/load-modules.sh and any non-native services that still use /etc/rc.d scripts for startup. The best you can do is leave it blank or symlink to /dev/null.

benneque · 2011-03-19 15:06:09

I understand things with cups.. I'll wait

Now my rc.conf is just:
TIMEZONE="Europe/Berlin"
MOD_AUTOLOAD="yes"

I recognized that it automatically loads modules from /etc/modules-load.d/ (that's because of systemd-modules-load.service)

Now to udev: Can I somehow get the "normal" udev behaviour, so it automatically loads all modules it thinks is right?

EDIT: I found the solution! (thanks to Arch Wiki -> speed up udev)
Udev rules ALWAYS use /lib/udev/load-modules.sh instead of simply use modprobe. And load-modules.sh checks if there's module autoloading activated in /etc/rc.conf. So for me (!!!) the best solution was: mv /lib/udev/load-modules.sh /lib/udev/load-modules.sh.old && ln -s /sbin/modprobe /lib/udev/load-modules.sh

Last edited by benneque (2011-03-19 16:12:00)

falconindy · 2011-03-19 16:11:02

You'll need to rip out all references to /lib/udev/load-modules.sh in the rules files in order to restore that behavior. It's a noble goal. I hate that script.

benneque · 2011-03-19 16:15:01

I edited my post 2 seconds before you

I simply made a symlink. Sure, another solution would be replace all references to /lib/udev/load-modules.sh.
Here's an easy solution for that: https://wiki.archlinux.org/index.php/Sp … v#Option_2

But I don't think its good: when there's an update to udev you have to replace it again (or not!?)
Maybe it's the same with the symlink. Can I make it somehow write-protected?

EDIT: in my post before I first wanted to call that script f*cked up, ugly and obsolete. But I thought I'd then be hated by all Archers

Last edited by benneque (2011-03-19 16:16:28)

falconindy · 2011-03-19 17:47:52

Sure, you can symlink it to /sbin/modprobe and then add that path to NoUpgrade in pacman's config. It'll be left alone on upgrading udev. Note that we also use this same script (a separate copy) on the initcpio.

I wouldn't go as far as to call it obsolete. It's a clean way of supporting module loading options in our "single file" system config and still takes effect immediately. We abstract this for systemd but the service is only run at shutdown.

Huh, so... brainstorm. What if we combine these two ideas to replace load-modules.sh with something sane? Untested...

#!/bin/bash

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

[[ $1 ]] || exit 0

if [[ /etc/rc.conf -nt $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' > "$modprobeconf"
  printf 'install %s /bin/false\n' "${blacklist[@]}" >> "$modprobeconf"
fi

exec /sbin/modprobe --use-blacklist "$1"

Blacklisting via the kernel command line could be done in the initcpio and rc.sysinit in a very similar fashion. Truncate the file, and then if disablemodules= is found on the kernel cmdline, generate a similar file.

benneque · 2011-03-19 18:08:55

Nice script

I thought udev uses the blacklists in /etc/modprobe.d/ ? I never got deep into it, 'cause I never needed blacklisting.

Now my systemd experience goes further: plymouth!
After a few hours of testing I have now plymouth up and running with systemd

There are a few remaining issues:
1. # systemctl --all | grep plymouth
plymouth...t-wait.service error inactive dead plymouth-quit-wait.servi
As far as I can see there's no servicefile in /lib/systemd/system/ ... where is it?

2. At the beginning I had plymouth shutdown screen (but no boot splash) using plymouth 0.8.3. Now I have no shutdown splash (but boot splash) using plymouth-git Maybe it's got something to do with "issue 1." ?

not systemd related:
3. I have to set MODULES="nouveau" in mkinitcpio.conf! else the high resoution is set after plymouth starts (system hangs forever) or when using grub2 with keep payload = true, then it switches framebuffers while plymouth is running. that's deadly, too. -> system hangs!
That's not a real problem since it runs using the right options. Maybe I could blacklist nouveaufb 'cause I use my terminal outside X once in 2 weeks

Zom · 2011-03-19 18:22:54

falconindy wrote:

don't cage pacman. seriously. That hack is more or less obsolete with pacman 3.5 anyways.

Yeah, I uncaged it right after I posted. I had honestly forgotten that I did it in the first place, I was just mostly surprised when suddenly the db wasn't accurate.

falconindy · 2011-03-19 18:27:49

So, here's the problem with blacklist v. install. Blacklist will blacklist all aliases that a module goes by, but it fails to block dependencies. install, on the other hand, will force dependencies to run /bin/false, erroring out and aborting the insertion of the initially specified parameter. My above script needs a few tweaks, but it should work nicely in place of load-modules.sh

WRT your other questions...
1) plymouth files are packed with systemd but for some reason not installed. I don't care enough to investigate. You could just add some install lines to the PKGBUILD to get around this.
2) Very likely.
3) Sounds like an upstream bug =P

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

benneque · 2011-03-19 19:08:41

Woohoo!

I have plymouth with systemd fully running!

I just took the systemd-20 tar-file and extracted the plymouth-* units, copied them to /lib/systemd/system/ and inserted the [Install] sections to plymouth-quit reboot and halt. Now I have splash at shutdown and reboot!

At boot there are a few messages from initrd (loading udev etc.) that still make the system feel a bit more ugly than it really is

Arch Linux

#201 2011-03-10 19:51:31

Re: systemd: Yet Another Init Replacement

#202 2011-03-11 09:18:41

Re: systemd: Yet Another Init Replacement

#203 2011-03-12 13:47:52

Re: systemd: Yet Another Init Replacement

#204 2011-03-12 16:13:37

Re: systemd: Yet Another Init Replacement

#205 2011-03-12 19:14:36

Re: systemd: Yet Another Init Replacement

#206 2011-03-12 21:56:09

Re: systemd: Yet Another Init Replacement

#207 2011-03-13 05:26:53

Re: systemd: Yet Another Init Replacement

#208 2011-03-13 20:06:58

Re: systemd: Yet Another Init Replacement

#209 2011-03-14 23:12:57

Re: systemd: Yet Another Init Replacement

#210 2011-03-15 10:06:45

Re: systemd: Yet Another Init Replacement

#211 2011-03-18 17:59:09

Re: systemd: Yet Another Init Replacement

#212 2011-03-18 22:31:39

Re: systemd: Yet Another Init Replacement

#213 2011-03-18 23:52:43

Re: systemd: Yet Another Init Replacement

#214 2011-03-19 10:15:04

Re: systemd: Yet Another Init Replacement

#215 2011-03-19 13:57:32

Re: systemd: Yet Another Init Replacement

#216 2011-03-19 14:22:01

Re: systemd: Yet Another Init Replacement

#217 2011-03-19 14:31:33

Re: systemd: Yet Another Init Replacement

#218 2011-03-19 15:06:09

Re: systemd: Yet Another Init Replacement

#219 2011-03-19 16:11:02

Re: systemd: Yet Another Init Replacement

#220 2011-03-19 16:15:01

Re: systemd: Yet Another Init Replacement

#221 2011-03-19 17:47:52

Re: systemd: Yet Another Init Replacement

#222 2011-03-19 18:08:55

Re: systemd: Yet Another Init Replacement

#223 2011-03-19 18:22:54

Re: systemd: Yet Another Init Replacement

#224 2011-03-19 18:27:49

Re: systemd: Yet Another Init Replacement

#225 2011-03-19 19:08:41

Re: systemd: Yet Another Init Replacement

Board footer