You are not logged in.

#426 2011-04-22 12:01:12

Kane
Member
Registered: 2006-10-08
Posts: 220

Re: systemd: Yet Another Init Replacement

I've just installed systemd, and have been testing it.

I have to say after reading http://0pointer.de/blog/projects/systemd.html i was expecting a great improvement in performance.

Results:
Standard arch from grub to gdm = 22.40s , 3665 processes, 193Mb memory
Systemd = 23.93s, 3440 processes, 185Mb memory

So yes there is a slight improvement, but for me i cant justify it over the added 'complexity'.

(still having to use daemons array for iptables crond cpufreq and sensors - might this reduce the performance?)


Kane

Offline

#427 2011-04-22 12:36:22

intgr
Member
Registered: 2009-10-02
Posts: 44

Re: systemd: Yet Another Init Replacement

Kane wrote:

I have to say after reading http://0pointer.de/blog/projects/systemd.html i was expecting a great improvement in performance.

Well, it does take a bit of tweaking to fully exploit its potential.

Did you install initscripts-systemd and systemd-arch-units? Not entirely sure, but without those I think it just runs the usual Arch bash init scripts, so you get no benefits from systemd.

Also, enable systemd-readahead-replay.service and systemd-readahead-collect.service, these will speed up boot the 2nd time around.

To figure out which units are slowing you down, read this: http://0pointer.de/blog/projects/blame-game.html

Offline

#428 2011-04-22 13:06:48

Kane
Member
Registered: 2006-10-08
Posts: 220

Re: systemd: Yet Another Init Replacement

Did you install initscripts-systemd and systemd-arch-units? Not entirely sure, but without those I think it just runs the usual Arch bash init scripts, so you get no benefits from systemd.

Also, enable systemd-readahead-replay.service and systemd-readahead-collect.service, these will speed up boot the 2nd time around.

To figure out which units are slowing you down, read this: http://0pointer.de/blog/projects/blame-game.html

Thanks intgr,
I had initscripts-systemd and systemd-arch-units installed already however, i just enabled replay and collect and that speeded up the boot by an extra 2.5s smile

One other slight problem, i tried to get gdm to run using systemctl enable gdm.service, but then upon rebooting it doesnt run. I can only get gdm to work by putting it in the daemons array in rc.conf.

(Edit: if i run systemctl start gdm.service after boot then gdm loads fine, so it seems like its not saving it as enabled?)

Any ideas?

Thanks again
kane

Last edited by Kane (2011-04-22 13:13:47)

Offline

#429 2011-04-22 13:50:05

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

Re: systemd: Yet Another Init Replacement

Kane wrote:

(Edit: if i run systemctl start gdm.service after boot then gdm loads fine, so it seems like its not saving it as enabled?)

If you want to start the daemon, you use systemctl start. If you want to enable it, you use systemctl enable.

Offline

#430 2011-04-22 15:26:44

Kane
Member
Registered: 2006-10-08
Posts: 220

Re: systemd: Yet Another Init Replacement

falconindy wrote:
Kane wrote:

(Edit: if i run systemctl start gdm.service after boot then gdm loads fine, so it seems like its not saving it as enabled?)

If you want to start the daemon, you use systemctl start. If you want to enable it, you use systemctl enable.

I initially tried systemctl enable gdm.service, upon reboot however gdm does not load. So i tried systemctl start gdm.service after boot to test to make sure the gdm.service actually worked correctly (which it does)

Or have i misunderstood the usage? I assumed systemctl enable gdm.service would enable gdm on boot? Or is there something else i have to do?

Cheers
Kane

Offline

#431 2011-04-22 15:47:30

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

Re: systemd: Yet Another Init Replacement

Make sure default.target in /lib/systemd/system symlinks to graphical.target. Alternatively, add systemd.target=graphical.target to your kernel cmdline.

Offline

#432 2011-04-22 15:58:06

Kane
Member
Registered: 2006-10-08
Posts: 220

Re: systemd: Yet Another Init Replacement

lrwxrwxrwx 1 root root   16 Apr 21 03:35 default.target -> graphical.target

I've just tried reinstalling the arch units and initscripts, but no difference.

[root@home kane]# systemctl enable gdm.service
ln -s '/lib/systemd/system/gdm.service' '/etc/systemd/system/graphical.target.wants/gdm.service'

