Problems with XDM and systemd

English Install/Boot/Login
#1

As (I think) has been noted in these forums, xdm on OpenSuse 12.2 (64-bit) doesn’t restart when you logout. The only way to get it restarted is to switch to vt1, login, and then rcxdm.

I thought that was a bit of a pain, and took this as a challenge to learn about systemd. Unfortunately, at the moment, although I’ve learned a lot, systemd is winning, so thought I’d see if anyone on the forums has sorted it out.

systemd seemed like a great remedy for the xdm issue, since it can restart a service when it exits. And, indeed, when I switch to using systemd, if I logout, xdm is restarted, which is great. I thought I had it beat! Unfortunately, when the system is rebooted, xdm fails to start. It looks like the X server, which is started by xdm, fails to start with ‘no screens found’.

I started with the xdm.service file from openSUSE Lizards, and here’s where I am now:

[Unit]
Description=XDM Display Manager
After=console-kit-daemon.service systemd-user-sessions.service

[Service]
Type=simple
EnvironmentFile=/etc/sysconfig/displaymanager
EnvironmentFile=/etc/sysconfig/language
EnvironmentFile=/etc/sysconfig/windowmanager
PIDFile=/var/run/xdm.pid
ExecStartPre=/bin/rm -f /var/run/xdm.pid
ExecStartPre=/etc/X11/xdm/TakeDevices
ExecStart=/usr/bin/xdm -nodaemon -config /etc/X11/xdm/xdm-config
Restart=always

[Install]
WantedBy=graphical.target

Has anyone sorted out how to make this work?

Thanks

#2

xdm is not a native systemd service. It is redirected to the initd script. The issue you’re having is not related to systemd nor xdm. As you noticed, it is an X problem. Most likely something is wrong in your X configuration. It could be a wrong BusID or a wrong driver in the Device section of your /etc/X11/xorg.conf, or a syntax error in this file.

Try to start in runlevel 3, login as root and run xdm from console. What error message do you get?

#3

Also notice that xdm is buggy under 12.2. The login screen doesn’t come back when you log out. You have to kill and restart xdm. It makes xdm quite inoperative for local sessions, although it’s OK for remote logins.

https://bugzilla.novell.com/show_bug.cgi?id=780130

#4

Correct. That’s why I went down the path of using systemd in the first place, as I mentioned. I don’t think it’s a bug in xdm, rather it’s in one of the myriad scripts that wrap around it, but I have no interest in debugging those.

#5

(For some reason I’ve posted the gist of this message several times lately … odd that it, topically, keeps coming up … but anyway lol!..): You have it backwards there – X starts, then the DM, which in turn launches a DE session on the server … No X, no DM, no desktop

#6

If I use /etc/init.d/xdm to start xdm, all works fine (except for the xdm not restarting on logout), so I don’t think i have a basic X configuration problem. My guess is that there’s an issue with xdm starting from systemd, but I can’t figure it out. Thought perhaps someone here might have gone through this.

#7

You might be correct that X starts, then the DM, but here are some things that I found in wandering through the X11 startup:

/etc/init.d/xdm is the only startup script/function/service that starts any X11 components
/etc/sysconfig/displaymanager has the following section in it

Let the displaymanager start a local Xserver.

Set to “no” for remote-access only.

Set to “no” on architectures without any Xserver (e.g. s390/s390x).

DISPLAYMANAGER_STARTS_XSERVER=“yes”

Finally, /etc/X11/xdm/Xservers lists the X servers that xdm is to start.

Given the above, I believe the sequence is that when xdm starts, one of the first things that it does is start the local X server. For some reason, that is failing when I use systemd with the xdm.service script that I posted above.

If you can enlighten me as to the configuration files that actually start the X Server before xdm starts, I would be most appreciative of the pointers, as it could help me figure out what’s not working right with systemd starting xdm.

Thanks

#8

OK. No, you don’t. That was my question. But you also confirm that xdm doesn’t restart on logout. Feel free to add a comment to the bug report, which hasn’t received any attention since it was issued in september (and already got 1 duplicate in the meantime).

Maybe. I can not tell since I never boot directly in graphical mode. But even if it would work in systemd, it wouldn’t be very useful until the bug is fixed since we established that it doesn’t restore the login screen. xdm is still running though. If you enable xdmcp, you can log in remotely as many times as you like.

#9

Actually, As I mentioned way back in the base posting, using xdm with systemd DOES resolve the xdm not starting issue. Of course, since it can’t start xdm at boot time, it only works if you switch from using /etc/init.d/xdm to using systemd to control xdm after the system is up and running. I don’t know enough about systemd yet to know whether you can have a service that’s on, but not started at boot time.

#10

No, I am wrong … I’ve gotten ahead of myself and tripped up. What you mentioned is correct.

