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

[Lennart Poettering]

On Thu, 12.08.10 15:56, Bill Nottingham (notting at redhat.com) wrote:

> > 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.
> 
> Will those that are interacting with the unit files be the same set that
> will interact with the 'task' low-level infrastructure?

It's unfortunately exposed way too often, I think. 

> If not, it might be OK to use the same verbiage.

And if people come from windows they are probably used to the "task as
process" meaning of "task" too.

> > 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?
> 
> 'function'
> 'oneshot'
> 'single'
> 'not-respawning'
> 
> (None of these are necessarily good.)

"oneshot" sounds the best choice from this list to me. What are your
opinions on "transient"?

I am tempted to do s/finish/transient/. Anybody else has an opinion on
this?

> > 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.
> 
> I'd think you'd just run that as ExecStartPre in your auditd service.
> Perhaps that's not the best example?

I discussed this in length actually with the audit folks two days
ago. Because starting auditd is kinda slow they'd prefer to to that as
part of late bootup, i.e. like any other service. However, the policy
should be loaded early, so that events for the early boot process are
properly generated. i.e. to speak in the terms of the old fedora boot:
the policy loading should ideally happen in rc.sysinit, while the daemon
itself should be started with a sysv script.

(It's actually even more complex: for govt folks there'll be an
alternative auditd.service version (called auditd-early.service or so)
which can be enabled optionally as part of sysinit, so that it can be
guaranteed that no audit events are lost at the price of delaying the
boot)

So yepp, I think the audit policy loading is actually a good example
here ;-)

> I think it might still make sense to separate them. You'd have other
> benefits by distinguishing them:
> 
> - Separate defaults that make sense (Restart=on-success for services,
>   Restart=once (or not even a valid option) for tasks)
> - Separated reporting, if you wanted (the random example above could
>   be considered as 'finished' instead of 'active/exited'.) This
>   may not fit fully into how systemd is organized.
> 
> > (Oh, and if you have a better suggestion for a name of ValidNoProcess= I
> > am all ears too!)
> 
> Well, the neat thing about splitting off task and service like this
> is that that key goes away.

Hmm, still not convinced. ;-)

Here's another reason: historically, sysv init scripts are used for both
tasks-style and service-style stuff and systemd would have no way to
figure out which kind is which, to expose them properly. While that
probably doesn't matter too much for fedora, where everything is done in
one single sysinit script which is not LSB conforming in anway it
actually matters to other distros. Example: on suse early boot scripts
also carry LSB information and can be started in parallel. Some of them
are more service-like (e.g. the one that runs spawns udev very early on
bootup) and others more tasks-like (e.g. fsck). And we couldn't figure
out just by prsing the LSB headers what type this is. On Fedora we have
a couple of services like this, too, such es iptables.

Of course, we could depart from SysV here and even though SysV does not
distuingish the types we could distuingish them in systemd, but if we do
this then we probably should have really really good reasons for it...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.