[systemd-devel] Environment for prefdm.service
lennart at poettering.net
Mon Jul 11 12:34:19 PDT 2011
On Mon, 11.07.11 15:29, David Michael (fedora.dm0 at gmail.com) wrote:
> On Tue, Jul 5, 2011 at 6:20 PM, Kay Sievers <kay.sievers at vrfy.org> wrote:
> > To work in the right direction here, it might be worth to point out in
> > this context, that the concept of a (multiplexing) prefdm.service
> > should go away sooner than, and all individual window manager should
> > install their own native service file from their own package.
> > Which of the window managers will be started at bootup will then
> > entirely be controlled by the 'enable' state of the systemd service
> > and not by some (awkward) global distro config/service file.
> I tried creating a unit file for this, and it's not a big deal at the
> moment since no other display managers (that I use) have one, but how
> do you recommend handling situations with multiple display manager
> services installed?
> I don't follow if/how display-manager.service is intended to work in
> this situation. Are users supposed to manage the target of the
> symlink manually?
> It is distributed under /lib (along with its link
> under graphical.target.wants), implying it should not be changed.
Unit files (and symlinks) in /etc/systemd/system will override those in
/lib/systemd/system if the bear the same name. If a user wants to
deviate from the system default, he should should place his own symlink
/ect/systemd/system/display-manager.service and leave /lib untouched.
> Ignoring display-manager.service, I imagine distribution packages
> would have to ship all display managers enabled by default, so users
> who only install one will have a graphical login automatically. Will
> anything prevent multiple display managers from actually trying to
> start concurrently? I used conflicts in my unit file, but that
> doesn't seem like it will scale well.
The thing is that in a multi-seat setup running multiple DMs might
actually be a valid choice, so compltely prohibiting this is probably
not an option.
> Sorry if I'm missing something simple or if I have confused myself
> beyond all hope. I appreciate any advice on how to prepare this in a
> future-compatible way.
My recommendation is to simply list display-manager.service in Alias= in
[Install] in your unit file. Since that symlink can only point to one
service we should be safe. The choice which one to start is done with
this symlink and nothing else.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel