[15:39] <Laney> Hello upstart friends! I'm after some help writing a user-session job for monkeysphere-validation-agent. It's usually run from Xsession.d in the usual manner taking another program to spawn, but can also run in the foreground, in which case it outputs some shell to be evaluated (setting the important env variable).
[15:41] <Laney> Not really sure how to deal with this
[16:10] <jodh> Laney: I think stgraber was looking at that at the client sprint. We had a similar headache with dbus but circumvented the problem with dbus-launch by calling dbus-daemon directly after first setting the required env var (see /usr/share/upstart/sessions/dbus.conf)
[16:12] <jodh> Laney: problem is that you need the env var to be exported to the Session Init environment using 'initctl set-env', but you can't do that if the program is in the foreground (unless the value of that env-var is fully predictable? *shudder*)
[16:12] <Laney> correct, and it is of course not predictable (or settable AFAICT)
[16:13] <Laney> all I can think of is somehow reinventing parts of the STARTUP mechanism in jobs
[16:13] <Laney> hmm, or having some helper script which does the work (msva-perl my-cool-script)
[16:14] <jodh> Laney: that sounds workable - just have it call 'initctl set-env' and sleep forever.
[16:16] <Laney> jodh: yeah, let me try that
[16:16] <Laney> funny how thinking out loud makes these things turn up
[16:17] <jodh> Laney: yeah :)
[16:32] <stgraber> Laney: sounds like you're doing the same thing I did at the client sprint (go through all packages shipping something in /etc/X11/Xsession.d and fixing those that break under upstart)
[16:33] <Laney> yeah
[16:33] <Laney> plus I happen to use this one so it seems like a good place to start :-)
[16:33] <stgraber> Laney: FWIW when I did that at the client sprint, I only noticed gpg-agent (which I fixed) and monkeysphere-validation-agent which I chose to ignore
[16:33] <stgraber> ah, so people actually use this thing? good to know ;)
[16:35] <stgraber> I chose to ignore it on the basis that nobody in the foundations room knew what it was, the code wasn't terribly readable and it wasn't easy at all to figure out how to run that thing on my machine for testing ;)
[16:37] <Laney> heh
[16:37] <Laney> it probably requires some time investment to set it up
[16:40] <Laney> initctl set-env from the script doesn't work though
[17:16] <Laney> hmm, it /is/ in list-env, but not in my session's environment
[17:33] <Laney> ah, so if I block in post-start until it's set then I get it there
[17:33] <Laney> stgraber: jodh: how would you do that?
[17:43] <stgraber> Laney: hmm, so I'm not completely clear on what's the problem you're having
[17:45] <Laney> soooooooo I call a script as an argument of the main program which does initctl set-env --global foo=bar and then sleeps indefinitely
[17:45] <Laney> but I need to block the job from completing until the set-env has finished, otherwise the env var isn't set in the session
[17:49] <Laney> One option would presumably be to use an event to signal when it's ready
[17:51] <stgraber> ah, I suppose that's because monkeysphere-validation-agent actually exits when the wrapped software returns and there's no way to have it not do that?
[17:52] <Laney> correct
[17:54] <stgraber> so I think the way I'd do it is with a job having only a pre-start and post-stop section (similar to ssh-agent.conf). In pre-start you'd call monkeysphere-validation-agent with a script which prints the environment variables. You'd pipe that output into (while read line; do ...; done) so you can parse the output and when done, just leave the process running in the background
[17:54] <stgraber> similarly to ssh-agent.conf, you'll want to set an environment variable containing the PID of monkeysphere-validation-agent so that you can kill it in post-stop and then unset all the variables
[17:56] <stgraber> though the cleanest way to solve this may be to patch monkeysphere-validation-agent to support just printing the environment variables and then forking into the background (similar to what gpg-agent and ssh-agent do)
[18:00] <Laney> mmm, I'll try that out tomorrow and see what it's like, thanks
[18:01] <stgraber> not sure how active upstream is, but I don't think it'd be unreasonable for them to merge a --print-env or similar function that implements a behaviour similar to gpg-agent/ssh-agent, that'd definitely be my preference
[18:03] <Laney> pretty sure he's fairly active
[18:03] <Laney> you could then basically do the same as the *-agent jobs