Problems with XDM and systemd

@Tyler_K: I was NOT using nomodeset, and was using whatever xorg configuration file was dropped into place by the standard configuration that I did. Have not edited the file at all.

That said, I booted the system and added nomodeset to the boot command line, and now xdm starts correctly. And, even better, when I logout of the session, xdm is restarted…the whole goal of this exercise.

I haven’t done any further digging around to see what else might be broken as a result of using nomodeset (although I notice that there are a couple of questionable things in Xorg.0.log), nor have I looked at performance.

Thanks for the nomodeset suggestion.

@please_try_again: I think you’re wrong about xdm being running after you logout. I did not see it in the ps aux list after I logged out, so in my configuration, with VNC disabled, and no other remote graphical login capability enabled, it’s just not running.

Since someone asked about the Xorg.0.logs, here they are.

Xorg.0.log from failing session using xdm started by systemd: SUSE Paste
Xorg.0.log from successful session started using /etc/init.d/xdm: SUSE Paste
Xorg.0.log from successful session using xdm started by systemd with nomodeset: SUSE Paste

Yep, that became clearer from your last post (though, without confirmation, I still wasn’t 100% certain – would have needed wanted to see the full Xorg log) … it was much more unclear from your original postings, where it looked like you may have been using it (either knowingly or unknowingly) – given, as I said, “no screens found” is a typical result of mixing UMS and KMS settings

and was using whatever xorg configuration file was dropped into place by the standard configuration that I did. Have not edited the file at all.
okay,

That said, I booted the system and added nomodeset to the boot command line, and now xdm starts correctly. And, even better, when I logout of the session, xdm is restarted…the whole goal of this exercise.
Excellent.

I haven’t done any further digging around to see what else might be broken as a result of using nomodeset (although I notice that there are a couple of questionable things in Xorg.0.log), nor have I looked at performance.
No doubt the change introduced some of its own problems (most likely not associated with the original problem), but I wouldn’t worry too much about these errors for now – unless you are happy to continue to run in this fashion (more on this in the next sentence), it was just a test case to help narrow down the avenues that need to be investigated in order to get the proper environment running.
Performance will suck because you will now be using just a generic 2D driver that lacks acceleration, let alone zero 3D support. So, expect things to be quite laggy. The OSS drivers (for ati/intel/nvidia) have all gone the KMS route, and the fallback drivers under UMS are either aneamic (FBdev, vesa, nv…) and/or broken/buggy/unmaintained (radeonhd, intellegacy,…) and/or are not applicable in your case anyway.

What you could do, however, is try the prop. nvidia driver, given that it is not a KMS driver. That of course depends upon whether care or not about tainting the kernel, or are more interested in finding a solution via the OSS driver route. If you do opt for the nvidia route, I’d advise doing an image of the drive before hand, as it can be easier to revert back to a “clean” image sometimes then to purge taint from a system.

Thanks for the nomodeset suggestion.
Glad it worked.

@please_try_again: I think you’re wrong about xdm being running after you logout. I did not see it in the ps aux list after I logged out, so in my configuration, with VNC disabled, and no other remote graphical login capability enabled, it’s just not running.
Interesting…In another thread discussing this point, I seem to recall pta provided info showing that it was still running. Anyway, I don’t think that aspect is particularly relevant at the moment in your case. If you wish to pursue the original problem you are encountering furhter, I’d focus in on what is negatively impacting the DRM/KMS driver.

Since someone asked about the Xorg.0.logs, here they are.

Xorg.0.log from failing session using xdm started by systemd: SUSE Paste
Xorg.0.log from successful session started using /etc/init.d/xdm: SUSE Paste
Xorg.0.log from successful session using xdm started by systemd with nomodeset: SUSE Paste
Yep, that was me. I’ll have a look through them later tonight and see if anything further jumps out at me. Though, right now, I suspect that google will be you best friend in helping you get everything straightened out properly.

xdm is running for me after I logged out. I wouldn’t have added a comment to the bug report otherwise.

I don’t know why you’re talking about VNC here. It has nothing to do with VNC. I am able to establish different types of graphical remote connections to this server - on which the xdm login screen didn’t return after the first logout - as you noticed - some of them using and needing xdm + xdmcp, some others not. I never use VNC.

To summarize, I booted in systemd and console mode, as I always do, then started xdm from then command line by typing:

# xdm

I agree, starting the service or running the init script is more elegant, but that’s not the problem here. After logout, the greeter didn’t return locally, but xdm is still alive - and honours remote connection requests.


# ps nc -C xdm
  PID TTY      STAT   TIME COMMAND
12777 tty1     S+     0:00 xdm

