http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c2 --- Comment #2 from Giacomo Comes --- (In reply to Fabian Vogt from comment #1)

Exit status 6 means that sddm-helper aborted - can you try to get a backtrace and debug log with QT_LOGGING_RULES=*.debug=true?

Can you tell me how to do that? I added the line: Environment=QT_LOGGING_RULES=*.debug=true to /usr/lib/systemd/system/display-manager.service, but the information in the journal did not change: Apr 04 11:33:20 virtual1 sddm-helper[3553]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0) Apr 04 11:33:20 virtual1 sddm[3495]: Greeter session started successfully Apr 04 11:33:20 virtual1 sddm-greeter[3561]: High-DPI autoscaling not Enabled Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/gnome-xorg.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/gnome.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/icewm-session.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/icewm.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/kodi.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/lxde.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/lxqt.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/mwm.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/openbox.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/plasma5.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/twm.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/xsessions/xfce.desktop" Apr 04 11:33:20 virtual1 sddm-greeter[3561]: Reading from "/usr/share/wayland-sessions/plasmawayland.desktop" Apr 04 11:33:27 virtual1 sddm-greeter[3561]: Loading theme configuration from "/usr/share/sddm/themes/breeze-openSUSE/theme.conf" Apr 04 11:33:27 virtual1 systemd[3555]: Started D-Bus User Message Bus. Apr 04 11:33:27 virtual1 sddm-greeter[3561]: Socket error: "QLocalSocket::connectToServer: The socket operation is not supported" Apr 04 11:33:27 virtual1 sddm-greeter[3561]: Cannot connect to the daemon - is it running? Apr 04 11:33:27 virtual1 sddm-greeter[3561]: Could not initialize GLX Apr 04 11:33:27 virtual1 kernel: Core dump to |/usr/lib/systemd/systemd-coredump 3561 173 455 6 1522856007 18446744073709551615 sddm-greeter pipe failed Apr 04 11:33:27 virtual1 sddm-helper[3553]: pam_unix(sddm-greeter:session): session closed for user sddm Apr 04 11:33:27 virtual1 sddm-helper[3553]: [PAM] Closing session Apr 04 11:33:27 virtual1 sddm-helper[3553]: [PAM] Ended. Apr 04 11:33:27 virtual1 sddm[3495]: Auth: sddm-helper exited with 6 Apr 04 11:33:27 virtual1 sddm[3495]: Greeter stopped.

Can you also try to rcxdm restart after the black screen? It might be a race condition on startup.

I have restarted many many times sddm after I found the bug. The login screen never came back (except when I disabled ypbind). It doesn't look like a race condition. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c4 --- Comment #4 from Giacomo Comes --- Created attachment 765994 --> http://bugzilla.opensuse.org/attachment.cgi?id=765994&action=edit requested Xorg log Xorg looks fine to me. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c6 --- Comment #6 from Giacomo Comes --- Created attachment 766011 --> http://bugzilla.opensuse.org/attachment.cgi?id=766011&action=edit new log from tumbleweed running a real PC

[ 14.988] (EE) modeset(0): glamor initialization failed [...] [ 14.994] (II) AIGLX: Screen 0 is not DRI2 capable [ 14.994] (EE) AIGLX: reverting to software rendering

These two error messages are unrelated to the sddm problem. They are due to the fact that I was running the X server in a virtual machine which of course is not capable of DRI. Attached are the Xorg log file and the sddm journal entry of a tumbleweed installation running on a real PC. X does not have errors. The differences for sddm are: ## no NIS, sddm working ## Apr 04 19:40:07 virtual1 sddm-greeter[1949]: Loading theme configuration from "/usr/share/sddm/themes/breeze-openSUSE/theme.conf" Apr 04 19:40:08 virtual1 sddm-greeter[1949]: Connected to the daemon. Apr 04 19:40:08 virtual1 sddm[1829]: Message received from greeter: Connect ## NIS enabled, sddm not working ## Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Loading theme configuration from "/usr/share/sddm/themes/breeze-openSUSE/theme.conf" Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Socket error: "QLocalSocket::connectToServer: The socket operation is not supported" Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Cannot connect to the daemon - is it running? Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Could not initialize GLX Apr 04 19:46:23 virtual1 kernel: Core dump to |/usr/lib/systemd/systemd-coredump 3214 187 467 6 1522885583 18446744073709551615 sddm-greeter pipe failed -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c8 Michal Srb changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(msrb@suse.com) | --- Comment #8 from Michal Srb --- (In reply to Fabian Vogt from comment #7)

