systemd: Yet Another Init Replacement

tomegun · 2011-07-18 23:10:01

@Viper_Scull: no need for that. All you have to do is to disable syslog-ng.service (or rsyslog.service if that's what you use).

On next reboot all your syslog messages can be seen by using "dmesg". Nothing get's written to /var/log (except for stuff that circumvents syslog of course).

ron9 · 2011-07-19 16:17:11

tomegun wrote:

@Viper_Scull: no need for that. All you have to do is to disable syslog-ng.service (or rsyslog.service if that's what you use).

What about syslog.socket? It still loaded after disabling syslog-ng.service. Is it needed for something else?

tomegun · 2011-07-19 16:35:56

ron9 wrote:

What about syslog.socket? It still loaded after disabling syslog-ng.service. Is it needed for something else?

syslog.socket creates /dev/log and starts systemd-kmsg-syslogd.service on demand. This is a minimal syslog implementation which just forwards all messages from /dev/log to kmesg. This is what allows you to see all your syslog messages using dmesg.

Under normal circumstances (when syslog-ng/rsyslog are enabled) the role of systemd-kmsg-syslogd.service is to catch the messages that arrive before the real syslog daemon is available.

ron9 · 2011-07-19 17:37:24

[ronny@olebrumm ~]$ systemd-analyze blame
2813ms udev-trigger.service
2510ms var-lock.mount
2487ms media.mount
2463ms var-run.mount
1509ms systemd-vconsole-setup.service
429ms home-ronny-mydata.mount
399ms wireless.service
399ms systemd-sysctl.service
364ms systemd-readahead-collect.service
340ms systemd-readahead-replay.service
333ms wpa_supplicant.service
320ms udev.service
239ms systemd-tmpfiles-setup.service
213ms systemd-logind.service
176ms dbus.service
166ms systemd-remount-api-vfs.service
147ms home-ronny-homeserver.mount
103ms dcron.service
69ms systemd-user-sessions.service
23ms remount-rootfs.service
13ms boot.mount

Startup finished in 3458ms (kernel) + 6175ms (userspace) = 9633ms

After some testing, the result is that there is very little or no time to spare to disable syslog-ng on my system. With readahead enabled time is changing a little bit up and down for every reboot. The fastest start I've read has been just under six seconds plus kernel......
But anyway thanks for the explanation about syslog.socket and for suggestions to speedup boottime.

litemotiv · 2011-07-19 17:54:46

ron9, your udev-trigger.service call seems quite slow, i wonder why that is.

tomegun · 2011-07-19 20:36:09

litemotiv wrote:

ron9, your udev-trigger.service call seems quite slow, i wonder why that is.

The call to trigger should be instantaneous, so (unless there is a bug in udev), this is just a side-effect of having a slow HDD.

ron9 · 2011-07-19 22:31:46

litemotiv wrote:

ron9, your udev-trigger.service call seems quite slow, i wonder why that is.

Udev-trigger.service uses between 2.5-3.5sec with readahead enabled. Mutch faster without readahead.

[ronny@olebrumm ~]$ systemd-analyze blame
2776ms systemd-vconsole-setup.service
959ms wireless.service
887ms wpa_supplicant.service
729ms systemd-remount-api-vfs.service
678ms var-lock.mount
663ms media.mount
656ms systemd-logind.service
643ms var-run.mount
438ms home-ronny-mydata.mount
386ms dbus.service
386ms udev-trigger.service
340ms udev.service
303ms systemd-tmpfiles-setup.service
296ms systemd-sysctl.service
172ms systemd-user-sessions.service
169ms home-ronny-homeserver.mount
130ms dcron.service
31ms boot.mount
19ms remount-rootfs.service
1ms dev-mqueue.mount

Startup time is almoust same with and without readahead, but as you see some services are slower with and faster without... ?

tomegun wrote:

The call to trigger should be instantaneous, so (unless there is a bug in udev), this is just a side-effect of having a slow HDD.

My HDD is a Seagate Momentus 7200rpm, sata 3Gb/s, 8mb cache. Not so slow, but in comparison with SSD....(on my wish list)
But maybe slow enough to make udev.trigger.service so slow.

.

tomegun · 2011-07-19 22:46:45

ron9 wrote:

My HDD is a Seagate Momentus 7200rpm, sata 3Gb/s, 8mb cache. Not so slow, but in comparison with SSD....(on my wish list)
But maybe slow enough to make udev.trigger.service so slow.
.

Yeah, in my simplistic world view "slow==HDD", "fast==SSD"

To compound the issue, I believe readahead is run with real-time priority if you are on a HDD, which means that start-up of some other services will be starved and appear to take a very long time. The total time should of course (in theory) be shorter with readehead, but YMMV. There is probably a lot of low hanging fruit if you want to have a look at optimizing readahead for HDD as I believe all he main devs use SSD.

Essentially, I think "systemd-analyze blame" should be taken with a shovel of salt when using HDD.

Stebalien · 2011-07-22 04:51:29

For some reason, running net-auto-wireless (netcfg) from systemd/systemctl fails with the following error:

iwl3945 0000:0c:00.0: Error: Response NULL in 'REPLY_ADD_STA'
iwl3945 0000:0c:00.0: Adding station ff:ff:ff:ff:ff:ff failed.

.service file:

[Unit]
Description=Automatically connect to a wireless network.
Before=network.target
After=ufw.service
Wants=network.target

[Service]
Type=forking
ExecStart=/etc/rc.d/net-auto-wireless start
ExecStop=/etc/rc.d/net-auto-wireless stop

[Install]
WantedBy=default.target

Starting it manually and from the default arch initscripts works fine.

Any ideas?

litemotiv · 2011-07-22 07:37:42

Stebalien wrote:

For some reason, running net-auto-wireless (netcfg) from systemd/systemctl fails with the following error:
iwl3945 0000:0c:00.0: Error: Response NULL in 'REPLY_ADD_STA'
iwl3945 0000:0c:00.0: Adding station ff:ff:ff:ff:ff:ff failed.

Try this one:

[Unit]
Description=Automatically connect to wireless network
Requires=wireless-regdom.service
After=wireless-regdom.service

[Service]
Type=forking
ExecStart=/usr/bin/netcfg-wpa_actiond wlan0 
ExecStop=/usr/bin/netcfg-wpa_actiond stop wlan0 
StandardOutput=syslog

[Install]
WantedBy=multi-user.target

Stebalien · 2011-07-22 16:42:27

I don't have wireless-regdom.service so I used sys-subsystem-devices-net-wlan0.device instead. Thanks.

[Unit]
Description=Automatically connect to a wireless network.
After=ufw.service sys-subsystem-devices-net-wlan0.device

[Service]
Type=forking
EnvironmentFile=/etc/rc.conf
ExecStart=/usr/bin/netcfg-wpa_actiond ${WIRELESS_INTERFACE}
ExecStop=/usr/bin/netcfg-wpa_actiond stop ${WIRELESS_INTERFACE}
StandardOutput=syslog

[Install]
WantedBy=multi-user.target

Last edited by Stebalien (2011-07-22 16:42:50)

ato10 · 2011-07-24 09:42:38

Have someone problem with the last kernel in testing?
It doesn't work for me.

tomegun · 2011-07-24 11:34:39

ato10 wrote:

Have someone problem with the last kernel in testing?
It doesn't work for me.

I think you'd have to provide a bit more details. Is it strictly systemd related? It is probably worth filing a bug report.

ato10 · 2011-07-24 12:25:09

You right
I'd like to know is if there is any known problem, otherwise I will try to fend

eworm · 2011-07-24 12:37:01

Works fine here... Without any problems so far.

14:35:48 root@leda:~# uname -a
Linux leda 3.0.0-ARCH #1 SMP PREEMPT Sat Jul 23 23:17:54 CEST 2011 x86_64 Intel(R) Atom(TM) CPU N550 @ 1.50GHz GenuineIntel GNU/Linux
14:35:52 root@leda:~# ps 1
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:02 /bin/systemd

ato10 · 2011-07-24 13:58:33

eworm wrote:

Works fine here... Without any problems so far.

thanks for reply.
it was my mistake with syslog-ng which has clogged the log and I forgot to recompile the nvidia-beta. everything works now

framas · 2011-07-27 18:44:55

This days I experimented a little bittle to get the automount feature work with truecrypt.
On the gentoo wiki I found a little mount script to enable truecrypt in fstab which I extend a little by myself.

cat /sbin/mount.truecrypt

#!/usr/bin/env sh
function log(){
logger -t "mount.truecrypt" " ${1}"
}

if [ -z ${USER} ]
then
        _user=frank
else
        _user=${USER}
fi

export DISPLAY=:0
DEV="$1"
MNTPT="$2"
OPTIONS=""
TCOPTIONS=""
export XAUTHORITY=/home/${_user}/.Xauthority
shift 3
IFS=','
for arg in $*; do
    if [ "${arg}" == "system" ]; then
        TCOPTIONS="${TCOPTIONS}-m=system "                                                                                                                                       
    elif [[ "${arg}" == fs=* ]]; then                                                                                                                                            
        FS=${arg#*=}                                                                                                                                                             
        TCOPTIONS="${TCOPTIONS}--filesystem=${FS} "                                                                                                                              
    else                                                                                                                                                                         
        OPTIONS="${OPTIONS}${arg},"                                                                                                                                              
    fi                                                                                                                                                                           
done                                                                                                                                                                             
if [ -z "$(mount | grep ${MNTPT})" ]                                                                                                                                             
then                                                                                                                                                                             
        command="/usr/bin/sudo /usr/bin/truecrypt ${DEV} ${MNTPT} ${TCOPTIONS% *} --fs-options=\"${OPTIONS%,*}\""                                                                
        log "Running ${command} as user ${_user}"                                                                                                                                
        eval "${command}"                                                                                                                                                        
        if [ $? -eq 0 ]                                                                                                                                                          
        then                                                                                                                                                                     
                log "${MNTPT} successfully mounted"                                                                                                                              
        else                                                                                                                                                                     
                log "truecrypt returned $?"                                                                                                                                      
                exit $?                                                                                                                                                          
        fi                                                                                                                                                                       
else
        log "${MNTPT} is already mounted"
fi

In the next step I put a entry to fstab

/dev/sdb9 /media/private truecrypt       fs=ext4,noauto,defaults,user  0 0

The script works as expected when I call mount /media/privat.
As the next step my idea was to put this in an automount unit.

comment=systemd.automount

in the fstab does not work so I wrote my own units.
The mount unit:

[Unit]
Description=Mount private directory via truecrypt
After=kdm.service

[Mount]
What=/dev/sdb9
Where=/media/private
Type=truecrypt                                                                                                                                                                   
StandardOutput=syslog                                                                                                                                                            
StandardError=syslog                                                                                                                                                             
Options=fs=ext4                                                                                                                                                                  
DirectoryMode=750

The automount unit:

[Unit]                                                                                                                                                                           
Description=Mount private directory via truecrypt                                                                                                                                
After=kdm.service

[Automount]
Where=/media/private

[Install]
WantedBy=graphical.target

The problem now is that I cannot get the unit to start automatically during system startup / xsession startup or whatever I had to put this...
When I put this units after media.mount instead of kdm.service systemd hangs during startup because it wants to launch truecrypt.
Whith After=kdm.service kde is started normally but the unit is marked as death.
When I enable and start the service manually in X it works as expected when I try to access /media/private.
So I think I had to find the right start point for this unit and that's the point I want ask for help from you.

PS: I run kdm with autologon.

Wey · 2011-07-27 19:33:32

I noticed these lines in my dmesg:

[    8.637761] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp configured, ignoring.
[    8.638000] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.X11-unix configured, ignoring.
[    8.638009] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.ICE-unix configured, ignoring.
[    8.638017] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.XIM-unix configured, ignoring.
[    8.638037] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.font-unix configured, ignoring.
[    8.638044] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.Test-unix configured, ignoring.

I searched for the corresponding configuration files:

$ grep -rIE '(X11|ICE|XIM|font|Test)-unix' /usr
...
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.X11-unix    1777 root root
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.ICE-unix    1777 root root
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.XIM-unix    1777 root root
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.font-unix   1777 root root
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.Test-unix   1777 root root
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.X11-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.ICE-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.XIM-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.font-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.Test-unix 1777 root root 10d
...
$ LANG="" pacman -Qo /usr/lib/tmpfiles.d/x11.conf /usr/lib/tmpfiles.d/arch.conf 
/usr/lib/tmpfiles.d/arch.conf is owned by initscripts 2011.07.2-1
/usr/lib/tmpfiles.d/x11.conf is owned by systemd 30-1

Can i just ignore it?

falconindy · 2011-07-27 19:41:47

Sure. You can uninstall initscripts, too.

Wey · 2011-07-27 20:09:43

Thanks for your feedback. A native systemd setup was on my todo list for quite some time now, but i kept setting it aside.

Wey · 2011-07-27 23:46:34

I guess I'm mostly done. The only issue i encountered was with the consolefont hook in mkinitcpio:

  -> Parsing hook: [consolefont]
grep: /etc/rc.conf: No such file or directory

So in /lib/initcpio/install/consolefont i replaced

eval "$(grep -e "^CONSOLEFONT=" /etc/rc.conf)"

with

eval "$(grep -e "^FONT=" /etc/vconsole.conf)"

falconindy · 2011-07-28 13:07:06

Important!

If you are upgrading to v31 either by the soon to be hitting [community-testing] package or via systemd-git, please make sure you restart systemd-logind.service (via systemctl). If you do not do this, you will be locked out of SSH (and possibly more) if you are using systemd-pam (which damnit, you should be).

Update: v31 will not make to community-testing due to some blockers. I'm still undecided as to whether or not I'll add a try-restart to the install scriptlet for v32.

Last edited by falconindy (2011-07-28 14:15:50)

bart_vv · 2011-07-29 21:33:27

I seem to have a problem with systemd + rc.local. With sysVinit I used rc.local for my laptop graphics switching (I want my discrete graphics card powered off all the time) - there were few tweaks like sleep 5 between "modprobe radeon" and "echo OFF > /sys/kernel/debug/vgaswitcheroo/switch" - otherwise it won't work(and I cannot load radeon module normally - see https://wiki.archlinux.org/index.php/Acer_TimelineX ). "sleep x" command seems to malfunction with systemd. Can anyone confirm this? Any suggestions for workaround?

tomegun · 2011-07-29 21:39:49

bart_vv wrote:

I seem to have a problem with systemd + rc.local. With sysVinit I used rc.local for my laptop graphics switching (I want my discrete graphics card powered off all the time) - there were few tweaks like sleep 5 between "modprobe radeon" and "echo OFF > /sys/kernel/debug/vgaswitcheroo/switch" - otherwise it won't work(and I cannot load radeon module normally - see https://wiki.archlinux.org/index.php/Acer_TimelineX ). "sleep x" command seems to malfunction with systemd. Can anyone confirm this? Any suggestions for workaround?

Could you post exactly your contents of rc.local, as well as the output of "systemctl status rc-local.service"

bart_vv · 2011-07-30 00:00:59

It's modprobe radeon, sleep and echo OFF > /sys/kernel/debug/vgaswitcheroo/switch just as I said, nothing more:

#!/bin/bash
#
# /etc/rc.local: Local multi-user startup script.
#

modprobe radeon
sleep 5 ; echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

rc-local service is enabled, it loads radeon module. It works when I run it manually, it worked with sysVinit. I know that rc.local is a bad way usually, but I think that such a simple thing should work.

rc-local.service - /etc/rc.local Compatibility
      Loaded: loaded (/lib/systemd/system/rc-local.service)
      Active: active (exited) since Sat, 30 Jul 2011 01:28:31 +0200; 3min 39s ago
     Process: 557 ExecStart=/etc/rc.local (code=killed, signal=HUP)
      CGroup: name=systemd:/system/rc-local.service

Arch Linux

#851 2011-07-18 23:10:01

Re: systemd: Yet Another Init Replacement

#852 2011-07-19 16:17:11

Re: systemd: Yet Another Init Replacement

#853 2011-07-19 16:35:56

Re: systemd: Yet Another Init Replacement

#854 2011-07-19 17:37:24

Re: systemd: Yet Another Init Replacement

#855 2011-07-19 17:54:46

Re: systemd: Yet Another Init Replacement

#856 2011-07-19 20:36:09

Re: systemd: Yet Another Init Replacement

#857 2011-07-19 22:31:46

Re: systemd: Yet Another Init Replacement

#858 2011-07-19 22:46:45

Re: systemd: Yet Another Init Replacement

#859 2011-07-22 04:51:29

Re: systemd: Yet Another Init Replacement

#860 2011-07-22 07:37:42

Re: systemd: Yet Another Init Replacement

#861 2011-07-22 16:42:27

Re: systemd: Yet Another Init Replacement

#862 2011-07-24 09:42:38

Re: systemd: Yet Another Init Replacement

#863 2011-07-24 11:34:39

Re: systemd: Yet Another Init Replacement

#864 2011-07-24 12:25:09

Re: systemd: Yet Another Init Replacement

#865 2011-07-24 12:37:01

Re: systemd: Yet Another Init Replacement

#866 2011-07-24 13:58:33

Re: systemd: Yet Another Init Replacement

#867 2011-07-27 18:44:55

Re: systemd: Yet Another Init Replacement

#868 2011-07-27 19:33:32

Re: systemd: Yet Another Init Replacement

#869 2011-07-27 19:41:47

Re: systemd: Yet Another Init Replacement

#870 2011-07-27 20:09:43

Re: systemd: Yet Another Init Replacement

#871 2011-07-27 23:46:34

Re: systemd: Yet Another Init Replacement

#872 2011-07-28 13:07:06

Re: systemd: Yet Another Init Replacement

#873 2011-07-29 21:33:27

Re: systemd: Yet Another Init Replacement

#874 2011-07-29 21:39:49

Re: systemd: Yet Another Init Replacement

#875 2011-07-30 00:00:59

Re: systemd: Yet Another Init Replacement

Board footer