I just openend 4 remote connections to this server from 4 different computer in this lan.

# lsx -a

 :1001  ---    26159  agnelo        S            48:40    nxagent (FreeNX)
        =>     26153  agnelo        S            48:40    /bin/bash /usr/bin/nxnode --startsession
        =>     26196  agnelo        S            48:39    ck-launch-session gnome-session --session=cinnamon
        <=     25583  agnelo        Ss           48:44    /bin/bash /usr/bin/nxnode --slave
        <=     25582  agnelo        S            48:44    sshd: agnelo@notty
        <=     25579  root          Ss           48:45    sshd: agnelo [priv]
        <=     25450  root          Ss           48:45    sshd: nx [priv] kamala.niglo.net:47633
               26302  agnelo        Sl           48:39    gnome-session --session=cinnamon
                                              session:    /home/openSUSE/agnelo/.nx/C-jadzia-1001-CED286ECC6F28CC36194F6CE79877E54

 :2008  ---     9213  agnelo        S            16:32    nxagent (**-port 177 -query** jadzia.niglo.net)
        =>      9117  agnelo        Ss           16:35    /usr/NX/bin/nxnode
        =>      9220  agnelo        S            16:32    nxnode     /usr/NX/bin/nxnode
        <=      9117  agnelo        Ss           16:36    /usr/NX/bin/nxnode
        <=      9116  agnelo        S            16:36    sshd: agnelo@notty
        <=      9114  root          Ss           16:36    sshd: agnelo [priv]
        <=      9027  root          Ss           16:40    sshd: nx [priv] neelix.niglo.net:35256
                                              session:    /home/openSUSE/agnelo/.nx/C-jadzia-2008-4E1EFAA65B09ACBD2342E091B22B70BF

 remote ...     9352  agnelo        Ss           16:17    ck-launch-session sawfish
        =>     12777  root          Ss           16:32    -ja       
                9470  agnelo        S            16:17    urxvt -geometry 139x63+0+0 -name MainConsole -tr +sb +tint -fg khaki -fn 9x15 -e bash
                9474  agnelo        S            16:17    sawfish

 remote ...    13541  agnelo        Ss        01:37:41    ck-launch-session icewm-session
        =>     13538  agnelo        S         01:37:41    sshd: agnelo@notty from bareil.niglo.net:48035
               13674  agnelo        SN        01:37:40    icewmbg
               13675  agnelo        S         01:37:40    xpostit -geometry 22x22-190-1
               13676  agnelo        S         01:37:40    urxvt -geometry 154x61+0+0 -name MainConsole -tr +sb +tint -fg khaki -fn neep-14 -e bash
               13680  agnelo        S         01:37:40    icewm-session

 remote ...    **17328**  agnelo        Ss           02:59    ck-launch-session sawfish
        =>     12777  root          Ss           03:07    -ar       
               17458  agnelo        S            02:58    urxvt -geometry 127x51+0+0 -name MainConsole -tr +sb +tint -fg khaki -fn neep-14 -e bash
               17462  agnelo        S            02:58    sawfish


  • The first connection opens an xdm desktop to the Free NX server, but doesn’t require xdm to be running (would also work without xdm). Don’t ask me why! Thus it doesn’t open the xdm login screen but the default window manager.

  • The second connection opens an xdm desktop to the NoMachine NX server and does require xdm to be running. It opens the xdm (remote) greeter - which is actually the same as the local greeter in my case.

  • The third connection is the same as the second one. It shows a sawfish desktop after login in in xdm.

  • The next one is a xephyr connection - tunneling an entire X session over ssh instead of just an application. This one doesn’t require xdm.

  • It’s unclear that the last one is actually a xephyr -query connection, which requires xdm - but it’s clear if you look in the log below.

The lsx script is far to be perfect. Tha’ts why I haven’t released it yet.

Below, xdm error log.

cat /var/log/xdm.errors
xdm info (pid 12777): Starting
xdm info (pid 12777): Starting X server on :0

X.Org X Server 1.12.3
Release Date: 2012-07-09
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux jadzia 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.4.11-2.16-desktop root=UUID=aa192116-690d-4420-af5f-544d1e58b46c video=1600x900 nomodeset resume=/dev/disk/by-uuid/c224505c-6233-404f-a706-308138573fce splash=silent quiet showopts
Build Date: 29 October 2012  06:31:31PM
 
