[systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
Lennart Poettering
lennart at poettering.net
Wed Feb 11 12:19:16 PST 2015
On Wed, 11.02.15 23:10, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
> В Wed, 11 Feb 2015 20:12:35 +0100
> Lennart Poettering <lennart at poettering.net> пишет:
>
> > On Thu, 05.02.15 01:07, Zbigniew Jędrzejewski-Szmek (zbyszek at 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
More information about the systemd-devel
mailing list