Bug 710951 - prefdm.service not read from /etc/systemd/system because of display-manager.service symlink
prefdm.service not read from /etc/systemd/system because of display-manager.s...
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2011-06-05 19:29 EDT by Lukas Middendorf
Modified: 2012-06-02 07:17 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-02 07:17:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lukas Middendorf 2011-06-05 19:29:21 EDT
Description of problem:
I tried to place a modified prefdm.service in /etc/systemd/system (removing After=rc-local.service significantly reduces the perceived boot time) but found it being ignored.
It turns out that prefdm.service is originally accessed via the display-manager.service symlink in /lib/systemd/system. When creating a similar symlink in /etc/systemd/system, it works as expected.

Version-Release number of selected component (if applicable):
systemd-26-2.fc15


Steps to Reproduce:
1. place a prefdm.service in /etc/systemd/system
2. run systemctl daemon-reload
  
Actual results:
the unit in /lib/systemd/system is still used

Expected results:
the unit in /etc/systemd/system should be used
Comment 1 Fedora Admin XMLRPC Client 2011-10-20 12:28:02 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 2 Jóhann B. Guðmundsson 2012-01-25 09:12:34 EST
is this still an issue?
Comment 3 Lukas Middendorf 2012-01-25 12:43:47 EST
Still seeing this with systemd-37-7.fc16
Comment 4 Gary Tivey 2012-02-02 02:44:52 EST
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
Comment 5 Michal Schmidt 2012-02-02 08:04:31 EST
(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?
Comment 6 Gary Tivey 2012-02-02 12:00:31 EST
(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.
Comment 7 Jóhann B. Guðmundsson 2012-02-02 18:09:11 EST
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...
Comment 8 Jóhann B. Guðmundsson 2012-03-05 07:58:27 EST
By the way why did we create display-manager.service symlink instead of just using prefdm.service directly ?
Comment 9 Bill Nottingham 2012-03-05 11:23:42 EST
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.)
Comment 10 Jóhann B. Guðmundsson 2012-03-05 11:56:00 EST
(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?
Comment 11 Kay Sievers 2012-03-05 12:03:16 EST
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.
Comment 12 Jóhann B. Guðmundsson 2012-03-05 12:34:26 EST
(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.
Comment 13 Bill Nottingham 2012-03-05 14:31:18 EST
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.
Comment 14 Jóhann B. Guðmundsson 2012-03-07 12:33:49 EST
(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?
Comment 15 Bill Nottingham 2012-03-07 13:47:09 EST
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*.
Comment 16 Jóhann B. Guðmundsson 2012-03-07 14:08:32 EST
(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?
Comment 17 Jóhann B. Guðmundsson 2012-05-31 22:19:48 EDT
Notting ping safe to close or should we move this bug against rawhide?
Comment 18 Bill Nottingham 2012-06-01 17:22:02 EDT
Seems ok to close.

Note You need to log in before you can comment on or make changes to this bug.