Discussion:
/etc/systemd/system/default.target.wants/ no longer checked for unit files
Add Reply
Richard W.M. Jones
2017-07-14 09:13:33 UTC
Reply
Permalink
Raw Message
https://github.com/systemd/systemd/issues/6334

Since this commit
https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119bbb4427244
(in v233 and v234), you can no longer create
/etc/systemd/system/default.target.wants/ and drop in service files
(or symlinks). The directory is skipped. I have reverted the commit
on top of systemd from git and that makes defaults.target.wants work
again.

Is this supposed to work? It worked fine since at least Fedora 18-25,
but it is now broken in Fedora 26.

If it was never supposed to work, how are you supposed to enable a
service for the default target, even allowing for the user to change
the default target and still have the service enabled?

Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
Mantas Mikulėnas
2017-07-14 10:24:53 UTC
Reply
Permalink
Raw Message
Post by Richard W.M. Jones
https://github.com/systemd/systemd/issues/6334
Since this commit
https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119
bbb4427244
(in v233 and v234), you can no longer create
/etc/systemd/system/default.target.wants/ and drop in service files
(or symlinks). The directory is skipped. I have reverted the commit
on top of systemd from git and that makes defaults.target.wants work
again.
Is this supposed to work? It worked fine since at least Fedora 18-25,
but it is now broken in Fedora 26.
If it was never supposed to work, how are you supposed to enable a
service for the default target, even allowing for the user to change
the default target and still have the service enabled?
The current convention is to install all regular services into
multi-user.target, and I would expect all custom "daily use" targets to be
superset of multi-user.target as well, like the provided graphical.target
already is.

IMHO, don't try to second-guess the user. If they know how to create custom
targets, they'll probably know how to look what's inside their
multi-user.target.wants/ and deal with it.
--
Mantas Mikulėnas <***@gmail.com>
Michael Biebl
2017-07-14 10:28:20 UTC
Reply
Permalink
Raw Message
Post by Mantas Mikulėnas
Post by Richard W.M. Jones
https://github.com/systemd/systemd/issues/6334
Since this commit
https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119bbb4427244
(in v233 and v234), you can no longer create
/etc/systemd/system/default.target.wants/ and drop in service files
(or symlinks). The directory is skipped. I have reverted the commit
on top of systemd from git and that makes defaults.target.wants work
again.
Is this supposed to work? It worked fine since at least Fedora 18-25,
but it is now broken in Fedora 26.
If it was never supposed to work, how are you supposed to enable a
service for the default target, even allowing for the user to change
the default target and still have the service enabled?
The current convention is to install all regular services into
multi-user.target, and I would expect all custom "daily use" targets to be
superset of multi-user.target as well, like the provided graphical.target
already is.
Seems like default.target is used by quite a few services though:
https://codesearch.debian.net/search?q=WantedBy%3Ddefault.target

If default.target is not supposed to be used, then this should be
mentioned somewhere.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Felipe Sateler
2017-07-14 14:50:42 UTC
Reply
Permalink
Raw Message
Post by Michael Biebl
On Fri, Jul 14, 2017 at 12:13 PM, Richard W.M. Jones
Post by Richard W.M. Jones
https://github.com/systemd/systemd/issues/6334
Since this commit
https://github.com/systemd/systemd/
commit/2d058a87ffb2d31a50422a8aebd119bbb4427244
Post by Michael Biebl
Post by Richard W.M. Jones
(in v233 and v234), you can no longer create
/etc/systemd/system/default.target.wants/ and drop in service files
(or symlinks). The directory is skipped. I have reverted the commit
on top of systemd from git and that makes defaults.target.wants work
again.
Is this supposed to work? It worked fine since at least Fedora 18-25,
but it is now broken in Fedora 26.
If it was never supposed to work, how are you supposed to enable a
service for the default target, even allowing for the user to change
the default target and still have the service enabled?
The current convention is to install all regular services into
multi-user.target, and I would expect all custom "daily use" targets to
be superset of multi-user.target as well, like the provided
graphical.target already is.
https://codesearch.debian.net/search?q=WantedBy%3Ddefault.target
If default.target is not supposed to be used, then this should be
mentioned somewhere.
The user manager has a real default.target. Many (most?) of the units
listed above are user services.
--
Saludos,
Felipe Sateler
Richard W.M. Jones
2017-07-14 10:34:19 UTC
Reply
Permalink
Raw Message
Post by Mantas Mikulėnas
Post by Richard W.M. Jones
https://github.com/systemd/systemd/issues/6334
Since this commit
https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119
bbb4427244
(in v233 and v234), you can no longer create
/etc/systemd/system/default.target.wants/ and drop in service files
(or symlinks). The directory is skipped. I have reverted the commit
on top of systemd from git and that makes defaults.target.wants work
again.
Is this supposed to work? It worked fine since at least Fedora 18-25,
but it is now broken in Fedora 26.
If it was never supposed to work, how are you supposed to enable a
service for the default target, even allowing for the user to change
the default target and still have the service enabled?
The current convention is to install all regular services into
multi-user.target, and I would expect all custom "daily use" targets to be
superset of multi-user.target as well, like the provided graphical.target
already is.
IMHO, don't try to second-guess the user. If they know how to create custom
targets, they'll probably know how to look what's inside their
multi-user.target.wants/ and deal with it.
The commit seems as if it was intended to be pure optimization, and
yet it breaks an existing use case. Also the documentation doesn't
mention anything about default.target.wants being deprecated.

Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
Lennart Poettering
2017-07-16 14:31:40 UTC
Reply
Permalink
Raw Message
Post by Mantas Mikulėnas
Post by Richard W.M. Jones
https://github.com/systemd/systemd/issues/6334
Since this commit
https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119
bbb4427244
(in v233 and v234), you can no longer create
/etc/systemd/system/default.target.wants/ and drop in service files
(or symlinks). The directory is skipped. I have reverted the commit
on top of systemd from git and that makes defaults.target.wants work
again.
Is this supposed to work? It worked fine since at least Fedora 18-25,
but it is now broken in Fedora 26.
If it was never supposed to work, how are you supposed to enable a
service for the default target, even allowing for the user to change
the default target and still have the service enabled?
The current convention is to install all regular services into
multi-user.target, and I would expect all custom "daily use" targets to be
superset of multi-user.target as well, like the provided graphical.target
already is.
IMHO, don't try to second-guess the user. If they know how to create custom
targets, they'll probably know how to look what's inside their
multi-user.target.wants/ and deal with it.
default.target and multi-user.target are quite different:

