On Thu, 12.08.10 11:59, Bill Nottingham (nott...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
