| Keybuk | morning | 11:38 |
|---|---|---|
| Keybuk | ion_: around? | 11:38 |
| * Keybuk needs to bounce an idea off someone :p | 11:49 | |
| 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:15 |
| 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:16 |
| Keybuk | environment from the start request overrides that from the job definition, so env sets "defaults" | 13:17 |
| 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:18 |
| Keybuk | start on started getty INSTANCE=tty1 | 13:19 |
| Keybuk | and that happens to work for this | 13:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| Keybuk | do you think that's better than exporting nothing or exporting everything? | 13:25 |
| 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:26 |
| 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:27 |
| ion_ | Yeah | 13:28 |
| 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 | 14:25 |
| * Keybuk tries to think of a reason to support unlimited instance jobs | 15:08 | |
| 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:23 |
| ion_ | Yeah | 15:31 |
| 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:33 |
| 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:34 |
| ion_ | Yeah, i can’t think of one either. | 15:38 |
| Keybuk | sweet | 17:00 |
| 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:01 |
| 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:02 |
| Keybuk | rather than having rc2,3,4,5, etc. | 17:03 |
| ion_ | Nice | 17:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!