[EN] Survey on systemd Who uses it?

[dibl]

Today I discovered that when you use:

Code: [Select]

systemctl isolate multi-user.target it also kills the ssh service

This was only half-correct.  It actually kills networking.

Default installation does not create a runlevel3.target.

[ralul]

@dibl, you should link in what you need, on my Gentoo:

Code: [Select]

# ls -ll /etc/systemd/system/multi-user.target.wants/
insgesamt 0
lrwxrwxrwx 1 root root 35  6. Nov 2012  cups.path -> /usr/lib64/systemd/system/cups.path
lrwxrwxrwx 1 root root 38 25. Aug 2012  dhcpcd.service -> /usr/lib/systemd/system/dhcpcd.service
lrwxrwxrwx 1 root root 41  3. May 11:47 local-d-start.service -> /etc/systemd/system/local-d-start.service
lrwxrwxrwx 1 root root 40  4. Jun 17:44 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target
lrwxrwxrwx 1 root root 47 25. Aug 2012  wpa_supplicant@wlan0.service -> /usr/lib/systemd/system/wpa_supplicant@.service

[michaa7]

...

This was only half-correct.  It actually kills networking.
...

Hmm, but maybe that's a bug, because from what I read in the net,
https://bugzilla.redhat.com/show_bug.cgi?id=743603
 multi-user.target should have network enabled!

[dibl]

@dibl, you should link in what you need

Yep, now trying this:

Code: [Select]

root@imerabox:/etc/systemd/system/multi-user.target.wants# ln -s /lib/systemd/system/runlevel3.target runlevel3.target


EDIT:  Nope -- no help there.

[ralul]

Isn't
runlevel3.target
just another name for
multi-user.target
in sysvinit-compatible mode?

I hope you will not get a circular dependency issue, because it might be an internal special name (synonym) for systemd.

[edit]I just found on Gentoo with systemd-204:
man systemd.special

Code: [Select]

runlevel2.target, runlevel3.target, runlevel4.target, runlevel5.target
           These are targets that are called whenever the SysV compatibility code asks for runlevel 2, 3, 4, 5,
           respectively. It is a good idea to make this an alias for (i.e. symlink to) multi-user.target (for runlevel
           2) or graphical.target (the others)

By the way:
When dist-upgrading Debian-Sid it is not needed anymore to stop the X session, but safer. You can just stop your personal session and change via Ctrl+Alt+F3 to a non X console to do your DU as root.
Years ago an upgrade of dbus would have had an automatic restart of dbus and dependend services, which would have resulted in your session to stop and your root Konsole (doing DU) to also break/crash working. But I buged maintainers to stop that kind of nonsense.

[dibl]

I would think the multi-user.target would have the networking service.  But under /lib/systemd/system there is no network.service, only network.target.

Perhaps it is sufficient to stop the Display Manager (kdm, gdm, lightdm, slim, etc.) for the d-u.  That will shut down the gui, and then you can work at the tty console, as you say.

[DeepDayze]

Today I found a PEBKAC error was causing part of my issues -- on one laptop and the netbook which have SSDs, I had previously mounted /var/log on a tmpfs, so of course it was not possible for anything to be persistent including the systemd journal. (headslap here)  By changing that setup, and then making the /var/log/journal directory, and the next item below, they're working correctly.

Then make the directory for /var/log/journal as devil says, and after reboot it is working correctly on the Dell laptop I posted above and my other computers.  With these two things corrected, it looks like I can set the journal to be persistent at /var/log/journal on all my systems, so that's a closed issue.

HOWEVER, I believe we still need to develop correct guidance for taking the system to the level formerly known as "init 3" (no X server running) for d-u.  Today I discovered that when you use:

Code: [Select]

systemctl isolate multiuser.target it also kills the ssh service, so that is no good for remote administration. I'll have to wait for one more knowledgeable to figure out a correct procedure for d-u on a systemd system.

Should that directory actually be created by systemd already? if not hopefully that a future systemd package can set it all up properly or maybe tune settings at package install time via debconf

It would also be nice if there were some scripts included that can mimic the SysV runlevels for systemd and these can help people used to the sysv way of doing things with inits.



More good info for a wiki entry on systemd

[DeepDayze]

I would think the multi-user.target would have the networking service.  But under /lib/systemd/system there is no network.service, only network.target.

Perhaps it is sufficient to stop the Display Manager (kdm, gdm, lightdm, slim, etc.) for the d-u.  That will shut down the gui, and then you can work at the tty console, as you say.

That should be safe enough to allow a d-u without causing any issues. Perhaps rebooting the system after a d-u that makes updates to core system packages is advisable

[michaa7]

Only a sidenote to the survey:

According to
apt-cache rdepends kdm
apt-cache rdepends xserver-xorg
there is no dependency between the two packages.

So I'm not sure if stopping kdm really gets us the level of safety which we achive by switching to RL3 during d-u.

[DeepDayze]

