systemd: Yet Another Init Replacement

Neije · 2011-07-06 20:19:54

Sorry my question isn't really in the flow, but I couldn't find information on when & how Arch is supposed to move from SysV to Systemd ? Is it actually planned ? or not ?

Zom · 2011-07-06 21:21:36

It's not planned AFAIK.

ron9 · 2011-07-07 16:47:55

[Unit]
Description=Network Connectivity
Before=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set wlan0 up ; /usr/sbin/iwconfig wlan0 essid "KL" ; /sbin/ip addr add 10.252.82.10/24 dev wlan0 ; /sbin/ip route add default via 10.252.82.1
ExecStop=/sbin/ip link set wlan0 down
Restart=always
[Install]
WantedBy=multi-user.target..

I have used net-profiles.service for a while. It used 12 seconds to connect to the wireless router with WPA2 security.
Now with this service file and wpa_supplicant.service starting at the same time it connect in 1 second.... Nice!

Startup finished in 3230ms (kernel) + 6846ms (userspace) = 10076ms.

I have one problem. When I reboot the router network does not restart. Anyone has a solution to this?

Not a problem. My mistake....

.

Last edited by ron9 (2011-07-08 22:34:06)

WorMzy · 2011-07-11 01:05:16

I'm trying to write a service to start my network on an install without a network manager, but it seems that systemd doesn't like dhcpcd, and keeps sending it SIGTERM after it gets to a certain point.

Here's the service:

[Unit]
Description=Connect to NETGEAR
After=syslog.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/iwconfig wlan0 essid NETGEAR key ********** ; /usr/sbin/dhcpcd wlan0
Restart=always

[Install]
WantedBy=multi-user.target

and here's the accompanying daemon.log:

Jul 11 01:31:00 localhost dhcpcd[2841]: version 5.2.12 starting
Jul 11 01:31:00 localhost dhcpcd[2841]: wlan0: rebinding lease of 192.168.0.6
Jul 11 01:31:00 localhost dhcpcd[2841]: wlan0: acknowledged 192.168.0.6 from 192.168.0.1
Jul 11 01:31:00 localhost dhcpcd[2841]: wlan0: checking for 192.168.0.6
Jul 11 01:31:05 localhost dhcpcd[2841]: wlan0: leased 192.168.0.6 for 259200 seconds
Jul 11 01:31:05 localhost dhcpcd[2841]: forked to background, child pid 2867
Jul 11 01:31:05 localhost dhcpcd[2867]: received SIGTERM, stopping
Jul 11 01:31:05 localhost dhcpcd[2867]: wlan0: removing interface
Jul 11 01:31:06 localhost systemd[1]: netgear.service holdoff time over, scheduling restart.
Jul 11 01:31:06 localhost systemd[1]: Job pending for unit, delaying automatic restart.
Jul 11 01:31:06 localhost dhcpcd[2877]: version 5.2.12 starting
Jul 11 01:31:06 localhost dhcpcd[2877]: wlan0: rebinding lease of 192.168.0.6
Jul 11 01:31:06 localhost dhcpcd[2877]: wlan0: acknowledged 192.168.0.6 from 192.168.0.1
Jul 11 01:31:06 localhost dhcpcd[2877]: wlan0: checking for 192.168.0.6
Jul 11 01:31:12 localhost dhcpcd[2877]: wlan0: leased 192.168.0.6 for 259200 seconds
Jul 11 01:31:12 localhost dhcpcd[2877]: forked to background, child pid 2904
Jul 11 01:31:12 localhost dhcpcd[2904]: received SIGTERM, stopping
Jul 11 01:31:12 localhost dhcpcd[2904]: wlan0: removing interface
Jul 11 01:31:12 localhost systemd[1]: netgear.service holdoff time over, scheduling restart.
Jul 11 01:31:12 localhost systemd[1]: Job pending for unit, delaying automatic restart.
Jul 11 01:31:12 localhost dhcpcd[2915]: version 5.2.12 starting

etc.

Removing "Restart=always" still ends with a SIGTERM.

Does anyone have any advice regarding this? Am I missing something obvious?

