Discussion:
multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
(too old to reply)
Francis Moreau
2014-12-09 10:19:04 UTC
Permalink
Hello,

I've a very weird behaviour with systemd 217:

# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...

So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.

The network.service is an sysv service which is started by rc[345].d and
has in its LSB:

Provide: $network

Could anybody clarify what I'm facing ?

Also it appears that runlevel3 target is an alias for multi-user one.
Could anybody where this alias is done ? If that's in the source code of
systemd I would be curious to see where exactly.

Thanks !
Lennart Poettering
2014-12-09 13:10:59 UTC
Permalink
Post by Francis Moreau
Hello,
# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...
So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.
The network.service is an sysv service which is started by rc[345].d and
Provide: $network
Could anybody clarify what I'm facing ?
systemd lazy loads services from the file system as they are
referenced. This includes symlinked aliases, which are only loaded when
a unit is referenced by that specific name.
Post by Francis Moreau
Also it appears that runlevel3 target is an alias for multi-user one.
Could anybody where this alias is done ? If that's in the source code of
systemd I would be curious to see where exactly.
The /usr/lib/systemd/system/runlevel[0-5].target symlinks create these
alias names.

Lennart
--
Lennart Poettering, Red Hat
Francis Moreau
2014-12-09 16:25:48 UTC
Permalink
Hello Lennart,

Thanks for answering !
Post by Lennart Poettering
Post by Francis Moreau
Hello,
# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...
So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.
The network.service is an sysv service which is started by rc[345].d and
Provide: $network
Could anybody clarify what I'm facing ?
systemd lazy loads services from the file system as they are
referenced. This includes symlinked aliases, which are only loaded when
a unit is referenced by that specific name.
Sorry but I don't really understand.

Do you mean that the network.service wasn't loaded although the
runlevel3.target, which is an alias for multi-user target (default
target) wants it ?

I would be glad if you could enlight me because I'm confused.
Post by Lennart Poettering
Post by Francis Moreau
Also it appears that runlevel3 target is an alias for multi-user one.
Could anybody where this alias is done ? If that's in the source code of
systemd I would be curious to see where exactly.
The /usr/lib/systemd/system/runlevel[0-5].target symlinks create these
alias names.
I see now.

Thanks.
Ivan Shapovalov
2014-12-10 06:23:16 UTC
Permalink
Post by Francis Moreau
Hello Lennart,
Thanks for answering !
Post by Lennart Poettering
Post by Francis Moreau
Hello,
# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...
So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.
The network.service is an sysv service which is started by rc[345].d and
Provide: $network
Could anybody clarify what I'm facing ?
systemd lazy loads services from the file system as they are
referenced. This includes symlinked aliases, which are only loaded when
a unit is referenced by that specific name.
Sorry but I don't really understand.
Do you mean that the network.service wasn't loaded although the
runlevel3.target, which is an alias for multi-user target (default
target) wants it ?
I would be glad if you could enlight me because I'm confused.
Apparently, network.service gets pulled in only via runlevel3.target, i. e.
there is a symlink of kind