Only a sidenote to the survey:

According to
apt-cache rdepends kdm
apt-cache rdepends xserver-xorg
there is no dependency between the two packages.

So I'm not sure if stopping kdm really gets us the level of safety which we achive by switching to RL3 during d-u.

Isn't it safe when kdm AND Xorg completely shut down?

[dibl]

Isn't it safe when kdm AND Xorg completely shut down?

Right -- but what is that command, after systemd is installed?

[dibl]

So I'm not sure if stopping kdm really gets us the level of safety which we achive by switching to RL3 during d-u.

Today I made a little investigation about this, on my LXDE netbook and also on my KDE desktop.  You guys can try it and see if it is the same for your systems.

When you are logged in to the GUI as a user on TTY7, open a terminal and run

Code: [Select]

px aux | most

When you scroll down the list, at a point you find a section that looks like this:

Code: [Select]

root     27343  0.0  0.0  26808   780 ?        Ss   07:43   0:00 /usr/bin/kdm
.
.
.
root     27346  0.0  1.5 207128 91716 tty7     Ss+  07:43   0:07 /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-t1v2
root     27364  0.0  0.0      0     0 ?        S    07:43   0:00 [kworker/2:1]
root     27366  0.0  0.0  24344  1448 ?        S    07:43   0:00 /sbin/udevd
root     27367  0.0  0.0  24344  1444 ?        S    07:43   0:00 /sbin/udevd
root     27373  0.0  0.0  75268  2460 ?        S    07:43   0:00 -:0        
root     27489  0.0  0.0      0     0 ?        S    08:59   0:00 [kworker/1:1]
root     27535  0.0  0.0      0     0 ?        S    09:59   0:00 [flush-8:0]
root     27561  0.0  0.0      0     0 ?        S    10:27   0:00 [kworker/0:0]
root     27569  0.0  0.0      0     0 ?        S    10:35   0:00 [kworker/0:2]
don      27580  0.0  0.0   4324   696 ?        Ss   10:38   0:00 /bin/sh /usr/bin/startkde
don      27626  0.0  0.0  12592   336 ?        Ss   10:38   0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/
don      27629  0.0  0.0  24468   880 ?        S    10:38   0:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
don      27630  1.2  0.0  35228  3128 ?        Ss   10:38   0:01 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --ses
don      27670  0.0  0.0   4088    88 ?        S    10:38   0:00 /usr/lib/kde4/libexec/start_kdeinit +kcminit_startup
don      27671  0.1  0.7 367672 46348 ?        Ss   10:38   0:00 kdeinit4: kdeinit4 Running...                  
don      27672  0.0  0.4 373980 24608 ?        S    10:38   0:00 kdeinit4: klauncher [kdeinit] --fd=9          
don      27674  0.4  0.7 1417788 48716 ?       Sl   10:38   0:00 kdeinit4: kded4 [kdeinit]                      
don      27690  0.1  0.2 285160 17080 ?        S    10:38   0:00 /usr/bin/kglobalaccel
.
.
.

Now go to the console on tty1, log in as root, and issue:

Code: [Select]

service kdm stop

(or slim, gdm, lightdm, or whatever your DM is) and then run the same list of processes.  On the two systems I looked at, all of the user processes were killed, as well as the X-related root processes including /usr/bin/X on tty7.

So it looks safe to me to run d-u after the DM is stopped.  Right?

Of course if a new version of a video driver (or other hardware driver) is installed, we will still need to either unload/reload the applicable kernel module or reboot to run the new module.

[michaa7]

...You guys can try it and see if it is the same for your systems.

As I am still reluctent enough to not enable systemd I can't, but ...

...open a terminal and run

Code: [Select]

px aux | most

I assume you meant ps, not px?

I then tried it like this:

Code: [Select]

ps aux | egrep "kdm|X"

which avoids searching and scrolling.
Intrestingliny here kdm is owned by root not theuser, probably due to me using fluxbox as DE.

Then I switched to tty1 (but still init 5), issued "etc/init.d/kdm stop" and

Code: [Select]

ps aux | egrep "kdm|X" didn't show a running X. This indicates, while no package dependencies exist between kdm and x-server-org, that kdm is *configured* to start and stop X.
Acctually "etc/init.d/kdm start" brought back the kdm login screen (where I login to fluxbox, don't like slim a.o.).

So my warning some posting above seems unneccessary as we may assume that systemd does not change this behaviour.

[dibl]

I assume you meant ps, not px?

Ooops -- the old eyes are easily fooled by small text!

Interestingly here kdm is owned by root not theuser ...

No, KDM or the other DMs are root processes, because no one has logged into the system when they are launched.  Apparently the X server process is a child of the DM, and the KDE user processes are all children of that one. Or something like that ... I'm way over my head on this stuff.

[michaa7]

Interestingly here kdm is owned by root not theuser ...

No, KDM or the other DMs are root processes,..

You are right. Don't know how I came to an other idea ...