You are not logged in.

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

Neije
Member
Registered: 2011-07-06
Posts: 31

Re: systemd: Yet Another Init Replacement

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 ?

Offline

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

Zom
Member
From: Sweden
Registered: 2007-10-27
Posts: 430

Re: systemd: Yet Another Init Replacement

It's not planned AFAIK.

Offline

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

ron9
Member
From: Norway
Registered: 2011-02-02
Posts: 119

Re: systemd: Yet Another Init Replacement

[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.... tongue

.

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


lenovo w500 - huawei matebook 14 | archlinux | swaywm | alacritty | falkon

Offline

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

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,788
Website

Re: systemd: Yet Another Init Replacement

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)


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

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

ron9
Member
From: Norway
Registered: 2011-02-02
Posts: 119

Re: systemd: Yet Another Init Replacement

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?

.


lenovo w500 - huawei matebook 14 | archlinux | swaywm | alacritty | falkon

Offline

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

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

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

Offline

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

ron9
Member
From: Norway
Registered: 2011-02-02
Posts: 119

Re: systemd: Yet Another Init Replacement

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 ?


lenovo w500 - huawei matebook 14 | archlinux | swaywm | alacritty | falkon

Offline

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

MrPetzold123
Member
Registered: 2011-07-15
Posts: 3

Re: systemd: Yet Another Init Replacement

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

Offline

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

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

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 wink

Offline

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

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

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)

Offline

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

MrPetzold123
Member
Registered: 2011-07-15
Posts: 3

Re: systemd: Yet Another Init Replacement

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

Offline

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

MrPetzold123
Member
Registered: 2011-07-15
Posts: 3

Re: systemd: Yet Another Init Replacement

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 wink

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

Offline

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

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

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).

Offline

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

ron9
Member
From: Norway
Registered: 2011-02-02
Posts: 119

Re: systemd: Yet Another Init Replacement

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. big_smile

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... wink   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"

.


lenovo w500 - huawei matebook 14 | archlinux | swaywm | alacritty | falkon

Offline

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

litemotiv
Forum Fellow
Registered: 2008-08-01
Posts: 5,026

Re: systemd: Yet Another Init Replacement

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=

ᶘ ᵒᴥᵒᶅ

Offline

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

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

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.

Offline

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

litemotiv
Forum Fellow
Registered: 2008-08-01
Posts: 5,026

Re: systemd: Yet Another Init Replacement

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)


ᶘ ᵒᴥᵒᶅ

Offline

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

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

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).

Offline

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

litemotiv
Forum Fellow
Registered: 2008-08-01
Posts: 5,026

Re: systemd: Yet Another Init Replacement

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=

ᶘ ᵒᴥᵒᶅ

Offline

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

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

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.

Offline

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

bluetech
Member
Registered: 2007-10-26
Posts: 7

Re: systemd: Yet Another Init Replacement

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.

Offline

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

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

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...

Offline

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

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

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)

Offline

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

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

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?

Offline

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

Viper_Scull
Member
From: London, UK
Registered: 2011-01-15
Posts: 153

Re: systemd: Yet Another Init Replacement

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?


Athlon II X4 620 + Gigabyte 785GPM-UD2H + 4GB DDR3 + SSD OCZ Vertex2 60GB

Archlinux x86_64 + Openbox

Offline

Board footer

Powered by FluxBB