Current version of pixman: 0.24.4
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 22 13:42:33 2012
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
/usr/bin/xrdb:  "XConsole*background" on line 45 overrides entry on line 38
/usr/bin/xrdb:  "XConsole*foreground" on line 46 overrides entry on line 39
xdm info (pid 12783): sourcing /usr/local/config/xdm/Xsetup_0
xdm error (pid 12783): pam_authenticate failure: User not known to the underlying authentication module
xdm info (pid 12783): sourcing /usr/local/config/xdm/Xstartup_0
xdm info (pid 12819): executing session /usr/local/config/xdm/Xsession
xdm info (pid 12783): sourcing /usr/local/config/xdm/Xreset
**xdm error (pid 12777): Unknown session exit code 256 from process 12783**
Server terminated successfully (0). Closing log file.
xdm info (pid 12777): Starting X server on jadzia.niglo.net:2008
0 items in XFree86_VT property!
/usr/bin/xrdb:  "XConsole*background" on line 45 overrides entry on line 38
/usr/bin/xrdb:  "XConsole*foreground" on line 46 overrides entry on line 39
xdm info (pid 9242): sourcing /usr/local/config/xdm/Xsetup
xdm info (pid 9242): sourcing /usr/local/config/xdm/Xstartup
xdm info (pid 9352): executing session /usr/local/config/x11/XremoteSession
xdm info (pid 12777): Starting X server on arpad.niglo.net:1
0 items in XFree86_VT property!
/usr/bin/xrdb:  "XConsole*background" on line 45 overrides entry on line 38
/usr/bin/xrdb:  "XConsole*foreground" on line 46 overrides entry on line 39
xdm info (pid 17214): sourcing /usr/local/config/xdm/Xsetup
xdm info (pid 17214): sourcing /usr/local/config/xdm/Xstartup
xdm info (pid **17328**): executing session /usr/local/config/x11/XremoteSession
xdm info (pid 9242): sourcing /usr/local/config/xdm/Xreset
xdm error (pid 12777): Unknown session exit code 256 from process 9242
xdm info (pid 12777): Starting X server on jadzia.niglo.net:2009
0 items in XFree86_VT property!
/usr/bin/xrdb:  "XConsole*background" on line 45 overrides entry on line 38
/usr/bin/xrdb:  "XConsole*foreground" on line 46 overrides entry on line 39
xdm info (pid 25362): sourcing /usr/local/config/xdm/Xsetup

The error which prevented the local login screen to return is highlighted in red. I don’t know what’s wrong with this Xreset script. It is in another location here, but it’s the same script as the default /etc/X11/xdm/Xreset. It is also the same one as under 12.1, which is NOT affected by this bug. Thus, I don’t know what’s wrong, and when I don’t know how to fix a problem myself, I fill a bug report or add a comment to an existing one, as I did here.

As you can see from the log above, after the error occured, I continued to login remotely to this server over xdmcp, and xdm was still listening and allowing me to connect.

I just hope that this bug - which prevents xdm local login from working more than once - would simply get fixed. It would solve your problem and mine.

Why does this dummy Xreset below:


#!/bin/sh
echo "do nothing"
exit 0

return an unknown exit code:

# cat /var/log/xdm.errors
xdm info (pid 6521): Starting
xdm info (pid 6521): Starting X server on :0

X.Org X Server 1.12.3
Release Date: 2012-07-09
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux jadzia 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.4.11-2.16-desktop root=UUID=aa192116-690d-4420-af5f-544d1e58b46c video=1600x900 nomodeset resume=/dev/disk/by-uuid/c224505c-6233-404f-a706-308138573fce splash=silent quiet showopts
Build Date: 29 October 2012  06:31:31PM
 
Current version of pixman: 0.24.4
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 22 16:08:52 2012
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
/usr/bin/xrdb:  "XConsole*background" on line 45 overrides entry on line 38
/usr/bin/xrdb:  "XConsole*foreground" on line 46 overrides entry on line 39
xdm info (pid 6531): sourcing /usr/local/config/xdm/Xsetup_0
xdm info (pid 6531): sourcing /usr/local/config/xdm/Xstartup_0
xdm info (pid 6594): executing session /usr/local/config/xdm/Xsession
**xdm info (pid 6531): sourcing /usr/local/config/xdm/Xreset
do nothing
xdm error (pid 6521): Unknown session exit code 256 from process 6531**
Server terminated successfully (0). Closing log file.
xdm info (pid 6521): Shutting down
xdm info (pid 6521): Exiting

I think it’s the problem here. If we can answer this question, we can probably fix the bug.

Compare with xdm log on 12.1 - not affected:

starting xdm, login and logout on a 12.1 server:


xdm info (pid 14007): Starting
xdm info (pid 14007): Starting X server on :0