Where I was aiming is the fact that the graphical part of the DM can not startup without X.

xdm fails to start. It looks like the X server, which is started by xdm, fails to start with ‘no screens found’.
…
I don’t think i have a basic X configuration problem. My guess is that there’s an issue with xdm starting from systemd, but I can’t figure it out.
…
xdm starts, one of the first things that it does is start the local X server. For some reason, that is failing when I use systemd with the xdm.service script that I posted above.
Actually, chances are that it is a basic x configuration issue.

re: no screens found … from where did you read this … if you read it from the DM’s log, check the xorg log instead … a few lines above the line in the xorg log which says that “no screen is found”, you will likely find the explaination as to why that comes about. Are you using an xorg configuration file? What driver ? Have you used nomodeset?

#11

Those services are redirected to their init.d srcipt. xdm is not the only non systemd native service.

# systemctl enable xdm.service
xdm.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig xdm on

# systemctl disable xdm.service
xdm.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig xdm off
#12

Please @bls, I try to read this thread. Can you please use CODE tags around your copied/pasted computer text in the future? Use the # button in the toolbar.

#13

I understand that. Using the systemd script/service that I included in the base note, I disabled using /etc/init.d/xdm and had systemd use the xdm.service file. I verified that this worked correctly.

I must not be explaining something correctly. Can you please review the base note again and let me know where I’ve not been clear?

#14

Henk, thanks for pointing that out. The only code in the base note is the systemd script for xdm.service as follows:


[Unit]
Description=XDM Display Manager
After=console-kit-daemon.service systemd-user-sessions.service


[Service]
Type=simple
EnvironmentFile=/etc/sysconfig/displaymanager
EnvironmentFile=/etc/sysconfig/language
EnvironmentFile=/etc/sysconfig/windowmanager
PIDFile=/var/run/xdm.pid
ExecStartPre=/bin/rm -f /var/run/xdm.pid
ExecStartPre=/etc/X11/xdm/TakeDevices
ExecStart=/usr/bin/xdm -nodaemon -config /etc/X11/xdm/xdm-config
Restart=always


[Install]
WantedBy=graphical.target

Hope this helps clarify

#15

Indeed, its not clear from your description. Start from the top.

  • What desktop environment are you using ?

  • Where is the actual problem occurring … When can you or are you actually able to boot into the desktop … and then how do you invoke the problem ?

  • Are you sure you are using XDM as the DM? As opposed to, say KDM, which does leverage/draws upon some of the XDM scripts

  • What about the questions I asked previously (xorg, boot options)?

#16

OK, since I seem to have missed some details that you’re looking for, let me try again. Core i7-something, did a clean install of OpenSuSE 12.2 onto a fresh hard drive. Selected minimal X config, which gets me xdm and twm. I changed the window manager to icewm in /etc/sysconfig/displaymanager. The graphics adapter is some EVGA GeForce 9500 GT device. Kind of low end, but the system is primarily a server, so I don’t worry about the graphics performance too much.

This all works fine. The system boots, xdm comes up, I can login, icewm comes up, and I’m happy.

Well, except that if I logout, xdm doesn’t restart. In order to make that happen, I need to CTRL-ALT-F1, log in on a character cell session, and ‘rcxdm start’. This was noted previously in the thread as a problem with xdm on 12.2.

After I got 12.2 stabilized on my system, I noticed that systemd has the capability to restart services automatically. I thought that perhaps getting xdm running under systemd might solve the aforementioned problem of xdm not restarting after a logout.

So, I put a /lib/systemd/system/xdm.service file together. It currently contains:

Type=simpleEnvironmentFile=/etc/sysconfig/displaymanager
EnvironmentFile=/etc/sysconfig/language
EnvironmentFile=/etc/sysconfig/windowmanager
PIDFile=/var/run/xdm.pid
ExecStartPre=/bin/rm -f /var/run/xdm.pid
ExecStartPre=/etc/X11/xdm/TakeDevices
ExecStart=/usr/bin/xdm -nodaemon -config /etc/X11/xdm/xdm-config
Restart=always


[Install]
WantedBy=graphical.target

If I am logged in, and switch the system from using /etc/init.d/xdm to using /lib/systemd/system/xdm.service (which I do by putting the xdm.service file into the /lib/systemd/system directory and doing a systemctl disable command, followed by a systemctl enable command, and verifying via systemctl status that xdm is now configured to use the xdm.service file), everything works fine, as long as I don’t restart the system. If I logout, xdm restarts, as it should, so this verifies that the system is now using the xdm.service file.

However, if I restart the system (shutdown -r now) with this configuration, xdm does not start. /var/log/xdm.errors has “Fatal server error: no screens found”.

