strace shows it stuck at ppoll(fd;3, poll in) where 3 is some socket in the 70,000 range per /proc/[pid]/fd/3
It seems to effectively achieve init 3, but it never returns to the console without Ctrl+C.
I don’t know how to figure out what the socket represents to debug any further, or where that’s actually occurring in source code. I think something about systemctl in systemd possibly.
Okay, this seems really ugly.
log into gui, then log out
ctrl + alt + F1 to console
log in as root
init 3, hangs
ctrl + c
init 5 and GUI comes up (or ctrl + alt F7 to get there)
type password press enter
“Could not sync envirnonment to dbus.”
Nothing works, cannot ctrl alt F1
ssh from other machine and init 3
drops machine back to root’s console
password is on the screen in plain text, the gui wasn’t getting keyboard input, the hidden root session was!
That’s very bad.
A bug report might be in order.
I just tried this.
CTRL-ALT-F1 : okay, and logged in as root.
telinit 3 : hung, until I used ^C
telinit 5 : seemed okay. The GUI started without a problem.
Repeated, same sequence.
I was use “lightdm” during this test. It might be diffferent with “gdm”, because “gdm” runs under “wayland” (if the needed wayland packages are installed).
I’m using the default sddm. I filed a bug report that yast2 doesn’t properly adjust -listen tcp, it was closed with “just hand edit sddm.conf” so I don’t feel like filing bug reports with that sort of response.
I’m just an ordinary user. So I can’t explain that.
Generally speaking, bugs are handled well. Occasionally, they are treated as not serious.
A failure of “init 3” to return is likely to be seen as serious. I suggest you give it a try. And post the bug number here. Then I can confirm it, based on my testing.
I should have added that CTRL-ALT-Backspace failed to kill the GUI session. I’m not sure if that is an intended change.
I ran into the same problem: “init 3 never completes”.
VERSION_ID=“20180121”
Hi
Maybe fixed now…?
init 3
init 5
systemctl isolate multi-user
systemctl isolate graphical
cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20180122 "
Gnome DE, Nvidia 340.106 all working as expected.
Which DM are you using?
On Wed 24 Jan 2018 02:36:02 PM CST, arvidjaar wrote:
malcolmlewis;2852433 Wrote:
> Maybe fixed now…?
Which DM are you using?
Hi
The default with GNOME, gdm
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.3|GNOME 3.20.2|4.4.104-39-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
With 20180122, init 3 still hangs the same way, but ctrl-C then init 5 results in a working X session login now. (Unless I’m somehow doing something slightly different today.) edit: Ah, nope, on the 3rd time, it all wedged up with the same “Could not sync envirnonment to dbus.” at gui login and Ctrl+Alt_F1 not working. Had to reboot over ssh.
I like the new login light bulb logo.
This is systemd bug caused in default installation most likely by btrfsmaintenance-refresh.service. Among other things it does “systemctl enable/disable various.timers”. This implicitly does “systemctl daemon-reload”. Apparently after reload systemd “forgets” to reply to systemctl that initiated switch to run-level 3, and it “hangs” waiting for reply. The switch to run-level 3 itself is completed by systemd.
Note that any other unit that calls daemon-reload would cause the same issue.
You can check whether you have above enabled or not. I can reliably reproduce it with btrfsmaintenance-refresh.service enabled and “workaround” by disabling this service.
Developers are not your subordinates who jump to attention and do what you order. They may have own ideas what their software should (or should not) do. You have either to learn how to convince others or learn to live with the fact that others may have different views.
If filing an obvious bug (yast2 control is misleadingly broken and has no effect) is a waste of their time, then it’s a waste of my time. It cuts both ways. I’m not going to go into sales pitch mode and woo a code owner into taking an interest in properly operating software. I am not on the dev team. I already took time out to report a clearly observable issue. If the devs want configs to be adjusted by hand edits, then that’s the direction openSUSE is headed. Anyway!
Okay, I’ll web search “btrfsmaintenance-refresh.service” and turn that off and test again. Sounds like it won’t affect the login failure / wedge though, we’ll see.
That’s not a bug in YaST.
SDDM just doesn’t respect this particular (open)SUSE-specific setting in /etc/sysconfig/displaymanager, and nobody patched it yet to do that, as I already told you in another thread.
Maybe I will implement it if I find the time and motivation.
Feel free to submit a patch yourself though, openSUSE is a community distribution after all.
PS: OTOH we got quite a few bug reports in the past about KDM not respecting its own settings because it rather used the ones in /etc/sysconfig/displaymanager…
So, in reality, there’s not really a perfect solution possible that fits everybody.
If a user opens YaST, and the default login manager is active, and the user chooses to open TCP ports for X, then yes, YaST should adjust the correct config file to open the TCP ports for X. Why it adjusts an unused config file makes little sense to an end user using a default installation! We’re never going to get wide spread adoption of Linux with tactics like that.
That’s still no bug in YaST.
/etc/sysconfig/ exists for the very reason that YaST can just adjust settings in one single place.
It would be unmanageable to make YaST change config files of every single displaymanager there is…
Why it adjusts an unused config file makes little sense to an end user using a default installation!
Every other display manager/login screen is patched to read this setting from /etc/sysconfig/displaymanager.
Btw, “default installation” is relative.
A default GNOME installation uses gdm e.g.
And SLE doesn’t even come with sddm (nor any KDE software), otherwise SUSE probably would have patched it already.
MFW btrfs messes up a non-btrfs system. >:(
Anyway, I disabled btrfs refresh / balance / scrub [since my system has ext4 exclusively], and indeed “init 3” no longer hangs! rotfl!
For the web searchers:
systemctl disable btrfsmaintenance-refresh.service
systemctl disable btrfs-balance.timer
systemctl disable btrfs-scrub.timer