X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux kamala 3.1.10-1.16-desktop #1 SMP PREEMPT Wed Jun 27 05:21:40 UTC 2012 (d016078) x86_64
Kernel command line: root=/dev/disk/by-uuid/fd510cdc-6902-49a6-889d-f72bfaacbfc6 resume=/dev/disk/by-uuid/8ae0e410-f8bc-47ee-a290-f9567f725566 splash=silent quiet vga=0x345
Build Date: 10 November 2011  03:34:36PM
 
Current version of pixman: 0.24.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 22 16:15:32 2012
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE) Logitech Logitech Illuminated Keyboard: failed to initialize for relative axes.
/usr/bin/xrdb:  "XConsole*background" on line 118 overrides entry on line 83
/usr/bin/xrdb:  "XConsole*foreground" on line 119 overrides entry on line 84
xdm info (pid 14018): sourcing /usr/local/config/xdm/Xsetup_0
xdm info (pid 14018): sourcing /usr/local/config/xdm/Xstartup_0
/usr/local/config/xdm/Xstartup_0: line 29: /usr/bin/hal-find-by-property: No such file or directory
xdm info (pid 14056): executing session /usr/local/config/xdm/Xsession
**xdm info (pid 14018): sourcing /usr/local/config/xdm/Xreset
xdm info (pid 14007): Starting X server on :0
**
X.Org X Server 1.10.4
Release Date: 2011-08-19
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux kamala 3.1.10-1.16-desktop #1 SMP PREEMPT Wed Jun 27 05:21:40 UTC 2012 (d016078) x86_64
Kernel command line: root=/dev/disk/by-uuid/fd510cdc-6902-49a6-889d-f72bfaacbfc6 resume=/dev/disk/by-uuid/8ae0e410-f8bc-47ee-a290-f9567f725566 splash=silent quiet vga=0x345
Build Date: 10 November 2011  03:34:36PM
 
Current version of pixman: 0.24.0
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov 22 16:17:28 2012
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE) Logitech Logitech Illuminated Keyboard: failed to initialize for relative axes.
/usr/bin/xrdb:  "XConsole*background" on line 118 overrides entry on line 83
/usr/bin/xrdb:  "XConsole*foreground" on line 119 overrides entry on line 84
xdm info (pid 14427): sourcing /usr/local/config/xdm/Xsetup_0

What? Are we talking about the same bug?

Could it be that the xdm service you wrote provides a hack to this bug, that could not work before because you should have disabled KMS in order to start X?

Recall:

Now turning to:

From that we have:

   103.853] (WW) xf86OpenConsole: setpgid failed: Operation not permitted
   103.853] (WW) xf86OpenConsole: setsid failed: Operation not permitted

Suggestive of Plymouth not releasing the console. See:

   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

.... < cycles repeatedly through /dev/dri/card0-card15> ...  

   103.973] drmGetBusid returned ''
   103.973] (II) [drm] DRM interface version 1.0
   103.973] (EE) [drm] Could not set DRM device bus ID.
   103.973] (EE) NOUVEAU(0): [drm] error opening the drm
   103.973] (EE) NOUVEAU(0): 664: 
   103.973] (II) UnloadModule: "nouveau"
   103.973] (II) UnloadSubModule: "dri"
   103.973] (II) Unloading dri
   103.973] (EE) Screen(s) found, but none have a usable configuration.
   103.973] 
Fatal server error:
   103.973] no screens found

So obviously it is somewhat of a device discovery issue. My thoughts here are that either its acpi related, or if its a case of plymouth (perhaps the systemd plymouth-quit.service), such that the nouveaufb is failing to yeild on the device and that might be interfering with the X recognition of the device somehow. Here is where (as I mentioned previously) also taking a look at your kernel boot message might be revealing of some more information. (and while typing that, I was just thinking that it is too bad there doesn’t exist a better way to review logs for problems like this … a timestamp column and then columns for the boot log, DM log (and associated greeter logs if applicable) and the Xorg log … would make things so much easier to view all the moving parts).

Anyway, a couple of separate simple tests you could run, in no particular order, are (and in all cases remove the nomodeset boot option) are:

  • create a simple xorg.conf or applicable xorg.conf.d/xx- file and pass a device section, wherein you specifically cite your BusID. Example:
Section "Device"
    Identifier  "Card0"
    Driver      "nouveau"
    BusID       "PCI:whateveritis"
EndSection

Use “/sbin/lspci -v |grep VGA” to give you the whateveritis value…careful on any hex to decimal conversions if applicable, but it looks like your case is straight forward: 2:0:0 )

  • disable the plymouth bootsplash and boot without a user supplied xorg config (i.e. remove anything from last test)

  • pass an appropriate acpi boot parm (i.e. pci=noacpi or whatever)…(with plymouth, and without a user supplied Xorg config)

