search

ahkok / user-session-units

A collection of units for the systemd user session.
GNU Lesser General Public License v2.1
72 stars 23 forks source link

systemctl enable user-session@xxxx.service doesn't seem to do what we want? #9

Open henryptung opened 11 years ago

henryptung commented 11 years ago

Or perhaps I'm misunderstanding the purpose of systemctl enable, but for almost all other services, systemctl enable indicates a desire to start said service at boot; while systemctl enable here simply creates a symlink in etc/systemd/system, which is great - but seems to basically do absolutely nothing, since files in etc/systemd/system seem to be used for overriding their counterparts in usr/lib/systemd/system, and a symlink seems not very useful at all for this purpose. Is this the intended behavior, or can we put something like

[Install] WantedBy=multi-user.target

to produce more consistent behavior?

Bruners commented 11 years ago

Try to look at the user-session@.service as a template rather than a proper unit and the symlink being the real unit.

A service-file with the name@.service without anything between @ and .service can be consider as useless in terms of starting anything. Your install line will in other words not work at all since it will make a symlink to user-session@.service which can't be started.

The directory structure and what you call overriding is more or less up to the user/distro maintainers.

/usr/${LIBDIR}/systemd/* - for systemd upstream and distro specific files
/etc/systemd/* - for installed applications and enabled templates
/home/user/.config/systemd/* - for user specific files, be it customized or original work

The proper place for @.services is and should be in /usr/${LIBDIR}/systemd since it needs to be overridden to even be used. That being said there is nothing wrong with placing both the template and the enabled symlink in the same directory.

It could be debated if a new directory for storing @.service templates should be made