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