systemd: Yet Another Init Replacement

Army · 2011-04-07 16:20:34

eworm wrote:

install udev-167

That's what my problem was, after installing udev-167 everything's fine here.

falconindy · 2011-04-07 17:17:30

Which really just means that you were hanging on udev-settle.service.

Army · 2011-04-07 17:59:20

@falconindy: I guess you are right

Ok, so now that it works again I want to do things as right as possible. I added all daemons to systemd by executing systemctl enable ***.service, but some services aren't provided that way, e.g. cpufreq. So I was thinking, maybe it's the right thing to add these to the DAEMONS in rc.conf. I think it would be better to write a *.service file and throw it into /etc/systemd/system/multi-user.target.wants but I still have to figure out how these files are being created.

Or do you guys use a completely vanilla systemd without the scripts which kinda convert Arch's init-stuff to systemd? That would be very cool of course, or would it be a waste of time to get this?

fflarex · 2011-04-07 18:50:17

I'm getting /.config/Trolltech.conf (in the root directory) created every boot. I think it might have to do with the timing between KDM starting and /home mounting, but I'm not sure about that.

Zom · 2011-04-07 19:45:09

fflarex wrote:

I'm getting /.config/Trolltech.conf (in the root directory) created every boot. I think it might have to do with the timing between KDM starting and /home mounting, but I'm not sure about that.

Actually, I think KDM does that in sysvinit too.

fflarex · 2011-04-07 20:27:46

Wow, that's obnoxious then.

ngoonee · 2011-04-08 01:06:57

Yes it does, why does it bother you?

yoshi314 · 2011-04-08 07:59:53

it seems that filling /etc/crypttab and not initializing my luks+lvm volumes by initrd helped (root is not encrypted).

not i still have to wait a while on udev stage, but at least i get to the login prompt.

i still don't get lvm volumes discovered and have to rerun vgchange -ay to activate them, though, otherwise mount services referencing lvm volumes get stuck.

Evanlec · 2011-04-09 05:39:11

Hey, I've been using systemd successfully for a short time now, and so far it works great.
Of course I still have the habit of using /etc/rc.d/<daemon> to start/restart daemons but I'm getting used to it.

Question:
I just installed pdnsd (for local dns caching) and I looked around but didn't see any pdnsd.service file anywhere (I have the systemd-arch-units package installed also).

Should I try and write a unit file for it myself, in order to get the more advanced systemd style service?
or should I just wait for this to come along from upstream?

The daemon is fairly simple I think...it just provides local caching nameserver...but how might I go about writing a unit file for it?
Is there a unit file that would be good for 'copying' and then modifying?

Keep up the good work Falconindy , systemd looks like the future (hopefully) of init systems for linux.

hdhoang · 2011-04-09 14:41:48

@Evanlec, I wrote a pdnsd.service here <https://github.com/hdhoang/systemd-arch … sd.service>. Falconindy hasn't pulled it into the official repo yet, so s-a-u(-git) doesn't have it.

falconindy · 2011-04-10 00:31:02

Merged. Time has a way of getting away from me these days.

DIDI2002 · 2011-04-10 21:36:25

systemd doesn't shut my system down, e.g. 'halt', 'systemd shutdown' and 'systemd reboot' only return my to my VTs. On the other hand, 'systemctl isolate shutdown.target' works fine.
I can't really reproduce it, "sudo reboot" works sometimes, but sometimes I have to tap ctrl+alt+del to trigger a reboot.

Any idea what could be wrong?

Last edited by DIDI2002 (2011-04-10 21:50:11)

Army · 2011-04-11 08:47:42

systemd poweroff is what I use, works fine.

simongmzlj · 2011-04-12 08:37:15

DIDI2002 wrote:

systemd doesn't shut my system down, e.g. 'halt', 'systemd shutdown' and 'systemd reboot' only return my to my VTs. On the other hand, 'systemctl isolate shutdown.target' works fine.
I can't really reproduce it, "sudo reboot" works sometimes, but sometimes I have to tap ctrl+alt+del to trigger a reboot.
Any idea what could be wrong?

+1 exact same issue.

Dinosaw · 2011-04-12 20:57:12

