Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On 02/12/2015 04:38 AM, Michael Biebl wrote: 2015-02-11 20:12 GMT+01:00 Lennart Poettering lenn...@poettering.net: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Thu, 12.02.15 05:38, Michael Biebl (mbi...@gmail.com) wrote: 2015-02-11 20:12 GMT+01:00 Lennart Poettering lenn...@poettering.net: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
В Wed, 11 Feb 2015 21:19:16 +0100 Lennart Poettering lenn...@poettering.net пишет: 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Wed, Feb 11, 2015 at 08:12:35PM +0100, Lennart Poettering wrote: On Thu, 05.02.15 01:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Thu, 05.02.15 01:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Wed, 11.02.15 23:10, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Wed, 11 Feb 2015 20:12:35 +0100 Lennart Poettering lenn...@poettering.net пишет: On Thu, 05.02.15 01:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: 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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
2015-02-11 20:12 GMT+01:00 Lennart Poettering lenn...@poettering.net: 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? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Sun, Feb 08, 2015 at 09:12:32AM +0300, Andrei Borzenkov wrote: В Wed, 4 Feb 2015 01:29:11 +0100 Lennart Poettering lenn...@poettering.net пишет: On Thu, 25.12.14 08:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
[grr, accidentally dropped the mailing list on my previous reply] 2015-02-04 21:48 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 21:15, Michael Biebl (mbi...@gmail.com) wrote: 2015-02-04 2:12 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 02:05, Michael Biebl (mbi...@gmail.com) wrote: [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, and runlevel 0 and 6 are symlinks to those targets: 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... 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? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Wed, Feb 04, 2015 at 09:53:20PM +0100, Michael Biebl wrote: [grr, accidentally dropped the mailing list on my previous reply] 2015-02-04 21:48 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 21:15, Michael Biebl (mbi...@gmail.com) wrote: 2015-02-04 2:12 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 02:05, Michael Biebl (mbi...@gmail.com) wrote: [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, and runlevel 0 and 6 are symlinks to those targets: 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... 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Thu, 25.12.14 08:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
2015-02-04 1:29 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Thu, 25.12.14 08:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: 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? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Wed, 04.02.15 01:52, Michael Biebl (mbi...@gmail.com) wrote: 2015-02-04 1:29 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Thu, 25.12.14 08:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
2015-02-04 1:54 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 01:52, Michael Biebl (mbi...@gmail.com) wrote: 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? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Wed, 04.02.15 02:05, Michael Biebl (mbi...@gmail.com) wrote: 2015-02-04 1:54 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Wed, 04.02.15 01:52, Michael Biebl (mbi...@gmail.com) wrote: 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
В Wed, 10 Dec 2014 09:23:16 +0300
Ivan Shapovalov intelfx...@gmail.com пишет:
On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:
Hello Lennart,
Thanks for answering !
On 12/09/2014 02:10 PM, Lennart Poettering wrote:
On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:
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 ?
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 :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On 12/10/2014 10:19 AM, Francis Moreau wrote:
Hello,
On 12/10/2014 07:23 AM, Ivan Shapovalov wrote:
On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:
Hello Lennart,
Thanks for answering !
On 12/09/2014 02:10 PM, Lennart Poettering wrote:
On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:
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 ?
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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
Hello,
On 12/10/2014 07:23 AM, Ivan Shapovalov wrote:
On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:
Hello Lennart,
Thanks for answering !
On 12/09/2014 02:10 PM, Lennart Poettering wrote:
On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:
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 ?
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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
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 ! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote: 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 ? 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. 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
Hello Lennart, Thanks for answering ! On 12/09/2014 02:10 PM, Lennart Poettering wrote: On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote: 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 ? 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. 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:
Hello Lennart,
Thanks for answering !
On 12/09/2014 02:10 PM, Lennart Poettering wrote:
On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:
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 ?
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 /
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.
signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