/{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service -> network.service

That is, the Wants= dependency is generated for runlevel3.target only, not for
multi-user.target.

And, because systemd loads units lazily, systemd does not know about runlevel3.target
(and its dependencies) before anything forces systemd to load that unit.

After you issue `systemctl show runlevel3.target`, systemd loads that unit,
loads its dependencies and merges them to multi-user.target (because runlevel3.target
is an alias for multi-user.target).

HTHs,
--
Ivan Shapovalov / intelfx /
Post by Francis Moreau
Post by Lennart Poettering
Post by Francis Moreau
Also it appears that runlevel3 target is an alias for multi-user one.
Could anybody where this alias is done ? If that's in the source code of
systemd I would be curious to see where exactly.
The /usr/lib/systemd/system/runlevel[0-5].target symlinks create these
alias names.
I see now.
Thanks.
Francis Moreau
2014-12-10 09:19:13 UTC
Permalink
Hello,
Post by Ivan Shapovalov
Post by Francis Moreau
Hello Lennart,
Thanks for answering !
Post by Lennart Poettering
Post by Francis Moreau
Hello,
# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...
So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.
The network.service is an sysv service which is started by rc[345].d and
Provide: $network
Could anybody clarify what I'm facing ?
systemd lazy loads services from the file system as they are
referenced. This includes symlinked aliases, which are only loaded when
a unit is referenced by that specific name.
Sorry but I don't really understand.
Do you mean that the network.service wasn't loaded although the
runlevel3.target, which is an alias for multi-user target (default
target) wants it ?
I would be glad if you could enlight me because I'm confused.
Apparently, network.service gets pulled in only via runlevel3.target, i. e.
there is a symlink of kind
/{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service -> network.service
That is, the Wants= dependency is generated for runlevel3.target only, not for
multi-user.target.
And, because systemd loads units lazily, systemd does not know about runlevel3.target
(and its dependencies) before anything forces systemd to load that unit.
After you issue `systemctl show runlevel3.target`, systemd loads that unit,
loads its dependencies and merges them to multi-user.target (because runlevel3.target
is an alias for multi-user.target).
That helps, thanks !

However that seems a bit weird to have a target with 'hidden'
dependencies that can appears magically when poking another one, at
least from my point of (user) view.

Was the lazy load mechanism integrated recently ? I'm asking because
systemd 208 doesn't show the same behaviour.

What's the recommanded way to make sure that the Wants= dependencies
generated for runlevel3 target get pplied as soon as possible to its
alias target 'multi-user' ?

Thanks for your help.
Francis Moreau
2014-12-11 12:27:15 UTC
Permalink
Post by Francis Moreau
Hello,
Post by Ivan Shapovalov
Post by Francis Moreau
Hello Lennart,
Thanks for answering !
Post by Lennart Poettering
Post by Francis Moreau
Hello,
# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...
So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.
The network.service is an sysv service which is started by rc[345].d and
Provide: $network
Could anybody clarify what I'm facing ?
systemd lazy loads services from the file system as they are
referenced. This includes symlinked aliases, which are only loaded when
a unit is referenced by that specific name.
Sorry but I don't really understand.
Do you mean that the network.service wasn't loaded although the
runlevel3.target, which is an alias for multi-user target (default
target) wants it ?
I would be glad if you could enlight me because I'm confused.
Apparently, network.service gets pulled in only via runlevel3.target, i. e.
there is a symlink of kind
/{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service -> network.service
That is, the Wants= dependency is generated for runlevel3.target only, not for
multi-user.target.
And, because systemd loads units lazily, systemd does not know about runlevel3.target
(and its dependencies) before anything forces systemd to load that unit.
After you issue `systemctl show runlevel3.target`, systemd loads that unit,
loads its dependencies and merges them to multi-user.target (because runlevel3.target
is an alias for multi-user.target).
That helps, thanks !
However that seems a bit weird to have a target with 'hidden'
dependencies that can appears magically when poking another one, at
least from my point of (user) view.
Was the lazy load mechanism integrated recently ? I'm asking because
systemd 208 doesn't show the same behaviour.
What's the recommanded way to make sure that the Wants= dependencies
generated for runlevel3 target get pplied as soon as possible to its
alias target 'multi-user' ?
Could anybody enlight me because I actually don't know how I'm supposed
to start all services that runlevel3 would start otherwise. Should I add
manually a "Wants=</etc/rd.d/rc3/S*>" dependency in the multi-user target ?

Thanks.
a***@gmail.com
2014-12-25 06:26:25 UTC
Permalink
Отправлено с iPhone
Post by Francis Moreau
Post by Francis Moreau
Hello,
Post by Ivan Shapovalov
Post by Francis Moreau
Hello Lennart,
Thanks for answering !
Post by Lennart Poettering
Post by Francis Moreau
Hello,
# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...
So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.
The network.service is an sysv service which is started by rc[345].d and
Provide: $network
Could anybody clarify what I'm facing ?
systemd lazy loads services from the file system as they are
referenced. This includes symlinked aliases, which are only loaded when
a unit is referenced by that specific name.
Sorry but I don't really understand.
Do you mean that the network.service wasn't loaded although the
runlevel3.target, which is an alias for multi-user target (default
target) wants it ?
I would be glad if you could enlight me because I'm confused.
Apparently, network.service gets pulled in only via runlevel3.target, i. e.
there is a symlink of kind
/{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service -> network.service
That is, the Wants= dependency is generated for runlevel3.target only, not for
multi-user.target.
And, because systemd loads units lazily, systemd does not know about runlevel3.target
(and its dependencies) before anything forces systemd to load that unit.
After you issue `systemctl show runlevel3.target`, systemd loads that unit,
loads its dependencies and merges them to multi-user.target (because runlevel3.target
is an alias for multi-user.target).
That helps, thanks !
However that seems a bit weird to have a target with 'hidden'
dependencies that can appears magically when poking another one, at
least from my point of (user) view.
Was the lazy load mechanism integrated recently ? I'm asking because
systemd 208 doesn't show the same behaviour.
What's the recommanded way to make sure that the Wants= dependencies
generated for runlevel3 target get pplied as soon as possible to its
alias target 'multi-user' ?
Could anybody enlight me because I actually don't know how I'm supposed
to start all services that runlevel3 would start otherwise. Should I add
manually a "Wants=</etc/rd.d/rc3/S*>" dependency in the multi-user target ?
Workaround would be to set default.target to runlevel3.target (or 5). This will trigger everything mult-user normally does in addition to direct dependencies.

But in general aliasing via symlinks looks problematic enough.
Post by Francis Moreau
Thanks.
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Andrei Borzenkov
2014-12-25 05:37:34 UTC
Permalink
В Wed, 10 Dec 2014 09:23:16 +0300
Post by Ivan Shapovalov
Post by Francis Moreau
Hello Lennart,
Thanks for answering !
Post by Lennart Poettering
Post by Francis Moreau
Hello,
# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...
So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.
The network.service is an sysv service which is started by rc[345].d and
Provide: $network
Could anybody clarify what I'm facing ?
systemd lazy loads services from the file system as they are
referenced. This includes symlinked aliases, which are only loaded when
a unit is referenced by that specific name.
Sorry but I don't really understand.
Do you mean that the network.service wasn't loaded although the
runlevel3.target, which is an alias for multi-user target (default
target) wants it ?
I would be glad if you could enlight me because I'm confused.
Apparently, network.service gets pulled in only via runlevel3.target, i. e.
there is a symlink of kind
/{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service -> network.service
That is, the Wants= dependency is generated for runlevel3.target only, not for
multi-user.target.
And, because systemd loads units lazily, systemd does not know about runlevel3.target
(and its dependencies) before anything forces systemd to load that unit.
This looks like fallout of moving to generators for sysv units. Before
systemd added dependencies on runlevelX.target directly to units built
from initscripts. This forced runlevelX.target resolution and
everything was OK. Now core systemd never references these targets
directly.

This is a genuine bug which will bite people. But it looks like worked
just by accident before anyway :( So we need possibility to define
aliases for existing units without exhaustive search across all unit
definitions ... may be unit.alias.d?

Cc'ing Thomas as original author of sysv generators :)
Lennart Poettering
2015-02-04 00:29:11 UTC
Permalink
Post by Andrei Borzenkov
This looks like fallout of moving to generators for sysv units. Before
systemd added dependencies on runlevelX.target directly to units built
from initscripts. This forced runlevelX.target resolution and
everything was OK. Now core systemd never references these targets
directly.
This is a genuine bug which will bite people. But it looks like worked
just by accident before anyway :( So we need possibility to define
aliases for existing units without exhaustive search across all unit
definitions ... may be unit.alias.d?
This is a real shortcoming of the current logic in systemd, indeed.

So, one possible way out of this might be add a .wants/ dep from
multi-user.target.wants/ to runlevel3.target, if runlevel3.target is
linked to that. THis would cause runlevel3.target to be loaded, which
would then detect the symlink and merge it into
multi-user.target. After loading it would try to create the .wants
link, but recognize that it is now trying to create a .wants link on
itself, and suppress it.

These extra .wants symlinks could even be generated dynamically from
sysv-generator, so that people can easily override the runlevel
mappings by placing a symlink in /etc, without having to manually also
add the .wants/ link at the same time...

It's a bit ugly, and feels a bit hackish, but should work.

Another option would be to actually add expose the internal dependency
type "References" to the outside. It's only purpose is to act as
reference for the GC logic, thus ensuring that its target is
loaded.

I am kinda leaning towards the sysv-generator option.

Happy to take a patch if anybody wants to hack this up...

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2015-02-04 00:52:10 UTC
Permalink
Post by Lennart Poettering
Post by Andrei Borzenkov
This looks like fallout of moving to generators for sysv units. Before
systemd added dependencies on runlevelX.target directly to units built
from initscripts. This forced runlevelX.target resolution and
everything was OK. Now core systemd never references these targets
directly.
This is a genuine bug which will bite people. But it looks like worked
just by accident before anyway :( So we need possibility to define
aliases for existing units without exhaustive search across all unit
definitions ... may be unit.alias.d?
This is a real shortcoming of the current logic in systemd, indeed.
So, one possible way out of this might be add a .wants/ dep from
multi-user.target.wants/ to runlevel3.target, if runlevel3.target is
linked to that. THis would cause runlevel3.target to be loaded, which
would then detect the symlink and merge it into
multi-user.target. After loading it would try to create the .wants
link, but recognize that it is now trying to create a .wants link on
itself, and suppress it.
Is this the same issue as
https://bugzilla.redhat.com/show_bug.cgi?id=1002806#c20 ?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2015-02-04 00:54:10 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
Post by Andrei Borzenkov
This looks like fallout of moving to generators for sysv units. Before
systemd added dependencies on runlevelX.target directly to units built
from initscripts. This forced runlevelX.target resolution and
everything was OK. Now core systemd never references these targets
directly.
This is a genuine bug which will bite people. But it looks like worked
just by accident before anyway :( So we need possibility to define
aliases for existing units without exhaustive search across all unit
definitions ... may be unit.alias.d?
This is a real shortcoming of the current logic in systemd, indeed.
So, one possible way out of this might be add a .wants/ dep from
multi-user.target.wants/ to runlevel3.target, if runlevel3.target is
linked to that. THis would cause runlevel3.target to be loaded, which
would then detect the symlink and merge it into
multi-user.target. After loading it would try to create the .wants
link, but recognize that it is now trying to create a .wants link on
itself, and suppress it.
Is this the same issue as
https://bugzilla.redhat.com/show_bug.cgi?id=1002806#c20 ?
Feels like it.

It's not clear to me though why the bug was closed, i.e. what fix was
applied there...

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2015-02-04 01:05:53 UTC
Permalink
Post by Lennart Poettering
Post by Michael Biebl
Is this the same issue as
https://bugzilla.redhat.com/show_bug.cgi?id=1002806#c20 ?
Feels like it.
It's not clear to me though why the bug was closed, i.e. what fix was
applied there...
We pulled a fix/workaround from the Fedora package [1] if my memory
serves me well.
If we could get rid of that and this is fixed upstream proper, that
would be great.

Michael


[1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2015-02-04 01:12:40 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
Post by Michael Biebl
Is this the same issue as
https://bugzilla.redhat.com/show_bug.cgi?id=1002806#c20 ?
Feels like it.
It's not clear to me though why the bug was closed, i.e. what fix was
applied there...
We pulled a fix/workaround from the Fedora package [1] if my memory
serves me well.
If we could get rid of that and this is fixed upstream proper, that
would be great.
Michael
[1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b
That hack is actually not that ugly... Though incomplete since it will
only add refs to runlevel[1-5], but not 0,6...

But I still think the .wants symlinks from sysv-generator might be the
better hack to apply...

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2015-02-04 20:53:20 UTC
Permalink
[grr, accidentally dropped the mailing list on my previous reply]
Post by Lennart Poettering
Post by Michael Biebl
[1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b
That hack is actually not that ugly... Though incomplete since it will
only add refs to runlevel[1-5], but not 0,6...
Does it? It adds the wants symlinks to poweroff and reboot as well,
Well, but the goal here is to make sure runlevel0.target and
runlevel6.target are at least once referenced. For
runlevel[1-5].target this is nicely achieved by pulling in
systemd-update-utmp-runlevel.service, since that actually contains
After= deps for those 5 runlevel targets... But it doesn't for 0 and 6,
which hence never get loaded, thus not fixing the problem for them...
Post by Lennart Poettering
But I still think the .wants symlinks from sysv-generator might be the
better hack to apply...
Do you mean, generating the same set of symlinks as above from within
the sysv-generator?
I guess I could cobble together a patch for that.
No, s-u-u-r.s should not be involved really...
Instead, the generator should iterate through runlevel0-6.target, then
check where they point and add a .wants symlink from their destination
to themselves. When systemd tries to load the .wants/ symlinks it will
load these alias, figure out they point back to the respective
targets, merge the targets. Finally, it will realize that the wants
link is actually on itself, which it suppresses and all is good.
Alternatively, we could just create those symlink on make install, if
sysv support is enabled.
The benefit of a generator is that people can reassign what their
runlevels mean simply by overriding the one symlink in
/etc/systemd/system for it. We will then derive the other symlink from
that, automatically.
Since the original patch is from Zbyszek, I'm bringing him into the loop here.

Just want to know why he didn't considered pushing this patch upstream.
Apparently already two distros patch this downstream, so having a fix
upstream would imho make sense.


Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Zbigniew Jędrzejewski-Szmek
2015-02-05 00:07:44 UTC
Permalink
Post by Michael Biebl
[grr, accidentally dropped the mailing list on my previous reply]
Post by Lennart Poettering
Post by Michael Biebl
[1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b
That hack is actually not that ugly... Though incomplete since it will
only add refs to runlevel[1-5], but not 0,6...
Does it? It adds the wants symlinks to poweroff and reboot as well,
Well, but the goal here is to make sure runlevel0.target and
runlevel6.target are at least once referenced. For
runlevel[1-5].target this is nicely achieved by pulling in
systemd-update-utmp-runlevel.service, since that actually contains
After= deps for those 5 runlevel targets... But it doesn't for 0 and 6,
which hence never get loaded, thus not fixing the problem for them...
Post by Lennart Poettering
But I still think the .wants symlinks from sysv-generator might be the
better hack to apply...
Do you mean, generating the same set of symlinks as above from within
the sysv-generator?
I guess I could cobble together a patch for that.
No, s-u-u-r.s should not be involved really...
Instead, the generator should iterate through runlevel0-6.target, then
check where they point and add a .wants symlink from their destination
to themselves. When systemd tries to load the .wants/ symlinks it will
load these alias, figure out they point back to the respective
targets, merge the targets. Finally, it will realize that the wants
link is actually on itself, which it suppresses and all is good.
Alternatively, we could just create those symlink on make install, if
sysv support is enabled.
The benefit of a generator is that people can reassign what their
runlevels mean simply by overriding the one symlink in
/etc/systemd/system for it. We will then derive the other symlink from
that, automatically.
Since the original patch is from Zbyszek, I'm bringing him into the loop here.
Just want to know why he didn't considered pushing this patch upstream.
Apparently already two distros patch this downstream, so having a fix
upstream would imho make sense.
Because it was just a hack :)

Maybe Lennart's idea with the sysv generator is a better thing.

Zbyszek
Lennart Poettering
2015-02-11 19:12:35 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Michael Biebl
Just want to know why he didn't considered pushing this patch upstream.
Apparently already two distros patch this downstream, so having a fix
upstream would imho make sense.
Because it was just a hack :)
Maybe Lennart's idea with the sysv generator is a better thing.
So, I have discussed this with Kay, David, Daniel, and co. And we
kinda came to the conclusion that we might as well just drop the
configurability where runlevel3-5.target point to. If we drop that, we
can just keep them as symlink aliases in place, but the sysv
generator won't create symlinks in them anymore. Instead it will
create the right links directly in multi-user.target and
graphical.target as necessary.

I think that would be the simplest, easiest solution for the
problem. Redefining runlevels in the systemd context is kinda a crazy
idea, and we should probably just say goodbye to it... I am retty sure
pretty much nobody made use of this anyway.

Opinions?

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2015-02-11 19:18:52 UTC
Permalink
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Michael Biebl
Just want to know why he didn't considered pushing this patch upstream.
Apparently already two distros patch this downstream, so having a fix
upstream would imho make sense.
Because it was just a hack :)
Maybe Lennart's idea with the sysv generator is a better thing.
So, I have discussed this with Kay, David, Daniel, and co. And we
kinda came to the conclusion that we might as well just drop the
configurability where runlevel3-5.target point to. If we drop that, we
can just keep them as symlink aliases in place, but the sysv
generator won't create symlinks in them anymore. Instead it will
create the right links directly in multi-user.target and
graphical.target as necessary.
I think that would be the simplest, easiest solution for the
problem. Redefining runlevels in the systemd context is kinda a crazy
idea, and we should probably just say goodbye to it... I am retty sure
pretty much nobody made use of this anyway.
If that works, than I'm +1.

Zbyszek
Andrei Borzenkov
2015-02-11 20:10:31 UTC
Permalink
В Wed, 11 Feb 2015 20:12:35 +0100
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Michael Biebl
Just want to know why he didn't considered pushing this patch upstream.
Apparently already two distros patch this downstream, so having a fix
upstream would imho make sense.
Because it was just a hack :)
Maybe Lennart's idea with the sysv generator is a better thing.
So, I have discussed this with Kay, David, Daniel, and co. And we
kinda came to the conclusion that we might as well just drop the
configurability where runlevel3-5.target point to. If we drop that, we
can just keep them as symlink aliases in place, but the sysv
generator won't create symlinks in them anymore. Instead it will
create the right links directly in multi-user.target and
graphical.target as necessary.
Why not simply make generator resolve links to final destination? I bet
we already should have helper that does it.
Post by Lennart Poettering
I think that would be the simplest, easiest solution for the
problem. Redefining runlevels in the systemd context is kinda a crazy
idea, and we should probably just say goodbye to it... I am retty sure
pretty much nobody made use of this anyway.
Opinions?
But the problem is not limited to legacy initscripts. It makes it
generally unsafe to have aliases via symlinks. Aliases were always
meant "for compatibility" but this problems exactly means that
"compatibility" is broken here - when you replace unit A with
compatibility link to unit B things may be broken unless you always
refer to A when you refer to B. At which point why have alias at all?
Lennart Poettering
2015-02-11 20:19:16 UTC
Permalink
Post by Andrei Borzenkov
В Wed, 11 Feb 2015 20:12:35 +0100
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Post by Michael Biebl
Just want to know why he didn't considered pushing this patch upstream.
Apparently already two distros patch this downstream, so having a fix
upstream would imho make sense.
Because it was just a hack :)
Maybe Lennart's idea with the sysv generator is a better thing.
So, I have discussed this with Kay, David, Daniel, and co. And we
kinda came to the conclusion that we might as well just drop the
configurability where runlevel3-5.target point to. If we drop that, we
can just keep them as symlink aliases in place, but the sysv
generator won't create symlinks in them anymore. Instead it will
create the right links directly in multi-user.target and
graphical.target as necessary.
Why not simply make generator resolve links to final destination? I bet
we already should have helper that does it.
It's really hard to follow those symlinks, since they are not followed
in the same scheme as the kernel, but actually are overblended with
/run, /etc/ /usr, and the actual target is used last.

To my knowledge we have no code for this.

Also, this is not a game you can win. Checking what is already there
is difficult, since things can dynamically appear via generators and
stuff.

I'd really try to put a strong focus on keeping generators strictly
additive, so that they don't start to gain weird interdependencies. In
fact, the patch I recently merged from Martin that checks /usr before
creating sysv units already breaks with that, and that's precisely why
I don't like it.
Post by Andrei Borzenkov
Post by Lennart Poettering
I think that would be the simplest, easiest solution for the
problem. Redefining runlevels in the systemd context is kinda a crazy
idea, and we should probably just say goodbye to it... I am retty sure
pretty much nobody made use of this anyway.
Opinions?
But the problem is not limited to legacy initscripts. It makes it
generally unsafe to have aliases via symlinks. Aliases were always
meant "for compatibility" but this problems exactly means that
"compatibility" is broken here - when you replace unit A with
compatibility link to unit B things may be broken unless you always
refer to A when you refer to B. At which point why have alias at all?
I think it's completely Ok that dependencies on aliases only work as
long as they are referenced at least once by them. This isn't really
that surprising a behaviour I think.

Lennart
--
Lennart Poettering, Red Hat
Andrei Borzenkov
2015-02-13 06:49:59 UTC
Permalink
В Wed, 11 Feb 2015 21:19:16 +0100
Post by Lennart Poettering
Post by Andrei Borzenkov
But the problem is not limited to legacy initscripts. It makes it
generally unsafe to have aliases via symlinks. Aliases were always
meant "for compatibility" but this problems exactly means that
"compatibility" is broken here - when you replace unit A with
compatibility link to unit B things may be broken unless you always
refer to A when you refer to B. At which point why have alias at all?
I think it's completely Ok that dependencies on aliases only work as
long as they are referenced at least once by them. This isn't really
that surprising a behaviour I think.
Sorry if I was not clear. User had WantedBy=A.target in the past and
other places had Want/Require=A.target. Now A.target -> B.target and
all other places were adjusted to Want/Require=B.target. As was
demonstrated all user units that were using WantedBy=A.target are now
effectively broken.

Aliases imply that they are interchangeable. If they are not that must
be at least quite clear and explicitly stated so in manual. If aliases
are not interchangeable than the only use case I can see is for one way
migration from old to new name but exactly this use case is broken.
Lennart Poettering
2015-02-13 09:52:36 UTC
Permalink
Post by Andrei Borzenkov
В Wed, 11 Feb 2015 21:19:16 +0100
Post by Lennart Poettering
Post by Andrei Borzenkov
But the problem is not limited to legacy initscripts. It makes it
generally unsafe to have aliases via symlinks. Aliases were always
meant "for compatibility" but this problems exactly means that
"compatibility" is broken here - when you replace unit A with
compatibility link to unit B things may be broken unless you always
refer to A when you refer to B. At which point why have alias at all?
I think it's completely Ok that dependencies on aliases only work as
long as they are referenced at least once by them. This isn't really
that surprising a behaviour I think.
Sorry if I was not clear. User had WantedBy=A.target in the past and
other places had Want/Require=A.target. Now A.target -> B.target and
all other places were adjusted to Want/Require=B.target. As was
demonstrated all user units that were using WantedBy=A.target are now
effectively broken.
Aliases imply that they are interchangeable. If they are not that must
be at least quite clear and explicitly stated so in manual. If aliases
are not interchangeable than the only use case I can see is for one way
migration from old to new name but exactly this use case is broken.
Sure, we can always have more documentation.

But I think they actually have a lot of uses still, since they allow
mapping of some fixed name to a variety of different choices. As long
as the fixed name is explicitly requested all is good.

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2015-02-12 04:38:22 UTC
Permalink
Post by Lennart Poettering
So, I have discussed this with Kay, David, Daniel, and co. And we
kinda came to the conclusion that we might as well just drop the
configurability where runlevel3-5.target point to. If we drop that, we
Do you mean runlevel2-5, or is runlevel2 excluded for a reason?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2015-02-12 10:03:07 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
So, I have discussed this with Kay, David, Daniel, and co. And we
kinda came to the conclusion that we might as well just drop the
configurability where runlevel3-5.target point to. If we drop that, we
Do you mean runlevel2-5, or is runlevel2 excluded for a reason?
No, that was just a typo...

Happy to take a patch for this...

Lennart
--
Lennart Poettering, Red Hat
Jóhann B. Guðmundsson
2015-02-12 10:27:55 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
So, I have discussed this with Kay, David, Daniel, and co. And we
kinda came to the conclusion that we might as well just drop the
configurability where runlevel3-5.target point to. If we drop that, we
Do you mean runlevel2-5, or is runlevel2 excluded for a reason?
Well we have more targets then there are run levels for example
emergency and rescue both of which could be seen as "run level 1"
Run level 2 arguably should have been mapped to basic.target from the
start and is causing confusion since it's mapped to the multi-user.target
Run level 3 as in the multi-user.target lacks network support ( even
thou now it arguably could be added properly with systemd-networkd ),
which is what users expect
Run level 4 cant be mapped to users custom boot target ( they have to
manually link it themselves and since they have to do that they are
simply better of using systemctl set-default <my-custom-boot.target>
reboot and then change it back or isolate to it.
etc.

The fact is if shit hits the fan at bootup systemd really aught to
handle that gracefully and drop users down to rescue.target and or
emergency.target and if you switch targets later then you should wind up
with only the exact services running as you would have booted directly
to the target you isolated to.

Forcing users having to add a kernel command line ( 1,2,3 etc ) is
archaic in the 21 century from my pov but unfortunately our huge timeout
that happens at bootup contributes to users having to manually boot to a
specific target ( or runlevel ) due to the fact users dont wait for that
time out ( by my observation these years if users are used boot
completing in <15s having them wait for more then ca 30s tops reaches
their patience threshold and they *will* in all cases hard power off the
machine and power it on again which beats the purpose of the time out to
begin with )

So arguably the entire concept of run levels ( and backward
compatibility and support ) should be put to rest upstream and have
downstream maintaining that compatibility support if they so much desire
since it never applied to systemd and doing so has and is hindering
adoption of the systemd concept of targets, causes confusion for users
and arguably hinders us evolve to a better native solution to solve the
usecases that inspired the existence of run levels to begin with.

JBG
Andrei Borzenkov
2015-02-08 06:12:32 UTC
Permalink
В Wed, 4 Feb 2015 01:29:11 +0100
Post by Lennart Poettering
Post by Andrei Borzenkov
This looks like fallout of moving to generators for sysv units. Before
systemd added dependencies on runlevelX.target directly to units built
from initscripts. This forced runlevelX.target resolution and
everything was OK. Now core systemd never references these targets
directly.
This is a genuine bug which will bite people. But it looks like worked
just by accident before anyway :( So we need possibility to define
aliases for existing units without exhaustive search across all unit
definitions ... may be unit.alias.d?
This is a real shortcoming of the current logic in systemd, indeed.
So, one possible way out of this might be add a .wants/ dep from
multi-user.target.wants/ to runlevel3.target, if runlevel3.target is
linked to that.
Won't it cause a loop? runlevel3.target is already link to
multi-user.target; this will make it to Want itself?
Zbigniew Jędrzejewski-Szmek
2015-02-08 15:47:56 UTC
Permalink
Post by Andrei Borzenkov
В Wed, 4 Feb 2015 01:29:11 +0100
Post by Lennart Poettering
Post by Andrei Borzenkov
This looks like fallout of moving to generators for sysv units. Before
systemd added dependencies on runlevelX.target directly to units built
from initscripts. This forced runlevelX.target resolution and
everything was OK. Now core systemd never references these targets
directly.
This is a genuine bug which will bite people. But it looks like worked
just by accident before anyway :( So we need possibility to define
aliases for existing units without exhaustive search across all unit
definitions ... may be unit.alias.d?
This is a real shortcoming of the current logic in systemd, indeed.
So, one possible way out of this might be add a .wants/ dep from
multi-user.target.wants/ to runlevel3.target, if runlevel3.target is
linked to that.
Won't it cause a loop? runlevel3.target is already link to
multi-user.target; this will make it to Want itself?
This loop will be dropped. Although I think that I added code which warns
when a dependency on self is declared. This warning might have to be changed
if we got this route.

Zbyszek
Continue reading on narkive:
Loading...