[11:38] morning [11:38] ion_: around? [11:49] * Keybuk needs to bounce an idea off someone :p [13:15] keybuk: Yeah [13:15] ion_: so I've been thinking about the whole problem of job environment [13:15] let's use the getty job as an example [13:16] env SPEED 38400 [13:16] instance $TTY [13:16] exec /sbin/getty $SPEED $TTY [13:16] we can fire off a couple of these for the system consoles [13:16] start getty TTY=tty1 [13:16] start getty TTY=tty2 [13:16] start getty TTY=tty3 [13:16] and we can figure up one for a slower serial console [13:16] start getty TTY=ttyS0 SPEED=14400 [13:17] environment from the start request overrides that from the job definition, so env sets "defaults" [13:18] so that all works nicely [13:18] now, what happens when another job uses those events [13:18] start on started getty [13:18] which getty? there's lots of gettys running [13:18] we do have the INSTANCE variable in that event we could use [13:19] start on started getty INSTANCE=tty1 [13:19] and that happens to work for this [13:20] so using a different example, the dbus session bus daemon service [13:20] instance $USER [13:20] exec /sbin/dbus-daemon --session [13:20] env DBUS_SESSION_BUS_ADDRESS=... [13:20] another job might do [13:20] start on started dbus-session-bus [13:21] but it doesn't have access to the session bus address [13:21] Yeah [13:21] since it exists in the job environment of the dbus-session-bus job [13:21] and isn't in the starting/started/stopping/stopped events [13:21] even getty starts to have a useful example [13:21] start on starting getty TTY=ttyS* [13:22] exec setserial $TTY $SPEED [13:22] suddenly we have a case where we might want to run setserial if we're starting a getty with a particular $TTY (rather than just instance name) and want the speed [13:23] so I was thinking about adding the whole job environment to the events [13:23] but I don't think that works at all [13:23] in particular, if the job's started on a failed event, any job starting on that would be indistinguishable from the same failed event info [13:23] and it just leads to massive environment creep [13:24] so what I came up with was: [13:24] env SPEED=38400 [13:24] instance $TTY [13:24] export TTY SPEED [13:24] exec /sbin/getty $SPEED $TTY [13:24] ie. a job definition can "export" some of its environment [13:24] and those are the variables that will be added to its starting/started/stopping/stopped events automatically [13:24] Looks good [13:25] do you think that's better than exporting nothing or exporting everything? [13:26] Exporting everything would work, too, if the other jobs acting on those events can select what to import instead of having their environment polluted. [13:26] yeah, but I couldn't think of a good syntax from that [13:26] and that would start to mean you need to declare import for everything [13:26] Yeah [13:27] start on tty-added [13:27] What you proposed seems good to mee. [13:27] me [13:27] stop on tty-removed TTY=$TTY [13:27] import TTY from tty-added [13:27] (you'd need the latter to be consistent) [13:27] I kinda like the fact that if you mention an event, you automatically get its environment [13:27] and having consistency between what you can match on and what you can use is nice too [13:28] Yeah [14:25] of course, _now_ I notice a problem with taking away job ids [14:25] jobs with just "instance" can't be uniquely dealt with [15:08] * Keybuk tries to think of a reason to support unlimited instance jobs [15:23] can't think of a good one [15:23] if people really want them, they can just do something like [15:23] instance $UUID [15:23] start job UUID=$(uuidgen) [15:31] Yeah [15:33] after racking my brain I can't think of _any_ [15:33] if it acts on an event, it needs at least one environment variable to know what to do [15:33] if it acts on a device or path, it can instance on that [15:33] if it writes to the disk, it needs to instance on that path [15:33] etc. [15:34] unlimited instance jobs inherently can't lock anything, or have any side-effects [15:34] and I can't think of anything like that [15:38] Yeah, i can’t think of one either. [17:00] sweet [17:01] I just worked out something that will now work [17:01] assuming that telinit places $RUNLEVEL and $PREVLEVEL in the runlevel event, and sets utmp/wtmp (which is the plan) [17:01] /etc/init/jobs.d/rc: [17:01] start on runlevel [17:01] stop on runlevel [!$RUNLEVEL] [17:02] [17:02] export RUNLEVEL [17:02] [17:02] console owner [17:02] session leader [17:02] exec /etc/init.d/rc $RUNLEVEL [17:03] rather than having rc2,3,4,5, etc. [17:07] Nice