[root@home kane]# ls -l /lib/systemd/system/gdm.service
-rw-r--r-- 1 root root 222 Apr 10 14:38 /lib/systemd/system/gdm.service
[root@home kane]# ls -l /etc/systemd/system/graphical.target.wants/gdm.service
lrwxrwxrwx 1 root root 31 Apr 22 16:56 /etc/systemd/system/graphical.target.wants/gdm.service -> /lib/systemd/system/gdm.service

Does all this look ok?

Edit: Sorry i only just realised, i failed to mention that im using gdm from testing with gnome3, don't know if this needs a different startup script?

Last edited by Kane (2011-04-22 16:20:22)

Offline

#433 2011-04-22 16:30:10

intgr
Member
Registered: 2009-10-02
Posts: 44

Re: systemd: Yet Another Init Replacement

Kane wrote:

lrwxrwxrwx 1 root root   16 Apr 21 03:35 default.target -> graphical.target

I've just tried reinstalling the arch units and initscripts, but no difference.

You have to delete the /etc/systemd/system/default.target file, then it will choose graphical.target by default. /etc/systemd/ files always override what's in /lib/systemd/.

This has always annoyed me. By default the /etc/inittab file defaults to runlevel 3, so the systemd post_install script tries to be uber-smart and creates a default.target pointing to it. I'd much prefer that it didn't do this magic.

  # Try to read default runlevel from the old inittab if it exists
  runlevel=$(/bin/awk -F':' '$3 == "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab 2> /dev/null)
  if [ -z "$runlevel" ]; then
    target="/lib/systemd/system/graphical.target"
  else
    target="/lib/systemd/system/runlevel$runlevel.target"
  fi

  # And symlink what we found to the new-style default.target
  /bin/ln -sf "$target" /etc/systemd/system/default.target
Kane wrote:

Edit: Sorry i only just realised, i failed to mention that im using gdm from testing with gnome3, don't know if this needs a different startup script?

No, that makes no difference.

Last edited by intgr (2011-04-22 16:38:07)

Offline

#434 2011-04-22 19:07:17

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

Re: systemd: Yet Another Init Replacement

intgr wrote:

This has always annoyed me. By default the /etc/inittab file defaults to runlevel 3, so the systemd post_install script tries to be uber-smart and creates a default.target pointing to it. I'd much prefer that it didn't do this magic.

Looking at the structure of the installed package, this actually isn't necessary any longer. default.target defaults to graphical. If you never enable a DM on installation, this will silently fall back to tty. I'll remove it for the next release.

Offline

#435 2011-04-22 19:31:29

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

Re: systemd: Yet Another Init Replacement

I'm officially (as officially as I can) deprecating initscripts-systemd. What does this mean?

  • arch-persistent-settings.service and rc-local.service will move to community/systemd.

  • lvm.service is moving to community/systemd-arch-units.

  • arch-daemon is going away. It's a kludge and I don't like it.

When is this happening? Not sure yet. Probably sooner rather than later. It's too much for me to maintain, particularly when I've been able to pare down the initscripts package to 6 files with plans to remove 2 of them. Figure less than a month.

Last edited by falconindy (2011-04-22 19:32:37)

Offline

#436 2011-04-22 20:33:43

Kane
Member
Registered: 2006-10-08
Posts: 220

Re: systemd: Yet Another Init Replacement

sorry me again guys,

Looks like i've completely fubar'ed it now.

I removed everything (this is before reading intgr's reply)

Pacman -Rsc systemd

However this still left /etc/systemd/ directory, so i removed this and all the .service and .wants within it.

So then i thought id try reinstalling it from scratch:

pacman -S initscripts-systemd

Which also installed systemd, however when systemd is installing i get this message:

warning: directory permissions differ on run/
filesystem: 1777  package: 755

(Don't remember seeing it when i first installed it)

I then installed systemd-arch-units

Rebooted (with init=/bin/systemd appended to kernel line in grub)

(This is the same installation method i used to begin with when it worked)

Now when i try and boot using systemd it stops at the line:

Started remount root FS

For about 5 minutes, and then afterwards prints alot of red aborted errors.

Starting Getty on tty5 aborted because a dependency failed

However i can't scroll up to find out what this dependency was.

Anyone any ideas why this might have suddenly stopped working?

Cheers
Kane

Offline

#437 2011-04-23 03:39:08

vinhsynd
Member
Registered: 2010-08-05
Posts: 56

Re: systemd: Yet Another Init Replacement

Hi!

I read through the wiki and have been looking to try out systemd, however I couldn't find anything on using it with a LUKS encrypted root partition. Has anyone tried this out already?


The older I get the less time I have.

Offline

#438 2011-04-23 05:41:36

MurdersLastCrow
Member
Registered: 2010-10-04
Posts: 74

Re: systemd: Yet Another Init Replacement

Oddly enough, while you guys are reporting relatively insignificant changes in boot speed, my boot went from 23 seconds to 10 just from systemd's basic setup. I'm not even using readahead, yet. So I'd say this is the next big thing, and hopefully we can continue to improve on it to get our boot times down to something miniscule and insignificant.

My phone starts much slower than my computer now. Not sure if that's a good thing. XD

Offline

#439 2011-04-23 06:53:53

eworm
Package Maintainer (PM)
From: Oberhausen, Germany
Registered: 2010-01-30
Posts: 107
Website

Re: systemd: Yet Another Init Replacement

vinhsynd wrote:

I read through the wiki and have been looking to try out systemd, however I couldn't find anything on using it with a LUKS encrypted root partition. Has anyone tried this out already?

Yes, I did, working on a luks encrypted system with systemd atm.
As the initrd manages the root filesystem decryption systemd does not have to care at all... Just try it out, works without problems!


ArchLinux - make it simple & lightweight

Offline

#440 2011-04-23 12:51:15

pankajmore
Member
Registered: 2010-07-06
Posts: 23

Re: systemd: Yet Another Init Replacement

How do i set auto login using systemd ,

I had mingetty --autologin username in /etc/inittab to login to a virtual console. Since sytemd doesnt use inittab ,
I tried replacing the getty file at /etc/systemd/system... to use mingetty but it didnt boot

Offline

#441 2011-04-23 13:14:09

ejona86
Member
Registered: 2011-04-22
Posts: 5

Re: systemd: Yet Another Init Replacement

I was in the same state as Kane, with gdm never starting. As I remember, /etc/systemd/system/default.target pointed to graphical.target, but gdm still wouldn't start on bootup (and it was enabled via systemctl enable). I ended up deleting /etc's default.target and I think a few other files in /etc/systemd and now gdm starts correctly. Just as a note, I had systemd installed much earlier (back when it was in AUR and we were required to use the -git version) and had very little problem with it then, but I didn't have the time to verify the system was correct so I didn't swap over to using it permanently.

I am not seeing my DAEMONS start up though. That seems like a arch-daemon.service problem, but I am seeing it generate things in /run/systemd/generator. As a workaround, I have thus have gone through the list of DAEMONS and manually enabled any of the services I can, but it seems that any service that doesn't have a native .service file can't be enabled:

[root@Twin ~]# systemctl status samba.service
samba.service
      Loaded: loaded (/etc/rc.d/samba)
      Active: inactive (dead)
      CGroup: name=systemd:/system/samba.service
[root@Twin ~]# systemctl enable samba.service
Couldn't find samba.service.
[root@Twin ~]# systemctl is-enabled samba.service
Couldn't find samba.service.
[root@Twin ~]# systemctl start samba.service
[root@Twin ~]# systemctl status samba.service
samba.service
      Loaded: loaded (/etc/rc.d/samba)
      Active: active (running)
     Process: 4676 ExecStart=/etc/rc.d/samba start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/samba.service
          ├ 4687 /usr/sbin/smbd -D
          ├ 4690 /usr/sbin/nmbd -D
          └ 4691 /usr/sbin/smbd -D

I don't understand how systemd lets me start start something manually, but not allow me to enable it to be started automatically. It really seems like arch-daemons.service isn't contributing anything because there is a samba.service in /run/systemd/generator/arch-daemons.target.wants/.

Just as a side question, since arch-daemon.service (and thus DAEMONS support) is going away, then new users will need to 'systemctl enable' all the things in the DAEMONS list?

Offline

#442 2011-04-23 13:41:44

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

Re: systemd: Yet Another Init Replacement

ejona86 wrote:

I was in the same state as Kane, with gdm never starting. As I remember, /etc/systemd/system/default.target pointed to graphical.target, but gdm still wouldn't start on bootup (and it was enabled via systemctl enable). I ended up deleting /etc's default.target and I think a few other files in /etc/systemd and now gdm starts correctly. Just as a note, I had systemd installed much earlier (back when it was in AUR and we were required to use the -git version) and had very little problem with it then, but I didn't have the time to verify the system was correct so I didn't swap over to using it permanently.

I am not seeing my DAEMONS start up though. That seems like a arch-daemon.service problem, but I am seeing it generate things in /run/systemd/generator. As a workaround, I have thus have gone through the list of DAEMONS and manually enabled any of the services I can, but it seems that any service that doesn't have a native .service file can't be enabled:

[root@Twin ~]# systemctl status samba.service
samba.service
      Loaded: loaded (/etc/rc.d/samba)
      Active: inactive (dead)
      CGroup: name=systemd:/system/samba.service
[root@Twin ~]# systemctl enable samba.service
Couldn't find samba.service.
[root@Twin ~]# systemctl is-enabled samba.service
Couldn't find samba.service.
[root@Twin ~]# systemctl start samba.service
[root@Twin ~]# systemctl status samba.service
samba.service
      Loaded: loaded (/etc/rc.d/samba)
      Active: active (running)
     Process: 4676 ExecStart=/etc/rc.d/samba start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/samba.service
          ├ 4687 /usr/sbin/smbd -D
          ├ 4690 /usr/sbin/nmbd -D
          └ 4691 /usr/sbin/smbd -D

I don't understand how systemd lets me start start something manually, but not allow me to enable it to be started automatically. It really seems like arch-daemons.service isn't contributing anything because there is a samba.service in /run/systemd/generator/arch-daemons.target.wants/.

Just as a side question, since arch-daemon.service (and thus DAEMONS support) is going away, then new users will need to 'systemctl enable' all the things in the DAEMONS list?

The point of generators is that they're dynamic. You can't rely on something dynamic existing on next boot so units created by a generator are, by design, unable to be enabled. We've amassed a large amount of units in systemd-arch-units, and anything that still needs to be kludged along in lieu of a proper native unit can be created as simply as the generated units in /run/systemd/generator/arch-daemons.target.wants/.

So, to answer your question: no. It won't have to be done because it can't be done. This is part of why arch-daemons needs to go away. Contrary to popular belief, systemd isn't about booting in 6 seconds, but using native unit files instead of wrappers around shell scripts certainly helps. The fact that this was enabled by default means that things just magically work on bootup and no one thinks twice because it just works™. While it is rather convenient, it's stifling to my efforts of integration because we're not seeing native service files created for popular services.

edit: and here's a samba unit file, because I notice that systemd is not able to correctly determine the PID of smbd.

[Unit]
Description=Samba/NetBIOS Services

[Service]
ExecStart=/usr/sbin/smbd -F
ExecStart=/usr/sbin/nmbd -F

[Install]
WantedBy=multi-user.target

Last edited by falconindy (2011-04-23 13:50:28)

Offline

#443 2011-04-23 14:14:19

pankajmore
Member
Registered: 2010-07-06
Posts: 23

Re: systemd: Yet Another Init Replacement

on boot i get this


<30>systemd-fsck[772]: /dev/sda1: clean, 400835/2501856 files, 3939069/10000454 blocks
<30>systemd-fsck[2424]: /dev/sda4: Superblock last write time is in the future.
<30>systemd-fsck[2424]: (by less than a day, probably due to the hardware clock being incorrectly set).  FIXED.
<30>systemd-fsck[2424]: /dev/sda4: clean, 717737/26402816 files, 68396908/105595245 blocks
<30>systemd-fsck[2428]: Reiserfs super block in block 16 on 0x802 of format 3.6 with standard journal
<30>systemd-fsck[2428]: Blocks (total/free): 5000224/1279347 by 4096 bytes
<30>systemd-fsck[2428]: Filesystem is clean



time changes at each boot , any idea how to fix it .... I am using UTC and no windows

Offline

#444 2011-04-23 14:28:46

igndenok
Member
From: Sidoarjo, Indonesia
Registered: 2010-06-07
Posts: 160

Re: systemd: Yet Another Init Replacement

According to systemctl man

poweroff
    Shut down and power-off the system. This is mostly equivalent to start poweroff.target but also prints a wall message to all users.
    If combined with --force shutdown of all running services is skipped, however all processes are killed and
    all file systems are unmounted or mounted read-only, immediately followed by the powering off.

If I using 'systemctl poweroff' my system on immediately a few ms after off, but not with 'systemctl start poweroff.target'.
Is that by design or what ?!


Ask, and it shall be given you.
Seek, and ye shall find.
Knock, and it shall be opened unto you.

Offline

#445 2011-04-23 14:32:11

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

Re: systemd: Yet Another Init Replacement

You generally don't want to 'start' targets, you isolate them.

Offline

#446 2011-04-23 15:32:28

igndenok
Member
From: Sidoarjo, Indonesia
Registered: 2010-06-07
Posts: 160

Re: systemd: Yet Another Init Replacement

Ah, I see. My bad for not read man further, and just a while ago I got error because it couldn't detect vfat filesystem.
After reboot it, the error was gone hmm


Ask, and it shall be given you.
Seek, and ye shall find.
Knock, and it shall be opened unto you.

Offline

#447 2011-04-24 09:07:36

lymphatik
Member
From: Somewhere else
Registered: 2009-03-07
Posts: 119

Re: systemd: Yet Another Init Replacement

I tried this for laptop-mode service but it seems that it does not stay active. Should I add something like this RemainAfterExit=yes

[Unit]
Description=Laptop power saving package
After=syslog.target acpid.service
Wants=acpid.service

[Service]
ExecStart=/usr/sbin/laptop_mode auto
ExecStop=/usr/sbin/laptop_mode stop

[Install]
WantedBy=multi-user.target

And I tried the code from gentoo for lighttpd and it seems to work flawlessly

[Unit]
Description=Lighttpd Daemon
After=network.target

[Service]
ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf
ExecStart=/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

/etc/tmpfiles.d/lighttpd.conf

d /var/run/lighttpd 0750 http http -

http://en.gentoo-wiki.com/wiki/Systemd

Last edited by lymphatik (2011-04-24 09:35:29)

Offline

#448 2011-04-24 09:48:26

unikum
Member
From: Russia
Registered: 2010-09-04
Posts: 151
Website

Re: systemd: Yet Another Init Replacement

/usr/sbin/laptop_mode not contain 'stop' option. See man page.

Last edited by unikum (2011-04-24 09:50:00)

Offline

#449 2011-04-24 10:27:33

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

Re: systemd: Yet Another Init Replacement

lymphatik wrote:

I tried this for laptop-mode service but it seems that it does not stay active. Should I add something like this RemainAfterExit=yes

[Unit]
Description=Laptop power saving package
After=syslog.target acpid.service
Wants=acpid.service

[Service]
ExecStart=/usr/sbin/laptop_mode auto
ExecStop=/usr/sbin/laptop_mode stop

[Install]
WantedBy=multi-user.target

I did something similar, but used the scripts in /etc/rc.d/ instead (Yeah, I'm terribly lazy sometimes), and I don't have a daemon running either. I think it simply doesn't have a daemon, that it just sets the values from the config file to something in the kernel. Maybe.

Offline

#450 2011-04-24 13:28:18

lymphatik
Member
From: Somewhere else
Registered: 2009-03-07
Posts: 119

Re: systemd: Yet Another Init Replacement

Well from the rc.d

[ ! -d /var/run/laptop-mode-tools ] && install -d /var/run/laptop-mode-tools
    touch /var/run/laptop-mode-tools/enabled
    /usr/sbin/laptop_mode auto >/dev/null 2>&1

It seems you have to create a directory and file to activate it. But I have no idea how to do that for the moment. Maybe with tmpfile.d. Will and comeback to you if I find something interesting.

Edit
/etc/tmpfiles.d/laptop-mode.conf

d /var/run/laptop-mode-tools 0755 root root
f /var/run/laptop-mode-tools/enabled 0644 root root

But this actually activate laptop-mode all the time you cannot stop it. I have not found yet how to delete files when a execstop is launched.

Last edited by lymphatik (2011-04-24 13:55:51)

Offline

Board footer

Powered by FluxBB