EDIT: falconindy swoops to rescue. Replacing "Restart=always" with "RemainAfterExit=yes" solves the problem.

Last edited by WorMzy (2011-07-11 01:22:34)

ron9 · 2011-07-13 22:41:31

I have a windows home server that I mount with comment=systemd.automount. It tries to mount at boot, but fail with the following error message.

CIFS VFS: Error connecting to socket. Aborting operation
CIFS VFS: cifs_mount failed w/return code = -101

It mounts when I open it in filemanager and then it also shows active in systemctl.

# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
devpts /dev/pts devpts defaults 0 0
shm /dev/shm tmpfs nodev,nosuid 0 0
LABEL=boot /boot ext4 defaults,noatime 0 2
LABEL=arch / ext4 defaults,noatime 0 1
LABEL=swap swap swap defaults 0 0
LABEL=mydata /home/mydata ntfs-3g defaults 0 0
//10.252.82.20/shares /home/ronny/homeserver cifs credentials=/home/ronny/.me,comment=systemd.automount 0 0

I think the error message comes because it try to mount before net is up.
But I thought systemd.automount should first be active when it was needed.
Am I doing something wrong? How do I get rid of error message with cifs?

.

falconindy · 2011-07-14 10:15:10

network mounts should be properly marked with _netdev in the options section.

ron9 · 2011-07-14 13:26:25

Thanks for the quick reply.

//10.252.82.20/shares /home/ronny/homeserver cifs _netdev,credentials=/home/ronny/.me,comment=systemd.automount 0 0

Still got the error message on screen on startup.
I probably still have to use systemd.automount ?

MrPetzold123 · 2011-07-15 17:00:10

Hi all,

I tested systemd against default Arch initscripts. systemd definitely is much faster (over 10 seconds faster, in fact).

I have posted a short video of my Pentium 4 (2 Ghz, 5400 rpm hdd) system booting from grub to slim in about 15 seconds here:

http://www.youtube.com/watch?v=BfAeWbtj36A