...

Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Socket error: "QLocalSocket::connectToServer: The socket operation is not supported" Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Cannot connect to the daemon - is it running? Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Could not initialize GLX Apr 04 19:46:23 virtual1 kernel: Core dump to |/usr/lib/systemd/systemd-coredump 3214 187 467 6 1522885583 18446744073709551615 sddm-greeter pipe failed

This means sddm-greeter aborted because it could not initialize GLX. If GLX worked, it wouldn't crash.

I don't think the GLX initialization fail is the culprit here. It would be strange that GLX would work without NIS and stopped with it. When sddm-greeter prints the message "Cannot connect to the daemon - is it running?" it calls `QCoreApplication::exit`. Unlike the `exit` function from stdlib, this method does return. It only sets some flag that the application's event loop should not run. So even that sddm-greeter is trying to exit, it still proceeds with initialization and also calls `QGuiApplication::exec()`. Then Qt tries to initialize GLX, but it fails because it did not receive any usable configs. My guess is that it did not receive them because it was in the exiting state. So I think the GLX message is only falloff from sddm-greeter exiting. The main cause is that it failed to talk to sddm. Maybe sddm is busy/frozen/broken because of the NIS? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c10 --- Comment #10 from Fabian Vogt --- (In reply to Michal Srb from comment #8)

