1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
logging of processes
shutdown - this is going to be need some special casing, as we're
going to need to send a further poweroff or halt event after the
shutdown event has been processed; we'll need to know about system
harmony to be able to do that.
send the job description in the status event, so logd can just
subscribe to that ;)
handle location of pid/binary for spawned daemons
deal with instances
query value of event
per-user services
use pam (and thus read /etc/environment) to set up child process
environment from event
file descriptors from event
register services
temporal events
scheduled times
load average checking
respawning too fast (even if it goes through waiting and not
respawning)
ctrl-alt-delete and powerfail, etc.
The current system of using job names for their associated events
isn't going to be, in the long term, ideal. While it's the simplest
design, I think that something more clever is going to be desired.
Another problem, with a related solution, is that dependencies are
only useful for services as they're triggered when there's a process
running. Tasks need them to be triggered when the process has
stopped.
Perhaps the solution is to replace the level event for a job with an
edge event, and have that triggered at either running or stopping as
appropriate. This would release dependencies. This would mean you
couldn't be specific as to the state, or watch for state changes
though.
Would be nice if we could use the "spawned" state for other things
daemon-related too, like having a script that indicates whether the
daemon is actually running yet or not -- useful for "not running until
it listens on port 80"
|