For some reason depmod.service is still trying to load even though it nolonger exists and sysinit.target no longer wants it according to the file in /lib/systemd/system.

Its causing my boot to pause for ~180s until the timeout is reached before it can carry on.

Systemadm says it is still wanted by sysinit.target however, could it be using an old config file in a different location that hasn't been updated and is taking precedence over the correct file?

I'm using systemd 22-2 and initscripts v21-1 on i686

falconindy · 2011-04-12 20:59:18

Even though the unit itself is gone, you've got a dangling symlink in /etc/systemd/system. Clean it up.

ChoK · 2011-04-12 22:49:01

I tried systemd today. Unfortunately arch systemd depends on libdbus availability at boot time and I have a separate / and /usr so my kernel panics at boot.
As dbus is not needed by the traditionnal init system and systemd is in community (unsupported), technically it's not a bug but it should be mentionned maybe in the .install file.

ldd /bin/systemd                                                                                                        
        linux-vdso.so.1 =>  (0x00007fff1aaf7000)                                                                                       
        libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f5a67611000)                                                                 
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f5a673f4000)                                                                   
        libudev.so.0 => /lib/libudev.so.0 (0x00007f5a671e7000)                                                                         
        libpam.so.0 => /lib/libpam.so.0 (0x00007f5a66fda000)                                                                           
        libcap.so.2 => /lib/libcap.so.2 (0x00007f5a66dd6000)                                                                           
        librt.so.1 => /lib/librt.so.1 (0x00007f5a66bce000)                                                                             
        libc.so.6 => /lib/libc.so.6 (0x00007f5a6686d000)                                                                               
        /lib/ld-linux-x86-64.so.2 (0x00007f5a67856000)                                                                                 
        libdl.so.2 => /lib/libdl.so.2 (0x00007f5a66669000)                                                                             
        libattr.so.1 => /lib/libattr.so.1 (0x00007f5a66465000)

Relevant info/controversy :
http://www.freedesktop.org/wiki/Softwar … -is-broken
http://lwn.net/Articles/429695/
http://thread.gmane.org/gmane.comp.sysu … devel/1337

Last edited by ChoK (2011-04-12 22:55:42)

falconindy · 2011-04-12 23:20:45

No, that's something that belongs in the wiki. It's been mentioned before on this thread as well.

editorial: I'm in agreement with upstream that /usr on a separate partition is a silly thing. It's become far too ingrained in the Linux userspace to be separated out at this point. Legacy programs do legacy things, which is why you avoid pain and misery with sysvinit. Many other distros silently will not support your configuration.

Last edited by falconindy (2011-04-12 23:23:21)

yoshi314 · 2011-04-13 07:48:50

does anyone else have this weird issue where lvm volume links are in /dev, but mount services for those devices time out ?

mounting by hand works.

litemotiv · 2011-04-13 10:34:06

simongmzlj wrote:

DIDI2002 wrote:
systemd doesn't shut my system down, e.g. 'halt', 'systemd shutdown' and 'systemd reboot' only return my to my VTs. On the other hand, 'systemctl isolate shutdown.target' works fine.
I can't really reproduce it, "sudo reboot" works sometimes, but sometimes I have to tap ctrl+alt+del to trigger a reboot.
Any idea what could be wrong?
+1 exact same issue.

Yes i'm having breakage here too now, poweroff doesn't work anymore and my timezone isn't correctly set (UTC instead).

Edit: this solved itself, must've been a misfire..

Last edited by litemotiv (2011-04-13 15:41:51)

jac · 2011-04-14 10:49:38

Wow, I have to say, thanks a lot for all of your hard work! systemd installed without a hitch, and I see information about the native config files was added to the wiki recently.

My desktop only took around 15 seconds to boot before (grub -> CLI). Now bootchart says it takes 20s, but I can login and do things starting around 4.5s! In fact, if you look at this bootchart, you can see the login process starts around 4.5s into the boot, I then type my password in and do an xinit

Now if only there was a way to speed up my ridiculous BIOS...

crabman · 2011-04-16 12:08:47

it seems like systemd broke my pulseaudio

when i boot with sysvinit and play a file in amarok (using phonon-xine backend) or vlc, i hear the song/movie i am playing and a high pitch noise. In mplayer (which uses alsa directly) everything is fine.

