В Sun, 19 Apr 2015 13:19:37 +0000
Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> пишет:
> On Sun, Apr 19, 2015 at 09:29:55AM +0300, Andrei Borzenkov wrote:
> > В Fri, 17 Apr 2015 16:47:58 +0000
> > Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> пишет:
> >
> > > On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote:
> > > > Am 2015-02-16 14:16, schrieb Lennart Poettering:
> > > > >On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote:
> > > > >>Not quite. While you can use drop-in snippets to amend
> > > > >>orderings/depends, it's (unfortunately) not possible to override
> > > > >>Wants=,Before= etc.
> > > > >
> > > > >There have been discussions to allow masking deps via /dev/null
> > > > >symlinks in .wants/ and .requires/ dirs... I think that'd be a better
> > > > >solution...
> > > > >[...]
> > > > >>Agreed, systemctl edit is much nicer. Unfortunately, as said above,
> > > > >>drop-ins can *not* be used to override all aspects of a native unit
> > > > >>file. So it's not (yet) a complete replacement for insserv
> > > > >>overrides.
> > > > >>
> > > > >>If it would be possible to unset Wants= or After=, just like other
> > > > >>service properties, then things would be different.
> > > > >
> > > > >As mentioned, I'd be happy to take patches to make precisely that
> > > > >work!
> > > >
> > > > Last time I talked about this here, there was a lot of confusion, so
> > > > I didn't pursue it further. But I would really like to get this to
> > > > work, but before I start with a patch, I'd like to explain what I'd
> > > > like to do before working on it, to see if it works for you.
> > > >
> > > > The semantics I'd like to see would be the following:
> > > >
> > > > - anything in /etc named exactly the same as in /usr/lib overrides
> > > > the latter, just as is already the case with units and drop-ins
> > > >
> > > > => allow masking of .wants/ and .requires/ with symlinks to
> > > > /dev/null (I think you were in favor of that)
> > > >
> > > > - additionally, postpone processing of dependencies in unit files
> > > > until the entire unit (and all drop-ins) have been read in
> > > >
> > > > For example, even without a drop-in:
> > > >
> > > > a.service:
> > > > [Unit]
> > > > Wants=b.service
> > > > Wants=
> > > > Wants=c.service
> > > >
> > > > After that, Wants should be set to c.service. Note that this
> > > > should NOT affect dependencies set in other ways, i.e. via
> > > > .wants/ directories or by dependencies of other services, this
> > > > should JUST alter what was specified in the unit itself.
> > > >
> > > > A more complex example to illustrate the latter:
> > > >
> > > > /usr/lib/.../a.service:
> > > > [Unit]
> > > > Wants=b.service
> > > > After=c.service
> > > >
> > > > /usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service
> > > > /usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service
> > > >
> > > > /usr/lib/.../f.service
> > > > [Unit]
> > > > Before=a.service
> > > >
> > > > /etc/.../a.service.d/dont-depend-on-b.conf:
> > > > [Unit]
> > > > Wants=
> > > >
> > > > /etc/.../a.service.d/not-after-c.conf:
> > > > [Unit]
> > > > After=
> > > >
> > > > /etc/.../a.service.wants/e.service -> /dev/null
> > > >
> > > > In the end, the dependnecies should be:
> > > >
> > > > Wants=d.service
> > > > - b.service gets removed via drop-in
> > > > - e.service gets removed because it's masked
> > > > - but d.service stays, because it was never defined in
> > > > the unit file, so a drop-in doesn't override it, only
> > > > the mask does
> > > >
> > > > After=f.service
> > > > - c.service gets removed via drop-in
> > > > - f.service is not declared in the original unit file but
> > > > rather in f.service as a Before= dependency, so you'd
> > > > have to override that to make this go into effect
> > > >
> > > > The general principle would be: you can drop stuff at the same
> > > > place it's defined. If it's defined as After= in a unit,
> > > > override it in a drop-in for that unit, if it's defined as
> > > > Before= in another unit, override it in a drop-in for the other
> > > > unit, and if it's defined in the filesystem via .wants/ or
> > > > .requires/, you can override it by masking it in the filesystem.
> > > > Only in the end will all remaining dependencies be combined to
> > > > make up the entire list of dependencies for that service.
> > > >
> > > > Would you be agreeable to these semantics? If so, I'll hack up a
> > > > patch.
> > > Seems quite intuitive to me. Would be great to have this implemented.
> > >
> >
> > Unless I'm mistaken, the only real change is that Wants= will clear
> > list, just like it does it for ExecStart=. This should be rather
> > straightforward to implement I guess.
> Also links in .wants and .requires can be masked. It's not a huge change,
> but I not trivial either -- and this part of the code is notriously had to
> get right.
>
What about Wants-=e.service in dropin? Dropins are processed
after .{wants,requires}.d and has advantage that you can remove also
static dependency from unit definition file, not only mask another
directory.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
