Siduction Forum
Siduction Forum => Software - Support => Topic started by: bluelupo on 2015/11/18, 09:43:50
-
Hi community,
Since a few days you will be automatically logged in a change of the target. Can the behavior of systemd any of you reproduce?
This command I enter on a text console (tty) and then I get logged out:
# systemctl isolate multi-user.target
EDIT: opened bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805442
-
Same behaviour here.
systemd:
Installiert: 227-3
But, I don't understand the problem. Isn't this the expected behaviour?
When I'm logged in on a tty console, I am in the multi-user.target I think? Or am I not?
When I then give the command to isolate this target, shouldn't systemd then logout?
Isolate multi-user.target on graphical surface works and graphical.target on tty also.
greets
ayla
-
Hi,
same behaviour here with systemd version 227-3. But bluelupo is right, this has changed some days (weeks?) ago. Earlier I switched with <ALT><CTRL><F1> to tty1, logged in as root and changed "runlevel" with systemctl iso... multi... and remained logged in on this screen.
Ciao, Martin
-
hi ayla,
I do not believe that this is the expected behavior. If I, for example, from graphical desktop out the CTRL-ALT-F1 press to get to a text console, but am still in graphical.target (formerly init 5). There, for example, want to before a you a change to multi-user.target make (formerly init 3). At this point I'm going to be logged, that is definitely not been the default behavior.
---
In deutsch:
hi ayla,
Ich glaube nicht das dies das erwartete Verhalten ist. Wenn ich z.B. aus grafischen Desktop heraus die Tastenkombination CTRL-ALT-F1 drücke komme ich auf eine Textkonsole, bin aber immer noch im graphical.target (früher init 5). Dort möchte z.B. vor einem d-u einen Wechsel zum multi-user.target machen (früher init 3). An dieser Stelle werde ich jetzt ausgeloggt, das ist definitiv nicht das Standardverhalten gewesen.
-
Could it have to do with security changes regarding X and setuid root, see end of my post?
Expected or earlier behavior:
- a) you start in your desktop environment (running X)
- b) switch with STRG+ALT+F1 to tty 1 (X still runs, test with STRG+ALT+F7 and back)
- c) you want to DU without running X so 'systemctl isolate multi-user.target' stops X on F7),
c1) while you stay logged in on tty1
(c would be the same as if you 'systemctl stop lightdm [or sddm])
Now c1) doesn't really work as expected/earlier... -> throws you out, relogin necessary.
----
System1 with kdenext, sddm as DM, xserver-xorg-core 2:1.17.3-2, xserver-xorg-legacy 2:1.17.3-2, systemd 227-3
Acting like c) does stop X, logs me out of tty1 and gives me re-login prompt on tty1, I can login as root and work on.
After 'systemctl isolate graphical.target' X is started and lets me re-login in sddm.
System1, a) user in X, loginctl list-sessions:
SESSION UID USER SEAT
5 117 sddm seat0
6 1000 martin seat0
2 sessions listed.
System1, b) root in tty1, X still running loginctl list-sessions:
SESSION UID USER SEAT
5 117 sddm seat0
6 1000 martin seat0
7 0 root seat0
3 sessions listed.
System1, c) X stopped, root thrown out and re-logged in loginctl list-sessions:
SESSION UID USER SEAT
8 0 root seat0
1 session listed.
----
System2, no kdenext (stock debian), lightdm as DM, xserver-xorg-core 2:1.17.3-2, no xserver-xorg-legacy, systemd 227-3
Acting like c) does stop X, logs me out of tty1 and gives me re-login prompt on tty1, I can login as root and work on.
After 'systemctl isolate graphical.target' X is started and lets me re-login in lightdm.
System2, a) user in X, loginctl list-sessions:
SESSION UID USER SEAT
1 1000 martin seat0
c1 105 lightdm seat0
2 sessions listed.
System2, b) root in tty1, X running loginctl list-sessions:
SESSION UID USER SEAT
1 1000 martin seat0
2 0 root seat0
c1 105 lightdm seat0
3 sessions listed.
System2, c) X stopped, root thrown out and re-logged in loginctl list-sessions:
SESSION UID USER SEAT
3 0 root seat0
1 session listed.
----
Could it perhaps be a side effect related to changes for xserver, because the topic in irc #debian-next says "Unprivileged Xorg is here! /msg dpkg xorg root" , which gives /msg dpkg xorg root
From Debian 9 "Stretch" onwards (xorg-server 1.17.3-1), the Xorg server is no longer setuid root, reducing the risk of privilege escalation security problems. This relies on logind and libpam-systemd and moves the logs to ~/.local/share/xorg; use the xserver-xorg-legacy package and see Xwrapper.config(5) if you'd rather a setuid root X.
-
You're right bluelupo, as I seldom use CTRL-ALT-F1 I forgot that graphical target is still active.
So, when I'm logged in on tty as root I also see no reason to log out when changing "runlevel". I'm root, so what?
-
Hmm, sure this can't be configured somewhere ? I'm using Fedora 21 since it was released and it showed this (annoying) behaviour from day one.
-
That would probably match my guess, because fedora has non-setuid xorg since 21 ( https://fedoraproject.org/wiki/Changes/NonSetuidXorg ). But still, I dont know enough about the mechanisms behind the correlation behind runlevel-switching and xorg privileges.
-
same behavior here, with the irritating + to switch off eth0 interface >:( (avoided following forum suggestion to stop sddm instead going "init 3")
-
can someone please explain why the so called 'init 3' is still needed?
-
can someone please explain why the so called 'init 3' is still needed?
Shorter than systemctl iso.... or systemctl stop.... ?? ;)
-
@ayla - in general - why? We aren't in the bad old sidux days anymore - and if one has any doubts, ALT-F1 or screen should be sufficient :)
-
In short in Siduction LXQT with lightdm and systemd 227-3 bug 805442 is replicated and a detached session of tmux is also killed. This also kill my network using connman and my openvpn session via the killing of tmux. In an atom netbook also using Siduction LXQT repository but testing under Sparky linux with systemd 227-3 and connman 1.21-1.2 the sddm bug 805442 is not replicated, but network services are killed and error lines displayed after issuing "systemctl isolate multi-user target".
I gave up on systemctl isolate multi-user target in maybe July and went to using systemctl stop lightdm on one system and systemctl stop sddm on another. This stopped a nagging intermittent crashing of connman on wlan0 or eth0 which was restored either by ifup wlan0 or systemctl start connman.service. Sometimes stop connman service was needed first.
This was noted on two machines using Siduction LXQT sources, one siduction and the other an atom netbook with testing - Sparkylinux.
Todays details follow.
On the atom netbook on testing today after using sytemct isolate multi-user did not log me out of the root console on tty1. What it did do was crash the network (wlan0). systemctl start connman and ifup wlan0 did not restore network.
After the command of isolate multi-user target 2 lines were displayed
Policykit daemon disconnected from the bus
We are no longer a registered authentication agent
I rebooted and replicated the same behaviour, unable to apt-get update after systemctl isolate, but was able to prior to issuing the command, However a systemctl stop connman and then a systemctl start connman restored my wlan0.
That would be a bug for me as the first thing I usually do after powering on is start a vpn in a root tty1 via openvpn my...blah.ovpn in tmux and detach and then kill x via stopping lightdm or sddm and thenupdate and dist-upgrade -d in the same tty1 and then restart x.
systemd on testing is systemd 227-2
On a pure siduction LXQT install of siduction the isolate ... command logged out the root tty1 as in bug #805442, the detached tmux session was killed and of course the network went down. The network was resumed via "double-clutching" i,e. systemctl start, then stop, then systemctl start connman. I am holding off on the dist-upgrade to systemd 228-1. connman is 1.30-1 in sid
systemctl stop or start of lighdm or sdd services works flawlessly.
tmux in tty1 being affected via isolate multi-user.target is a bug.
-
Some good reading
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Targets.html
-
Hi,
This behaviour shouldn't be related to the xorg server because if you've already switched to multi-user.target and do again
systemctl isolate multi-user.target you will be logged out again. Ok, its annoying but on the other hand it gives you a clean start.
Ciao, Martin
-
... if you've already switched to multi-user.target and do again ...
horo, that's how powerusers debug their stuff: accidentally repeat the last command from history ... ;)
-
Please don't lapidate me even if I say "init 3"...
I put on my asbestos suit* and did another test: init 3 also drops you to the login each time - even when you're already in "level 3" or "multi-user.target", so I see it as a feature 'til someone from the team contradicts.
Ciao, Martin
* I'm lucky, no other harm occured, neither the hell froze nor little kittens were killed - phew!
-
Current state: Even with the new version of systemd 228-2 has the error not changed.
-
Ihr könnt hier noch ne Weile Handauflegen spielen - wie wäre es, wenn man einfach mal in oftc #debian-systemd fragt und/oder nen Bug malt?
-
... und/oder nen Bug malt?
... EDIT: opened bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805442
---
Edit: question to all posters here: does anybody have a clue with wich version of systemd it worked (or since when exactly it does not)? That would be useful info for the bug report.
-
It looks like the developers have a clue what could have changed and are working on it, from the bug report:
I looked into this a bit further.
Afaics, this is a regression that was introduced in v227 by commit
8c8da0e. Martin reverted that commit in 227-2, so this version is not
affected. In 227-3, that revert was replaced by upstream commit 4178002.
But that commit addressed some of the issues that were introduced by
8c8da0e.
I've forwarded this upstream and marked the bug accordingly.