I didn’t read the other logs…Too tired and can’t spend any more time on this…

Why does this dummy Xreset below: …return an unknown exit code:… I think it’s the problem here. If we can answer this question, we can probably fix the bug.

Compare with xdm log on 12.1 - not affected:
All of a sudden I get the sneaky feeling that the further integration of systemd in 12.2 might be at the root of this…

Or lack of thereof :slight_smile:

@Tyler_K: Thanks for having a look at the logs. One thing worth noting is that the setpgid and setsid failures occur in all 3 scenarios, including the original, working scenario using /etc/init.d/xdm. So, I suspect that while this may be a problem, it’s not causing the failure I’m seeing when starting xdm from systemd.

I haven’t yet tried your suggestion of using a simplified xorg.conf, but here are a couple of observations that lead me to believe we may be looking down the wrong path here.

First, in the failing scenario, xdm times out and is restarted over and over (like every 10-15 seconds?). One would think that in this case, it might have more success later in the process.

Secondly, and perhaps more importantly, if I ‘systemctl stop xdm.service’, and then

cd /etc/init.d
./xdm

the “old, original” xdm start script runs, and xdm successfully comes up.

This leads me to the theory that there is something environmental in the way xdm is run from /etc/init.d/xdm vs when systemd starts xdm.service.

Disabling plymouth has no effect on this issue.

Of course, the second line should have been “./xdm start

Fair point! lol!

.Ah, okay. As mentioned last night, I only got to the first one

So, I suspect that while this may be a problem, it’s not causing the failure I’m seeing when starting xdm from systemd.
yep, fair enough assumption

I haven’t yet tried your suggestion of using a simplified xorg.conf, but here are a couple of observations that lead me to believe we may be looking down the wrong path here…
This leads me to the theory that there is something environmental in the way xdm is run from /etc/init.d/xdm vs when systemd starts xdm.service.
Yep, its looking more like that might be the case given your observations

In one of the threads I linked to last night, it talks of a prefdm.service that we don’t have:

# systemctl status prefdm.service
prefdm.service
          Loaded: error (Reason: No such file or directory)
          Active: inactive (dead)

I’m wondering if that is playing a part, or if that is a distro specific thing and not applicable here… again, I’m largely ignorant about systemd, so you likely already know far more about it then me given your investigation into it.

Or maybe the problem is is entirely contained here already, and it will just take shaking out the difference between the init way and what the equivalent requirement for systemd way need be.

Another idea might be to check out Fedora, and see what they are doing, as they are further down the garden path then likely most other distros in terms of the adoption of systemd

Thanks. I’ll take a look at that and update the thread if I find anything useful :wink:

I found a part of the problem: consolekit. I’m not so sure about the bug anymore, because I was still starting the wm with ck-launch-session - which is supposely deprecated - in my Xsession. However, removing ck-launch-session didn’t help. Neither did adding the following in /etc/X11/xdm/xdm-config:

DisplayManager.consoleKit:      false

But starting xdm with the option -noconsolekit solves the local greeter issue. (!)

As for systemd, here’s what ArchLinux does (don’t have a recent Fedora) :

# cat xdm.service 
[Unit]
Description=X-Window Display Manager
After=systemd-user-sessions.service

[Service]
ExecStart=/usr/bin/xdm -nodaemon
Type=notify
NotifyAccess=all

[Install]
Alias=display-manager.service

# cat systemd-user-sessions.service 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Permit User Sessions
Documentation=man:systemd-user-sessions.service(8)
After=remote-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-user-sessions start
ExecStop=/usr/lib/systemd/systemd-user-sessions stop


I installed Fedora 17 and took a look. You are indeed correct that they are much farther along in moving toward systemd. There are only about 3 or 4 files left in /etc/init.d

Of course, in switching over, they have added a boatload of new stuff, so I don’t think I’m going to spend the time to figure out what they’ve done to make things work. Not having xdm restart on logout is an annoyance, but in my use case, nowhere near a major hassle.

BTW, prefdm apparently has something to do with selecting the display manager. I didn’t look at it in any more detail.

I still may sleuth through what the environmental differences are between an /etc/init.d script and a service started by systemd, but I’m pretty much over my time quota on solving this :frowning:

I feel the same way. The -noconsolekit did work once, but then not anymore. I also noticed that xdm is a separate package, while it was included in xorg before. I also spent to much time trying to fix this bug. I wish the xdm maintainers would just take care of that. I can not fix it.

I probably won’t resist recompiling xdm sooner or later … but I have to give up for now.