slangasek | I'm trying to think through why that's not simply a bug in the current importer, fixable by having richer annotations in the loom data | 00:00 |
---|---|---|
xnox | bug 911496 | 00:00 |
xnox | http://pad.lv/911496 | 00:00 |
xnox | because given one source package in can now have one or many states (the debian one or the ubuntu one) for each version =/ and it all gets hairy. | 00:01 |
slangasek | ah right, because then you're trying to do a merge from the Debian branch into the Ubuntu branch, and use the looms for it, but the Debian branch's loom doesn't actually represent what you'd be merging | 00:02 |
xnox | =) yeap. | 00:02 |
xnox | i think it was a bad idea to introduce series.vendor | 00:03 |
xnox | anyway =) i want tea and need to send in patch pilot report. | 00:04 |
slangasek | :) | 00:05 |
jodh | xnox/stgraber: comments please - https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions#Shutdown_Details | 11:55 |
stgraber | jodh: looking | 14:30 |
stgraber | jodh: wow, we end up with a pretty complex logout sequence but I guess it makes sense ;) We'll need to restrict the shutdown command to --user for now to avoid people trying to use it against PID 1. | 14:35 |
jodh | stgraber: It might need some tweaks, but it's as fair as I could make it whilst also having reasonable performance. | 14:36 |
jodh | stgraber: agreed - this is for Session Inits only for this cycle :) | 14:36 |
jodh | stgraber: an alternative could be that we handle the entire shutdown from a job, but I'm not particularly in favour of that as we don't have sufficient control over the other jobs. | 14:38 |
jodh | stgraber: do you know the desktop suspend path? That's the only scenario not covered in that section. | 14:45 |
stgraber | jodh: I think the desktop suspend path is pretty much a direct call to pm-suspend, I'm not sure gnome-session is really involved there | 14:46 |
jodh | stgraber: ack. I wonder if adding a pm-suspend hook that emits a 'resumed' event would be useful? | 15:02 |
stgraber | jodh: yeah, I guess having suspend/resume events would be nice and will be easy enough to do | 15:19 |
xnox | jodh: do we not have those system wide? or we just come back and assume the laptop is still in the same country connected to the same Heathrow airport wifi hot spot? | 15:22 |
xnox | is this point were I am being pressed for :: events?! =) | 15:24 |
jodh | xnox: we don't have such events atm, but yeah, it should be at the :sys: level. | 15:25 |
stgraber | jodh: just saw your e-mail, looks like that branch isn't based on the right upstream branch, let me fix that :) | 15:26 |
stgraber | (I didn't modify any .conf in my branch, so I must have messed up its base yesterday when debugging upstart) | 15:27 |
jodh | stgraber: ok, np. | 15:27 |
addisonj | looking at this post: http://serverfault.com/questions/128605/have-upstart-read-environment-from-etc-environment-for-a-service, is this still the best way to properly source an environment? | 17:38 |
xnox | addisonj: yes, but tbh it's best to only source the only environemt variable you want / need like guested in the second answer. | 17:44 |
addisonj | xnox: so setuid/setgid doesn't do anything PAM? just runs the daemon with that uid/gid set? | 17:45 |
xnox | yes. | 17:45 |
addisonj | xnox: yeah, problem is, we inject config into our application servers through env vars and don't want to maintain that list elsewhere... | 17:45 |
xnox | I believe, you can check the source code should be easily done. | 17:45 |
xnox | addisonj: but you do have that list somewhere right?! | 17:46 |
addisonj | chef writes it out to /etc/environment | 17:46 |
xnox | addisonj: on debian/ubuntu systems it is typical to have /etc/defaults/mydaemon which is user editable file for configs. | 17:46 |
xnox | addisonj: chef can also write out /etc/init/mydaemon.overrides which includes partially the stanzas you need with environmental variables you need. | 17:47 |
xnox | s/overrides/override/ | 17:47 |
xnox | which upstart will apply on top of the .conf file. | 17:47 |
xnox | (patch-style replacing individual stanzas) | 17:47 |
addisonj | oh, cool, didn't know that | 17:47 |
xnox | see cookbook | 17:47 |
xnox | http://upstart.ubuntu.com/cookbook/ | 17:48 |
addisonj | right now, we just use su and run it as our non-privileged user with env sourced, which has worked | 17:48 |
addisonj | but now I am trying to do a reload but the SIGHUP isn't getting through to me process | 17:48 |
* xnox wonders if upstart is tracking su pid, instead of daemon pid. | 17:49 | |
addisonj | i believe it is | 17:49 |
xnox | does $ status mydaemon matches the pid of the daemon queried via ps? | 17:49 |
addisonj | oh, lemme check, never thought of doing that | 17:50 |
xnox | cuase if it doesn't upstart is sending SIGHUP to something else =)))) | 17:51 |
xnox | (also see cookbook on establishing fork count) | 17:51 |
addisonj | yeah, the pid is the su process | 17:51 |
* xnox recommends to avoid su / sudo in upstart jobs | 17:52 | |
addisonj | so I just need to do expect fork 2 or something and it should work I imagine? | 17:52 |
xnox | http://upstart.ubuntu.com/cookbook/#expect-daemon | 17:52 |
xnox | expect daemon | 17:52 |
addisonj | yeah... thats why I was asking about proper PAM support so I could avoid that, maybe I shall hack something up to properly source env as part of the job | 17:52 |
addisonj | on another note however, upstart is quite awesome :) I much prefer it to init.d | 17:55 |
xnox | addisonj: http://paste.ubuntu.com/1538257/ | 17:56 |
xnox | example of script stanza that sources config file with envrionment variables and then executes fork. | 17:57 |
xnox | you can have setuid/setguid stanzas up there if you need to change user. | 17:57 |
xnox | this way you track "expect fork" & don't need su | 17:58 |
addisonj | hrm, interesting, I think the only problem with that is that /etc/environment vars don't do an export :\ but I think ican make it work with someting like that | 18:00 |
xnox | . /etc/environment | 18:06 |
xnox | export $PATH | 18:06 |
xnox | export $socks_proxy | 18:06 |
xnox | or whichever you need. | 18:06 |
xnox | or make chef write out sourcable / exportable /etc/environment | 18:07 |
addisonj | yeah, I shall figure something out, but you have been quiet helpful, many thanks | 18:08 |
xnox | np. | 18:21 |
stgraber | jodh: ping | 19:33 |
stgraber | jodh: ping? | 19:41 |
depesz | hi. first of all - i never had to write init scripts for upstart. but today is the day. So, I have a program, pgbouncer, that I can start, or stop, and it works fine. | 20:43 |
depesz | but. this program has also full online restart mode. where I run it using special parameters, and it takes over job of previously running copy. but the new copy has different pid, and upstart doesn't knwo it's still running | 20:44 |
depesz | do you know of any way to let upstart know that pid of a service has changed ? | 20:44 |
JanC | depesz: I suppose you mean it does a handover between 2 instances of the program so that there is no "gap" during the restart? | 21:05 |
JanC | no availability gap | 21:06 |
depesz | i am not sure about how it works internally, but as far as I understand - there is no gap as in "moment in time when there is no pgbouncer" | 21:07 |
depesz | there is always some pgboucner running, but it can online restart/upgrade | 21:07 |
JanC | maybe you could do some trickery by only using pre- & post- scripts but no main exec/script | 21:09 |
JanC | but it's certainly something where upstart could improve | 21:09 |
xnox | depesz: JanC: in this case you should use instances and restarting actually should stop one instance and start another. | 21:25 |
xnox | this way you can achieve & monitor the overlap as well. | 21:25 |
depesz | xnox: but i don't want to use restart. | 21:25 |
depesz | as restart does stop+ start. | 21:25 |
depesz | the built-in (in pgbouncer) is much better | 21:26 |
xnox | depesz: you can override in pre-stop script what actually happens during stop+start combo. | 21:26 |
xnox | depesz: detect that restart was requested and perform the pgbouncer handover. | 21:26 |
xnox | I am giving you a method how to use the built-in pbuilder restart & let upstart track the new pid. | 21:27 |
depesz | hmm .. ok | 21:27 |
JanC | xnox: that's more or less what I suggested, but there should probably be a more user friendly way to express that in upstart | 21:28 |
xnox | 90% things are trivial 10% are easy enough to achieve ;-) pre-stop scripts are unusual but it's not the end of the world. | 21:30 |
JanC | xnox: still, having syntax for it makes it easier to understand what the config does | 21:55 |
JanC | that's why sysvinit scripts have a semantic difference between restart & reload, for example | 22:02 |
xnox | JanC: so does upstart. it has both reload and restart | 22:05 |
JanC | except reload & restart are still (mostly) hardcoded | 22:06 |
JanC | and reload breaks if it causes the daemon to "switch" to another PID | 22:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!