Some notes:
-Uses default kernel + initial ramdisk
-/boot and /home are mounted using comment=systemd.automount
-uses systemd readahead implementation (does not have big effect)
-uses static ip (dhcpd on systemd does not have as big impact as on default init because of parallelization)
-systemd feels a little bit overly complicated, especially Wants/WantedBy, Before/After logics make it difficult to see the "big picture"
-Big users of time are filesystem check, filesystem mount, udev, dhcp, vconsole setup (even though I only have 2 tty's)
-Will be interesting to see Meego's systemd implementation in Meego 1.3 (they have stated their intention of have zero bash scripts and they are the guys that brought us 5 second moblin boot previously).

JK

falconindy · 2011-07-15 17:21:28

Feel free to look at systemd-analyze if you want an SVG bootchart or a blame list to further figure out where to optimize...

That said, faster boot is among the less interesting reasons to use systemd. Let's just throw aside socket/dbus/path/timer activated services, udev integration, fine grained process management via cgroups, daemon supervision, multi-seat handling, local and network based automounting, etc etc all because we can boot in 5 seconds

tomegun · 2011-07-15 17:28:06

MrPetzold123 wrote:

I tested systemd against default Arch initscripts. systemd definitely is much faster (over 10 seconds faster, in fact).
I have posted a short video of my Pentium 4 (2 Ghz, 5400 rpm hdd) system booting from grub to slim in about 15 seconds here:
http://www.youtube.com/watch?v=BfAeWbtj36A
Some notes:
-Uses default kernel + initial ramdisk
-/boot and /home are mounted using comment=systemd.automount
-uses systemd readahead implementation (does not have big effect)
-uses static ip (dhcpd on systemd does not have as big impact as on default init because of parallelization)
-systemd feels a little bit overly complicated, especially Wants/WantedBy, Before/After logics make it difficult to see the "big picture"
-Big users of time are filesystem check, filesystem mount, udev, dhcp, vconsole setup (even though I only have 2 tty's)
-Will be interesting to see Meego's systemd implementation in Meego 1.3 (they have stated their intention of have zero bash scripts and they are the guys that brought us 5 second moblin boot previously).

This is nice to see. Couple of remarks:

You could try to speed up (probably not very much) a bit more by adding "noauto" to your /boot partition, and then it will only be fscked the first time you actually access it (which you probably don't do very often).

My experience with such a slow hdd as what you have, is that "systemd-analyze blame" is not very useful. When your IO is maxed out you might get temporary "hangs" and systemd-analyze will blame the processes that happened to be running at the time of the hang rather than the process that caused the IO (at least that's how it was explained to me when I pointed out very weird numbers). The total time is of course correct, it is just the distribution between the services that is off.

Edit:

A couple more suggestions:

Boot with "quiet", this will remove all the startup messages, and this (rather surprisingly) makes a difference in boot speed.

Something which is not really advisable without systemd: you can disable syslog-ng/rsyslog and rely on dmesg for all your logging. Obviously this means you lose your logs on reboot, but for a laptop (with a slow harddrive) it might be worth the trade-off. This will be even nicer with the next util-linux release where you can filter dmesg to only show the messages you care about.

-t

Last edited by tomegun (2011-07-15 17:33:50)

MrPetzold123 · 2011-07-15 19:56:11

tomegun wrote:

You could try to speed up (probably not very much) a bit more by adding "noauto" to your /boot partition, and then it will only be fscked the first time you actually access it (which you probably don't do very often).

Yes, I actually did that for both /boot and /home. This is a very nice feature of systemd.

tomegun wrote:

My experience with such a slow hdd as what you have, is that "systemd-analyze blame" is not very useful. When your IO is maxed out you might get temporary "hangs" and systemd-analyze will blame the processes that happened to be running at the time of the hang rather than the process that caused the IO (at least that's how it was explained to me when I pointed out very weird numbers). The total time is of course correct, it is just the distribution between the services that is off.

Yes, probably the only way is to just try to start a minimum number of processes. My echo $$ now shows 684, which is still quite a lot.

tomegun wrote:

A couple more suggestions:
Boot with "quiet", this will remove all the startup messages, and this (rather surprisingly) makes a difference in boot speed.

Yes, but it feels slower because nothing seems to be happening ;-)

tomegun wrote:

Something which is not really advisable without systemd: you can disable syslog-ng/rsyslog and rely on dmesg for all your logging. Obviously this means you lose your logs on reboot, but for a laptop (with a slow harddrive) it might be worth the trade-off. This will be even nicer with the next util-linux release where you can filter dmesg to only show the messages you care about.

I will try that, thanks !

JK

MrPetzold123 · 2011-07-15 20:10:53

falconindy wrote:

Feel free to look at systemd-analyze if you want an SVG bootchart or a blame list to further figure out where to optimize...
That said, faster boot is among the less interesting reasons to use systemd. Let's just throw aside socket/dbus/path/timer activated services, udev integration, fine grained process management via cgroups, daemon supervision, multi-seat handling, local and network based automounting, etc etc all because we can boot in 5 seconds

Yes, these other features are very important. Isn't is nice that with systemd we can get it all ;-)

One beneficial thing that systemd hopefully/probably will do to Linux is that system startup will more de facto standardized between distros.

JK

tomegun · 2011-07-15 20:34:36

MrPetzold123 wrote:

tomegun wrote:
You could try to speed up (probably not very much) a bit more by adding "noauto" to your /boot partition, and then it will only be fscked the first time you actually access it (which you probably don't do very often).
Yes, I actually did that for both /boot and /home. This is a very nice feature of systemd.

I'd suggest haveng "comment=systemd.automount" on both /boot and /home, but "noauoto" only on /boot. This means that boot does not wait for either of them to be mounted, but /home is fsck'ed and mounted as soon as possible without waiting for the first access (unless you have a setup where for some reason you don't always access /home right after boot).

-t

PS

I never measured the impact of these things, so don't know how much it will save you (if anything).

ron9 · 2011-07-16 19:39:15

tomegun wrote:

I'd suggest haveng "comment=systemd.automount" on both /boot and /home, but "noauoto" only on /boot.

Startup time reduced by almost 1 second.

Startup finished in 3368ms (kernel) + 5988ms (userspace) = 9356ms

CPU~Dual core Intel Core2 Duo Kernel~2.6.39-ARCH x86_64 Mem~2GB HDD~100.0GB 7200rpm

It also popped into my brain that I overlooked to put noauto in fstab when I mounted my windows home server.

//10.252.82.20/shares /home/ronny/homeserver cifs credentials=/home/ronny/.me,uid=ronny,gid=users,noauto,comment=systemd.automount 0 0

Now I got rid of the error message... And it automount when its needed. ie when I start filemanager.

ron9 wrote:

CIFS VFS: Error connecting to socket. Aborting operation
CIFS VFS: cifs_mount failed w/return code = -101

I want to thank Tom for the eloquent and detailed explanations. As MrPetzold said, it is not easy to see the "big picture"

.

litemotiv · 2011-07-18 12:04:21

Did anything change in the locale settings?

% cat /etc/locale.conf
LANG=en_US.utf8
LC_COLLATE=C

% locale
LANG=en_US
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

falconindy · 2011-07-18 13:00:17

Works for me. I notice that in /etc/locale.gen, it's actually en_US.UTF-8, not en_US.utf8. Doesn't explains why LC_COLLATE isn't being set properly though.

The only recent changes to locale was the addition of a tiny daemon, localed (systemd v30), to allow desktop programs to update locale via policykit.

litemotiv · 2011-07-18 14:04:32

falconindy wrote:

Works for me. I notice that in /etc/locale.gen, it's actually en_US.UTF-8, not en_US.utf8. Doesn't explains why LC_COLLATE isn't being set properly though.

The naming is a bit confusing yes:

% locale-gen

Generating locales...
  en_US.ISO-8859-1... done
  en_US.UTF-8... done
Generation complete.

% locale -a
C
en_US
en_US.iso88591
en_US.utf8
POSIX

but changing to uppercase "UTF-8" doesn't seem to solve it, strange..

[edit] a possible cause, but even more strange:

% cat /etc/profile.d/locale.sh
export LANG=en_US

% ls -la /etc/profile.d/locale.sh
-rwxr-xr-x  1 root root   18 Jul 16 18:59 locale.sh

% pacman -Qo /etc/profile.d/locale.sh
error: No package owns locale.sh

Now where on earth did that come from...

Last edited by litemotiv (2011-07-18 14:25:47)

tomegun · 2011-07-18 14:34:46

litemotiv wrote:

[edit] a possible cause, but even more strange:
% pacman -Qo /etc/profile.d/locale.sh
error: No package owns locale.sh
Now where on earth did that come from...

It was created by rc.sysinit before you switched to systemd. Wearing my initscripts-maintainer-hat: we should _really_ stop doing that. Patches welcome!

You can safely delete it (there might be a behavioral change, but it should IMHO be the correct behaviour).

litemotiv · 2011-07-18 14:47:01

tomegun wrote:

It was created by rc.sysinit before you switched to systemd. Wearing my initscripts-maintainer-hat: we should _really_ stop doing that. Patches welcome!
You can safely delete it (there might be a behavioral change, but it should IMHO be the correct behaviour).

Ah right, i booted once without systemd 2 days ago, it must have been created then. I deleted it now and it stopped setting the locale, so that's good. Now to find out how to get systemd pick it up again since it's completely empty now:

% locale

LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

falconindy · 2011-07-18 17:30:31

Very strange. So, digging through the code, locale_setup(void) in src/locale-setup.c is what does the work of parsing the various environment files. locale_setup is called in main, and the only thing protecting it is:

if (arg_running_as == MANAGER_SYSTEM && !serialization) {

Which basically protects this from being run when you execute 'systemd --test' or 'kill 1'. Otherwise, it should be working...

I still can't reproduce this on systemd 30 or the latest from git.

bluetech · 2011-07-18 18:55:53

From getty@.service:

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION=

So if you happen to use startx or similar, you need to reset the locale, or change the service file.

falconindy · 2011-07-18 19:06:54

Good catch. Found where I'm getting this populated from my config files. I'd be more inclined to change the service file to use the -8 option to agetty and ignore this Environment unsetting crap. I'll see what upstream thinks...

falconindy · 2011-07-18 19:26:44

Uggh...this is broken behavior upstream

https://bugzilla.redhat.com/show_bug.cgi?id=663900

Unsetting the locale environment vars is a filthy hack to avoid issues with indian characters which the terminal cannot display. I'm inclined to fix this in our package since I suspect that there's a larger ratio of archers logging in at a getty than there is for say, fedora.

Edit: On a related note, this unsetting business has been happening since January... why is it only coming up now?

Last edited by falconindy (2011-07-18 19:29:13)

tomegun · 2011-07-18 20:54:24

I didn't notice as my locale is "en_US.UTF-8", which most of the time (always?) is the same as "".

I agree that this hack should be removed, though maybe it would be good to get upstream to do so? If I understand correctly, Lennart wants this to be fixed in util-linux, which probably is the right thing to do (unless there is a way to teach the console to show all the right glyphs?). I guess that this will take a long time though, and in the meantime I think it is much more reasonable for the small minority that are affected by this to apply the hack locally.

What about just commenting out the unsetting, with a small note explaining why one might un-comment it? Maybe this would even be acceptable upstream?

Viper_Scull · 2011-07-18 22:05:07

tomegun wrote:

Something which is not really advisable without systemd: you can disable syslog-ng/rsyslog and rely on dmesg for all your logging. Obviously this means you lose your logs on reboot, but for a laptop (with a slow harddrive) it might be worth the trade-off. This will be even nicer with the next util-linux release where you can filter dmesg to only show the messages you care about.

Since I'm on an SSD and my log dir is mounted in ram, i'd like to try this.
I guess i'll have to remove syslog.target in the field After in every unit with it, right?

Arch Linux

#826 2011-07-06 20:19:54

Re: systemd: Yet Another Init Replacement

#827 2011-07-06 21:21:36

Re: systemd: Yet Another Init Replacement

#828 2011-07-07 16:47:55

Re: systemd: Yet Another Init Replacement

#829 2011-07-11 01:05:16

Re: systemd: Yet Another Init Replacement

#830 2011-07-13 22:41:31

Re: systemd: Yet Another Init Replacement

#831 2011-07-14 10:15:10

Re: systemd: Yet Another Init Replacement

#832 2011-07-14 13:26:25

Re: systemd: Yet Another Init Replacement

#833 2011-07-15 17:00:10

Re: systemd: Yet Another Init Replacement

#834 2011-07-15 17:21:28

Re: systemd: Yet Another Init Replacement

#835 2011-07-15 17:28:06

Re: systemd: Yet Another Init Replacement

#836 2011-07-15 19:56:11

Re: systemd: Yet Another Init Replacement

#837 2011-07-15 20:10:53

Re: systemd: Yet Another Init Replacement

#838 2011-07-15 20:34:36

Re: systemd: Yet Another Init Replacement

#839 2011-07-16 19:39:15

Re: systemd: Yet Another Init Replacement

#840 2011-07-18 12:04:21

Re: systemd: Yet Another Init Replacement

#841 2011-07-18 13:00:17

Re: systemd: Yet Another Init Replacement

#842 2011-07-18 14:04:32

Re: systemd: Yet Another Init Replacement

#843 2011-07-18 14:34:46

Re: systemd: Yet Another Init Replacement

#844 2011-07-18 14:47:01

Re: systemd: Yet Another Init Replacement

#845 2011-07-18 17:30:31

Re: systemd: Yet Another Init Replacement

#846 2011-07-18 18:55:53

Re: systemd: Yet Another Init Replacement

#847 2011-07-18 19:06:54

Re: systemd: Yet Another Init Replacement

#848 2011-07-18 19:26:44

Re: systemd: Yet Another Init Replacement

#849 2011-07-18 20:54:24

Re: systemd: Yet Another Init Replacement

#850 2011-07-18 22:05:07

Re: systemd: Yet Another Init Replacement

Board footer