Bug 710951

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

is this still an issue?

Still seeing this with systemd-37-7.fc16

Experiencing similar issues with prefdm.service at runlevel 5

Normal boot into runlevel 5 fails to completely start kdm. (vern background only)
A ctl-alt-backspace will restart X server and kdm then runs correctly.

Booting into runlevel 3 and manually starting kdm via systemctl 

> systemctl start prefdm.service

kdm service starts normally

Note: Hardware is Thinkpad T40 with ATI Mobility 7500 Video
      systemd-37-7.fc16

(In reply to comment #4)
> Experiencing similar issues with prefdm.service at runlevel 5

I am not sure your problem is related to what Lukas described. Did you override prefdm.service with your own unit file as he did?

(In reply to comment #5)
> (In reply to comment #4)
> > Experiencing similar issues with prefdm.service at runlevel 5
> 
> I am not sure your problem is related to what Lukas described. Did you override
> prefdm.service with your own unit file as he did?


Did symlink /lib/systemd/system/prefdm.service to /etc/systemd/sytem/prefdm.service but no joy. Also tried copying file instead of symlink still no joy. This system is a Thinkpad (i686). My other x64 system has no issues. 

Found Bug #741441 after posting my initial comment here. 
Probably a better place for this problem. Could be a hardware (video driver) issue with ATI Mobility 7500. 

Deleted initial comment. Thanks Michal.

Michal perhaps this one can be solved by introducing systemctl copy $unit which copy the unit and all creates the relevant unit symlink(s) in /etc/systemd/system directory? 

I'm pretty sure this is one of those issues that users will constantly forget...

By the way why did we create display-manager.service symlink instead of just using prefdm.service directly ?

prefdm.service refers to the specific prefdm script that starts various DMs.

display-manager.service is the generic functionality it provides. In the future, display-manager.service might link to a specific gdm.service, or kdm.service, and so on. (That was the idea, at least.)

(In reply to comment #9)
> prefdm.service refers to the specific prefdm script that starts various DMs.
> 
> display-manager.service is the generic functionality it provides. In the
> future, display-manager.service might link to a specific gdm.service, or
> kdm.service, and so on. (That was the idea, at least.)

Hmm this sounds to me like display-manager.service should really should have been an display-manager.target and the relevant *dm.service ( kdm gdm lxdm xdm etc.. ) should have it in their [Install] section.

Is this something we ought to change and are you aware of an issues that might happen if we make this change?

Not sure if a target is really useful; there should only be a single
display-manager.service be enabled at a time, not a bunch of them.

(In reply to comment #11)
> Not sure if a target is really useful; there should only be a single
> display-manager.service be enabled at a time, not a bunch of them.

Well target makes more sense even if it is just for one service then an symbolic link does at least to me. 

An target unit that contained all the common bits ( conflicts after and before orderings etc ) that all of the *dm service files would have and then a slim dm.service file for each dm that would conflict with each other to ensure only one is running at a given time because you might want to have a lot of dm installed ( think for example testing purposes ) but only one enabled. 

Anyway the real problem here is that those symbolic links that get attached to units aren't being move along with them when an user customizes those units by copying them to /etc/systemd/system directory ( or simply stopped from being loaded ) and I think that is something users will always forget to ensure unless we come up with something like systemctl copy <unit> which ensured that all relevant links point the new target ( or makes sure of deleting that symbolic link referring to the unmodified unit )

Another example of where this is an issue ( or an form of the same underlying issue ) is when you point the default.target to another target, all what is still in the default.target.wants directory will still get loaded which leads to users routinely forgetting to empty that directory when doing so.

The way this was suggested to be done is to land the preset support and have each DM just do a preset, and have each desktop spin have its own preset file that defines which one should be active. 

I'm not sure a separate display-manager.target makes sense, since that's what graphical.target already is.

(In reply to comment #13)
> The way this was suggested to be done is to land the preset support and have
> each DM just do a preset, and have each desktop spin have its own preset file
> that defines which one should be active. 

Yeah that feature did not make it into F17 did it.

> I'm not sure a separate display-manager.target makes sense, since that's what
> graphical.target already is.

Cant we then just drop the display-manager.service symlink and add 

[Install]
WantedBy=graphical.target

To the prefdm.service?

No, because that doesn't enforce the only-one semantics.

I'd prefer to just document that if you want to change it, you copy it as display-manager.service and change *that*.

(In reply to comment #15)
> No, because that doesn't enforce the only-one semantics.
> 
> I'd prefer to just document that if you want to change it, you copy it as
> display-manager.service and change *that*.

Added as an NOTE here [1] feel free to review my English and rephrase if necessary.  

1, https://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F

Should we not the just put this matter to rest for now and close this bug?

Notting ping safe to close or should we move this bug against rawhide?

Seems ok to close.