For system services, default.target is generally an alias for either
multi-user.target or graphical.target, but can point to anything else,
too. By dropping in your deps into default.target you say "whatever
the user picks as default, even if it is emergency.target, I want my
service started".

For user services, default.target is a regular unit, and not an alias,
as there things are usually quite a bit simpler.

Do note that if the user starts his system with a special
runlevel/target specified on the kernel cmdline, default.target has no
effect, as we don't bother with it then but directly boot into the
specified name.

Hence, unless you are really really sure your stuff should be loaded
under all conditions, then default.target in system mode might be an
option. In most cases however that's not desirable, and
multi-user.target is the better place (or graphical.target, or so).

Lennart
--
Lennart Poettering, Red Hat
Richard W.M. Jones
2017-07-16 16:26:57 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
For system services, default.target is generally an alias for either
multi-user.target or graphical.target, but can point to anything else,
too. By dropping in your deps into default.target you say "whatever
the user picks as default, even if it is emergency.target, I want my
service started".
Thanks Lennart, this is an interesting take which I hadn't thought
about before. I think I will change virt-customize so it drops these
firstboot services into multi-user.target instead.
Post by Lennart Poettering
For user services, default.target is a regular unit, and not an alias,
as there things are usually quite a bit simpler.
Do note that if the user starts his system with a special
runlevel/target specified on the kernel cmdline, default.target has no
effect, as we don't bother with it then but directly boot into the
specified name.
Hence, unless you are really really sure your stuff should be loaded
under all conditions, then default.target in system mode might be an
option. In most cases however that's not desirable, and
multi-user.target is the better place (or graphical.target, or so).
... And also for these reasons.

Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
Lennart Poettering
2017-07-16 14:33:27 UTC
Reply
Permalink
Raw Message
Post by Richard W.M. Jones
https://github.com/systemd/systemd/issues/6334
Since this commit
https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119bbb4427244
(in v233 and v234), you can no longer create
/etc/systemd/system/default.target.wants/ and drop in service files
(or symlinks). The directory is skipped. I have reverted the commit
on top of systemd from git and that makes defaults.target.wants work
again.
Is this supposed to work? It worked fine since at least Fedora 18-25,
but it is now broken in Fedora 26.
The new code in systemd is simply broken, and we really need to fix
this. The old behaviour was correct.

Lennart
--
Lennart Poettering, Red Hat
Jérémy Rosen
2017-07-18 08:27:07 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Richard W.M. Jones
https://github.com/systemd/systemd/issues/6334
Since this commit
https://github.com/systemd/systemd/commit/2d058a87ffb2d31a50422a8aebd119bbb4427244
(in v233 and v234), you can no longer create
/etc/systemd/system/default.target.wants/ and drop in service files
(or symlinks). The directory is skipped. I have reverted the commit
on top of systemd from git and that makes defaults.target.wants work
again.
Is this supposed to work? It worked fine since at least Fedora 18-25,
but it is now broken in Fedora 26.
The new code in systemd is simply broken, and we really need to fix
this. The old behaviour was correct.
can I ask a more generic question ?

How should alias and drop-in work ? for all intent and purpose,
default.target is an alias for multi-user.target (or other)

should alias drop-ins be loaded when we start an alias but not the main
names ? should all drop-ins from all alias be used ? only the one for
the one we call ? should we skip drop-ins for the main name ?

afaik this is an interesting question that is not documented anywhere...

Jérémy
Post by Lennart Poettering
Lennart
--
Logo <http://www.smile.fr/>

20 rue des Jardins
92600 AsniÚres-sur-Seine
www.smile.fr <http://www.smile.fr/>
*Jérémy ROSEN*
Architecte technique
Email : ***@smile.fr <mailto:***@smile.fr>
Tel : +33141402967

Facebook <https://www.facebook.com/smileopensource> Google%2B
<http://fr.slideshare.net/SmileOpenSource/presentations> LinkedIn
<https://www.linkedin.com/company/smile> Twitter
<https://twitter.com/GroupeSmile>


bandeaux_mail
<http://www.smile.fr/Offres-services/Offres/Ingenierie?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planÚte, n'imprimez ce mail que si c'est nécessaire
Loading...