when i boot in systemd sound works as expected.

I have this issue since i installed systemd. Has anyone experienced similar problems?

crabman

ChoK · 2011-04-16 22:10:59

I finally merged my /usr partition and my root partition and gave systemd a go. It feels fast but I can't bootchart it unfortunately, appending init=/sbin/bootchartd bootchart_init=/bin/systemd doesn't work, the default init will be used (is that a bug ?)

Anyway systemd has some problems with the clock : my Timezone is Europe/Paris meaning localtime is UTC+2 due to DST, on the bios I saved the UTC time, UTC is set in rc.conf.
According to the Time article on the Archwiki :
"date" shows the system time, the one displayed on the KDE or Gnome clock for exemple.
"hwclock --show" shows the hardware clock time, as saved by the bios but according to man hwclock, the output will be in local time (i.e. corrected by +2 for me)

When I start the system at UTC 20:00, the date command displays 20:00 while the hwclock displays 22:00 (remember it's corrected by +2)
This means the system thinks the bios time is the local time.
A simple fix is to do "hwclock --hctosys" after booting to correct the system time.

The .service /lib/systemd/system/shutdown.target.wants/hwclock-save.service execute the command hwclock --systohc before each shutdown. The result is if I shutdown at UTC 20:10 (while the date command displays 20:10) . At next reboot the bios time will 18:10 meaning there is a 2 hours cumulative drift at each reboot.

In /lib/systemd/system/hwclock-load.service

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

[Unit]
Description=Apply System Clock UTC Offset
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target udev.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/hwclock --systz
StandardOutput=syslog

# Note the weird semantics of hwclock and the kernel here: the first
# settimeofday() invocation from userspace is special and may be used
# to set the offset from UTC of the system clock. It is independent
# of any specific RTC device. This is mostly a crufty hack to support
# legacy operating systems which insist on storing local time in the
# RTC.

[b]# Note that we do not run --hctosys here, we assume the kernel
# includes a compiled in RTC module which is used to initialize the
# system time as part of kernel setup.[/b]

[Install]
WantedBy=sysinit.target

It seems like the RTC module Lennart is speaking of is not compiled in Arch kernel, so this script should be edited to include --hctosys

edit: By the way the symlinks in /etc/systemd/system point to //lib/..
for exemple //lib/systemd/system/getty@.service //lib/systemd/system/remote-fs.target //lib/systemd/system/hwclock-load.service (correcting the symlinks doesn't change my time problem)

Last edited by ChoK (2011-04-16 23:00:40)

falconindy · 2011-04-16 23:51:32

ChoK wrote:

I finally merged my /usr partition and my root partition and gave systemd a go. It feels fast but I can't bootchart it unfortunately, appending init=/sbin/bootchartd bootchart_init=/bin/systemd doesn't work, the default init will be used (is that a bug ?)

If anything, a bug in bootchart. Use bootchart2, which has its own unit files. As of systemd 23, there also exists systemd-analyze, which is still somewhat primitive but I assume is going to be intended to replace bootchart.

ChoK wrote:

Anyway systemd has some problems with the clock : my Timezone is Europe/Paris meaning localtime is UTC+2 due to DST, on the bios I saved the UTC time, UTC is set in rc.conf.
According to the Time article on the Archwiki :
"date" shows the system time, the one displayed on the KDE or Gnome clock for exemple.
"hwclock --show" shows the hardware clock time, as saved by the bios but according to man hwclock, the output will be in local time (i.e. corrected by +2 for me)
When I start the system at UTC 20:00, the date command displays 20:00 while the hwclock displays 22:00 (remember it's corrected by +2)
This means the system thinks the bios time is the local time.
A simple fix is to do "hwclock --hctosys" after booting to correct the system time.
The .service /lib/systemd/system/shutdown.target.wants/hwclock-save.service execute the command hwclock --systohc before each shutdown. The result is if I shutdown at UTC 20:10 (while the date command displays 20:10) . At next reboot the bios time will 18:10 meaning there is a 2 hours cumulative drift at each reboot.
In /lib/systemd/system/hwclock-load.service
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

[Unit]
Description=Apply System Clock UTC Offset
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target udev.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/hwclock --systz
StandardOutput=syslog

# Note the weird semantics of hwclock and the kernel here: the first
# settimeofday() invocation from userspace is special and may be used
# to set the offset from UTC of the system clock. It is independent
# of any specific RTC device. This is mostly a crufty hack to support
# legacy operating systems which insist on storing local time in the
# RTC.

[b]# Note that we do not run --hctosys here, we assume the kernel
# includes a compiled in RTC module which is used to initialize the
# system time as part of kernel setup.[/b]

[Install]
WantedBy=sysinit.target
It seems like the RTC module Lennart is speaking of is not compiled in Arch kernel, so this script should be edited to include --hctosys

No, there was a feature request which was implemented several months ago. Have you enabled hwclock-load.service via systemctl?

ChoK wrote:

edit: By the way the symlinks in /etc/systemd/system point to //lib/..
for exemple //lib/systemd/system/getty@.service //lib/systemd/system/remote-fs.target //lib/systemd/system/hwclock-load.service (correcting the symlinks doesn't change my time problem)

I've noticed this and, as far as I can tell, that's an upstream packaging issue. It doesn't break anything so I haven't complained.

Last edited by falconindy (2011-04-16 23:54:38)

ChoK · 2011-04-17 09:47:51

Actually disabling hwclock-load.service works for me. What is curious is that once booted, running /sbin/hwclock --systz doesn't change my clock.

Another problem is with the rc-local.service . I use /etc/rc.local to mount some filesystem and block devices late, because the partition/mountpoint can be late and they are not essential to boot : for exemple I have a /var/local/abs that needs /var before being mounted.
The problem is they are not mounted after booting, I suppose it's because of the aggressive parallelization, rc.local ends up being run before some partition are even mounted.
I tried adding verbose to the grub line to see where the service fails, I saw some lines about rc-local.service but I can't find it in /var/log/* though. Anyway I'll try mounting them via fstab, hopefully systemd is smart about mount ordering.

Arch Linux

#376 2011-04-07 16:20:34

Re: systemd: Yet Another Init Replacement

#377 2011-04-07 17:17:30

Re: systemd: Yet Another Init Replacement

#378 2011-04-07 17:59:20

Re: systemd: Yet Another Init Replacement

#379 2011-04-07 18:50:17

Re: systemd: Yet Another Init Replacement

#380 2011-04-07 19:45:09

Re: systemd: Yet Another Init Replacement

#381 2011-04-07 20:27:46

Re: systemd: Yet Another Init Replacement

#382 2011-04-08 01:06:57

Re: systemd: Yet Another Init Replacement

#383 2011-04-08 07:59:53

Re: systemd: Yet Another Init Replacement

#384 2011-04-09 05:39:11

Re: systemd: Yet Another Init Replacement

#385 2011-04-09 14:41:48

Re: systemd: Yet Another Init Replacement

#386 2011-04-10 00:31:02

Re: systemd: Yet Another Init Replacement

#387 2011-04-10 21:36:25

Re: systemd: Yet Another Init Replacement

#388 2011-04-11 08:47:42

Re: systemd: Yet Another Init Replacement

#389 2011-04-12 08:37:15

Re: systemd: Yet Another Init Replacement

#390 2011-04-12 20:57:12

Re: systemd: Yet Another Init Replacement

#391 2011-04-12 20:59:18

Re: systemd: Yet Another Init Replacement

#392 2011-04-12 22:49:01

Re: systemd: Yet Another Init Replacement

#393 2011-04-12 23:20:45

Re: systemd: Yet Another Init Replacement

#394 2011-04-13 07:48:50

Re: systemd: Yet Another Init Replacement

#395 2011-04-13 10:34:06

Re: systemd: Yet Another Init Replacement

#396 2011-04-14 10:49:38

Re: systemd: Yet Another Init Replacement

#397 2011-04-16 12:08:47

Re: systemd: Yet Another Init Replacement

#398 2011-04-16 22:10:59

Re: systemd: Yet Another Init Replacement

#399 2011-04-16 23:51:32

Re: systemd: Yet Another Init Replacement

#400 2011-04-17 09:47:51

Re: systemd: Yet Another Init Replacement

Board footer