[systemd-devel] 'tasks' as first-order objects?

[Lennart Poettering]

On Thu, 12.08.10 11:59, Bill Nottingham (notting at redhat.com) wrote:

Heya,

> upstart jobs have two main types - 'services' and 'tasks'. systemd, while it
> has many other types, doesn't have a 'task' analogue. So, for anything that
> has the semantics of a task (at this time/dependency, do this thing and
> exit), ends up being encoded as a service of type 'finish', often
> with 'ValidNoProcess=yes'.

Well, "Type=finish" is supposed to be exactly what Upstart calls
"tasks". I must admit that the word "finish" for this sucks, so we are
open to change this to make it more discoverable. However, I am not sure
"task" is a good choice of names here either, since the low-level stuff
we work with here already uses "tasks" for something else (i.e. as a
generalization of processes and threads in the kernel). I wouldn't wan't
to add confusion here.

So, maybe "Type=transient" is nicer? Sounds a bit scientific but this
word is not unheard in the Free software world at least (i.e. X uses
that iirc) and describes pretty accurately what these kind of processes
are used for, i.e. transient, temporary, short-running processes? Other
suggestions?

> While this works, I think it might be cleaner if this was just promoted
> to a toplevel type - it makes more logical sense than treating these sorts
> of things as 'services', when they're really not.

But tasks and services are very similar things, while services and
mounts are certainly very different, or services and devices. So I am
not sure that the miniaml differences between tasks and services justify
to promote the destinction like this.

Also, there are a lot of things that are in the middle between tasks and
service how Upstart understands it: for example, some stuff you want to
run once whenever it is requested, and other stuff just once at all.

Two Examples: the audit policy loading is something for Type=finish,
since the process "audictl" which does this starts and ends during boot
and does not stay around during system runtime. You probably want to run
it before you run auditd and as a dependency of it, but it probably
makes sense to run it again if auditd terminates and you restart it
later on. So this would be something to set to "Type=finish" and
"ValidNoProcess=no". And it would *not* show up as "active" in systemctl
during normal system runtime, because when the processes exited the
service in systemd went away too.

On the other hand there is stuff like the code that loads the random
seed. It is also something that runs only for a short time during
bootup and does not really stay around during runtime. YOu probably
want to run it before you run sshd, and hence would put a dependency
between the two (of type After= plus Wants=), however if sshd is stopped
and eventually restarted you don't want to start this thing again, you
want this to only happen once, a single time. So you set it to
"Type=finish" but "ValidNoProcess=yes". That way it will still show up
as "active" in systemctl during normal runtime (though with a substate
of "exited"), and the next service that requests it will not pull it in
again.

So, from a superficial view both these services would fit into the
"task" semantics of upstart, however, they have a different effect
during runtime and one of it behaves in some way more like a service
then a task, and hence is something in the middle betweem them.

So, I guess what I want to say is that processes have different
semantics, and there is not clear dichotomy available. And because of
that I'd wrap all this in one unit, and then differentiate them via
Type= into the different styles. 

Does that make sense to you?

(Oh, and if you have a better suggestion for a name of ValidNoProcess= I
am all ears too!)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.