Also, Xorg.0.log has errors in it. In rewriting this note, I booted the system first with xdm.service enabled, and then with /etc/init.d/xdm enabled. The error in the failing log (using xdm.service) that seems to be the start of the problem is this (drmGetBusid fails, but works fine in the second case below using /etc/init.d/xdm):

   103.855] drmOpenDevice: node name is /dev/dri/card0
   103.855] drmOpenDevice: open result is 8, (OK)
   103.855] drmOpenByBusid: Searching for BusID pci:0000:02:00.0
   103.855] drmOpenDevice: node name is /dev/dri/card0
   103.855] drmOpenDevice: open result is 8, (OK)
   103.855] drmOpenByBusid: drmOpenMinor returns 8
   103.855] drmOpenByBusid: Interface 1.4 failed, trying 1.1
   103.855] drmOpenByBusid: drmGetBusid reports 
   103.855] drmOpenDevice: node name is /dev/dri/card1
   103.859] drmOpenByBusid: drmOpenMinor returns -1

In the successful case, using /etc/init.d/xdm, the log looks like:

    16.346] drmOpenDevice: node name is /dev/dri/card0
    16.346] drmOpenDevice: open result is 8, (OK)
    16.346] drmOpenByBusid: Searching for BusID pci:0000:02:00.0
    16.346] drmOpenDevice: node name is /dev/dri/card0
    16.346] drmOpenDevice: open result is 8, (OK)
    16.346] drmOpenByBusid: drmOpenMinor returns 8
    16.346] drmOpenByBusid: drmGetBusid reports pci:0000:02:00.0
    16.346] (II) [drm] nouveau interface version: 1.0.0

So, for some reason, when using xdm.service with systemd, the device is not being found correctly by the X server.

Hopefully this clarifies the scenario and the failure that I’m seeing.

Thanks

#17

Yes.

OK. You tried. to solve this bug by writing you own xdm.service, and it didn’t help. But actually, xdm is not dead when you log out. As I said, you can still log in remotely (I tried). It just doesn’t restore the local login screen. It probably doesn’t reset the console correctly. So restarting the service will not work since xdm is still running, but you might be able to succeed after all if you kill xdm first in your service.

#18

But you know, if people don’t add comments to the bug report, they’re not going to fix it. It seems that this bug report needs to be reassigned anyway.

#19

The problem is not xdm and systemd. The problem is xdm alone bot neing able to reset the console and restore the local login screen on the server where it has been started.

#20

Yes, good write up.

/var/log/xdm.errors has “Fatal server error: no screens found”.
…
Also, Xorg.0.log has errors in it. …The error in the failing log (using xdm.service) that seems to be the start of the problem is this (drmGetBusid fails…

   103.855] drmOpenDevice: node name is /dev/dri/card0
   103.855] drmOpenDevice: open result is 8, (OK)
   103.855] drmOpenByBusid: Searching for BusID pci:0000:02:00.0
   103.855] drmOpenDevice: node name is /dev/dri/card0
   103.855] drmOpenDevice: open result is 8, (OK)
   103.855] drmOpenByBusid: drmOpenMinor returns 8
   103.855] drmOpenByBusid: Interface 1.4 failed, trying 1.1
   103.855] drmOpenByBusid: drmGetBusid reports 
   103.855] drmOpenDevice: node name is /dev/dri/card1
   103.859] drmOpenByBusid: drmOpenMinor returns -1

…
So, for some reason, when using xdm.service with systemd, the device is not being found correctly by the X server.
Not a real surprise to see DRM being a player in this issue … (one of the reasons why I had asked about nomodeset earlier is that typically, in cases when “no screen found” occurs, its the result of a mismatch – a nomodeset boot option being passed when a hard coded (via user supplied xorg conf) DRM/KMS driver is used).

I don’t think that its a case of the graphics adapter device not being found correctly, rather, its a case of it being configured incorrectly … perhaps something in an init script you are overlooking is affecting this.

If you google for “drmOpenByBusid: Interface 1.4 failed” you will see that there are a number of threads for this problem, with varying hardware. There are some that suggest that its mobo chipset issue (Foxconn boards in particular), and a apci problem. Another I glanced at suggests that the plymouth bootsplash is interfering with the DRM/KMS driver. Of course, your issue comes about after you’ve attempted the systemd alterations, but you can, of course, use them as a guide towards what might be the remaining issue causing the misconfiguration.

You might want to see if there is further info being revealed in the boot log (“messages”) that isn’t showing up in the xorg or DM logs. As is, I’m be surprised that the no screens found only shows up in the DM log.

How about a test to see if things work without KMS. i.e. set nomodeset boot option. That should drop the display driver back to the anaemic fbdev or vesa (I forget offhand what nouveau falls back to).

Also, it would be good to see the entire xorg log (use suse paste: SUSE Paste and provide us a link) … both for the original faulty case and for a test of things with the nomodeset option used.