(In reply to Fabian Vogt from comment #7)

...

...

Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Socket error: "QLocalSocket::connectToServer: The socket operation is not supported" Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Cannot connect to the daemon - is it running? Apr 04 19:46:23 virtual1 sddm-greeter[3214]: Could not initialize GLX Apr 04 19:46:23 virtual1 kernel: Core dump to |/usr/lib/systemd/systemd-coredump 3214 187 467 6 1522885583 18446744073709551615 sddm-greeter pipe failed

This means sddm-greeter aborted because it could not initialize GLX. If GLX worked, it wouldn't crash.

I don't think the GLX initialization fail is the culprit here. It would be strange that GLX would work without NIS and stopped with it.

It's also strange that sddm-greeter is unable to create a socket...

When sddm-greeter prints the message "Cannot connect to the daemon - is it running?" it calls `QCoreApplication::exit`. Unlike the `exit` function from stdlib, this method does return. It only sets some flag that the application's event loop should not run.

So even that sddm-greeter is trying to exit, it still proceeds with initialization and also calls `QGuiApplication::exec()`. Then Qt tries to initialize GLX, but it fails because it did not receive any usable configs. My guess is that it did not receive them because it was in the exiting state.

Yes, this is a bug, but GLX initialization should still succeed after that. I verified that on several systems. (In reply to Michal Srb from comment #9)

(In reply to Giacomo Comes from comment #2)

...

Apr 04 11:33:27 virtual1 sddm-greeter[3561]: Socket error: "QLocalSocket::connectToServer: The socket operation is not supported"

If I am reading the Qt code correctly, in this situation it can happen only if a call to `socket(PF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0)` returned -1. This could happen for various reasons, for example exhausted system resources. (Maybe the NIS client is creating huge amount of sockets?) It would be good to know what was the errno after this call failed.

It's probably the same reason why GLX failed - maybe too many open fds?

Giacomo, could you run sddm in strace? For example after ssh-ing in as root from another machine and running: # systemctl stop display-manager # strace -f -o /tmp/sddm.strace sddm

The please attach the sddm.strace here.

Yes, that would be very useful. Also please provide the output of ps -ef | grep sddm during the black screen. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c12 Giacomo Comes changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(comes@naic.edu) | --- Comment #12 from Giacomo Comes --- Created attachment 766161 --> http://bugzilla.opensuse.org/attachment.cgi?id=766161&action=edit requested strace output of ps -ef | grep sddm: root 9821 2758 2 12:36 pts/0 00:00:06 strace -f -o /tmp/sddm.strace sddm root 9823 9821 0 12:36 pts/0 00:00:00 sddm root 9825 9823 0 12:36 tty7 00:00:00 /usr/bin/X -nolisten tcp -auth /run/sddm/{dfe041fe-1cae-474c-9779-b7dca436464a} -background none -noreset -displayfd 17 -seat seat0 vt7 root 9985 9717 0 12:42 pts/1 00:00:00 grep --color=auto sddm This and the strace is done in a virtual machine. If needed I can also do it on a real PC. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c14 Giacomo Comes changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(comes@naic.edu) | --- Comment #14 from Giacomo Comes --- Yes, that was the issue. Rising the soft nofile limit to 2048 made sddm work again. (the threshold was at about 1310). The question remains about why it is necessary (at least for me) to increase such limit. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c16 --- Comment #16 from Cristian Rodríguez --- (In reply to Fabian Vogt from comment #15)

(In reply to Giacomo Comes from comment #14)

...

Yes, that was the issue. Rising the soft nofile limit to 2048 made sddm work again. (the threshold was at about 1310).

The question remains about why it is necessary (at least for me) to increase such limit.

It appears to me like the NIS user enumeration (or some other part) leaks sockets:

socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 24 [...] (never closed) socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 1000

Reassigning to tirpc bugowner and raising severity to major, as one leaked fd per user (?) can really cause issues.

huh..it also does not set SOCK_CLOEXEC..did you identified which library has this behaviour ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c18 --- Comment #18 from Thorsten Kukuk --- (In reply to Fabian Vogt from comment #17)

No, that it's tirpc is just a first guess, it's the only rpc lib loaded into the process as seen in the trace.

You can easily find out: Install libtirpc from Leap 15.0. If that works and don't show the problems, please try https://build.opensuse.org/package/show/home:kukuk:branches:Base:System/libt... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c21 --- Comment #21 from Giacomo Comes --- (In reply to Thorsten Kukuk from comment #18)

(In reply to Fabian Vogt from comment #17)

...

No, that it's tirpc is just a first guess, it's the only rpc lib loaded into the process as seen in the trace.

You can easily find out: Install libtirpc from Leap 15.0.

after installing libtirpc from Leap 15.0 sddm worked again.

If that works and don't show the problems, please try https://build.opensuse.org/package/show/home:kukuk:branches:Base:System/ libtirpc

I installed https://api.opensuse.org/build/home:kukuk:branches:Base:System/openSUSE_Fact... and sddm stopped working again. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c23 --- Comment #23 from Thorsten Kukuk --- (In reply to Giacomo Comes from comment #21)

after installing libtirpc from Leap 15.0 sddm worked again.

I installed https://api.opensuse.org/build/home:kukuk:branches:Base:System/ openSUSE_Factory/x86_64/libtirpc/libtirpc3-1.0.3-101.1.x86_64.rpm and sddm stopped working again.

Ok, thanks, so the socket leak must be in one of the libtirpc changes, and it is not the bindresvport() replacement. Thomas, the new __try_protocol_version_2 function does not seem to close "client", while the old code did it via the "done" label. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c29 --- Comment #29 from Giacomo Comes --- I have bisected libtirpc and found the commit that introduced the regression: commit 5e7b57bc20bd9cadfffd6de52c3331a926ebdf92 Author: Thomas Blume Date: Wed Mar 14 09:51:51 2018 -0400 rpcinfo: change order of version to be tried to 4, 3, 2 When specifying TCP as transport on rpcinfo getport command (-T tcp), the initial RPC getport packet is still sent as a UDP packet. This is due to rpc protocol version 2 is tried first and function getpmaphandle() states: /* * Try UDP only - there are some portmappers out * there that use UDP only. */ Even on systems with newer rpc versions, this will hang when the UDP port is blocked. That is a quite artifical limitation, because UDP only portmappert should be really rare by now. The attached code changes the order of versions to be tried to 4, then 3 and use version 2 only as fallback. Reviewed-by: Chuck Lever Signed-off-by: Thomas Blume Signed-off-by: Steve Dickson This is the same commit that was reversed in https://api.opensuse.org/build/home:kukuk:branches:Base:System/openSUSE_Fact... Therefore such rpm also fixes the regression. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c33 Giacomo Comes changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(comes@naic.edu) | --- Comment #33 from Giacomo Comes --- We have several master/slave nis servers running redhat 9 and centos 5/6/7 I did a test with all of them and the issue arises when talking to nis running on: redhat 9 and centos 5 (portmapper 4.0) no issue with: centos 6 and centos 7 (rpcbind 0.2.0) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c36 --- Comment #36 from Thomas Blume --- Patch was accepted upstream. Submitting to factory. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1087925 http://bugzilla.opensuse.org/show_bug.cgi?id=1087925#c38 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fabian@ritter-vogt.de --- Comment #38 from Fabian Vogt --- The request got declined but nobody noticed: https://build.opensuse.org/request/show/602530 -- You are receiving this mail because: You are on the CC list for the bug.