[systemd-devel] [PATCH 1/6] Set StopWhenUnneeded=no, if unit started manually

[Lennart Poettering]

On Tue, 12.02.13 01:14, Oleksii Shevchuk (alxchk at gmail.com) wrote:

heya!

Sorry for the delay in reviewing.

Hmm, I agree such a change might make sense, but thinking about it I
came to the conclusion it should work differently...

But first: unit_start() will be called for both manual starts and start
caused because they are pulled in, so the current patch can't really
work, or am I missing something?

To really know if something is pulled in "automatically" or not is
probably not even the question we should ask for. Instead, maybe we
should hook this into the "override" functionality of the job engine
instead, that is currently little used.

"override" is a boolean that is passed when a new job is queued. If
"true" then RequiresOverridable= type dependencies are basically treated
like Wants=, i.e. they don't matter anymore. This boolean is currently
tracked for all queued jobs. "override" is set for all explicitly (via
dbus) requested jobs, but left unset for the jobs queued by other
means... It already sounds very close to your requirements.

In addition to this bool we should also extend the Job object to keep
track whether it was actually the "root" of a transaction, i.e. the
actual job being asked for rather than just a dependency of one. 

Now, if we have both those booleans, we could combine them and if both
are true we know that a unit was explicitly asked for by the
user... Which should do the job. This combined bool should then be
passed from the job to the unit in a new parameter to the unit_start()
call. The unit object should then store that (and implicitly reset it on
unit_stop() again). The stored bool would hence indicate "this unit was
requested manually at least once during this lifecycle".

This boolean could then easily be checked in unit_check_unneeded(),
which would just return early if it is set, thus disabling auto-stop of
the unit.

I hope this makes some sense? Hooking this into the transaction logic
makes grokking this all admittedly a bit more complex, but it sounds
worthy to me, as the patch will actually probably be more like 10 lines
and that's it...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.