| === JanC_ is now known as JanC | ||
| steffen_b3 | hi | 15:58 |
|---|---|---|
| steffen_b3 | can we really expect all of this: https://wiki.ubuntu.com/FoundationsTeam/Specs/MaverickFinishUpstart beginning of March ? | 15:59 |
| Keybuk | that's the plan | 16:05 |
| Keybuk | Canonical has multiple people working on Upstart | 16:05 |
| Keybuk | at this point, 1, 2 & 4 are complete | 16:06 |
| steffen_b3 | ok - cool - that makes it sound feasable | 16:06 |
| Keybuk | 7 is complete, but may be changed as there's discussion going on upstream | 16:06 |
| Keybuk | 3, 6, 8, 9 & 10 are all in progress | 16:06 |
| Keybuk | so the only one not started is #5 | 16:06 |
| steffen_b3 | #5 is nice but not that important | 16:07 |
| steffen_b3 | looking forward to see the rest :) | 16:09 |
| steffen_b3 | if working as expected should simplify the jobs we have a lot | 16:10 |
| Keybuk | a little yeah | 16:16 |
| Keybuk | 0.6 still has the fundamental issue that the "start on" / "stop on" single stanzas are hard to work with | 16:16 |
| steffen_b3 | yes | 16:25 |
| steffen_b3 | and states are missing a lot | 16:26 |
| Keybuk | that's all being worked on though ;-) | 16:26 |
| Keybuk | just not for natty | 16:26 |
| Keybuk | it may end up being released around the same time though | 16:26 |
| Keybuk | so natty+1 can start straight away with a new upstart | 16:26 |
| steffen_b3 | thats fine | 16:26 |
| steffen_b3 | i'm working on yavdr | 16:27 |
| steffen_b3 | so we are not bound 100% to ubuntu releases | 16:27 |
| Keybuk | ah cool | 16:27 |
| steffen_b3 | at the moment we are using things like | 16:28 |
| steffen_b3 | LANG=C /sbin/status openbox | grep -q process && /sbin/initctl emit vdr-frontend-restart || /bin/true | 16:28 |
| steffen_b3 | or | 16:29 |
| steffen_b3 | while [ ! -e /tmp/vdr-xine/stream ] ; do sleep 0.1 ; done | 16:29 |
| Keybuk | does respawn not work? | 16:29 |
| steffen_b3 | which becomes quickly quite nasty | 16:29 |
| Keybuk | (for the former) | 16:29 |
| steffen_b3 | it should start vdr-frontend | 16:29 |
| steffen_b3 | if vdr restarts | 16:29 |
| steffen_b3 | but only if X is up | 16:29 |
| steffen_b3 | else it will respawn it until it gives up | 16:30 |
| Keybuk | ah right | 16:30 |
| Keybuk | that makes sense | 16:30 |
| steffen_b3 | by the socket activation we should get rid of the sleeps | 16:31 |
| steffen_b3 | we have more then one of it | 16:32 |
| Keybuk | yup, and the direct state support will let you better specify the former | 16:32 |
| steffen_b3 | yes | 16:32 |
| steffen_b3 | then being able to start processes as user is another thing | 16:32 |
| steffen_b3 | if i got it right it should be also possible around that time | 16:33 |
| steffen_b3 | only one problem i didn't found any solution yet | 16:34 |
| steffen_b3 | to stop the shutdown process until a service has finished stopping | 16:35 |
| steffen_b3 | at runlevel everything start to stop at the same time | 16:36 |
| steffen_b3 | including dbus | 16:37 |
| steffen_b3 | so if you want to delay it | 16:37 |
| steffen_b3 | upstart seem to hang | 16:37 |
| steffen_b3 | something like | 16:39 |
| steffen_b3 | stop on stopping rc | 16:39 |
| steffen_b3 | anyway needs a closer look in march then | 16:39 |
| steffen_b3 | mainly wanted to see if the agenda is wishfull thinking or really something behind :) - great to see its the second | 16:41 |
| Keybuk | not sure what you mean by the stopping bit? | 16:43 |
| Keybuk | I suspect you're talking about an Ubuntu bug there, rather than an Upstart problem? | 16:43 |
| steffen_b3 | i guess its an ubuntu bug | 16:44 |
| steffen_b3 | but i don't really differentiate that much | 16:44 |
| steffen_b3 | ;) | 16:44 |
| steffen_b3 | or i really can't make sure those bug that is | 16:45 |
| steffen_b3 | if a signal is delayed to after dbus has stopped | 16:45 |
| steffen_b3 | the signal never happens | 16:45 |
| steffen_b3 | for upstart | 16:45 |
| Keybuk | oh right | 16:46 |
| Keybuk | yeah D-Bus is stopped by the runlevel event, which happens in parallel to the rest of the shutdown | 16:46 |
| steffen_b3 | and dbus is stopped at runlevel | 16:46 |
| steffen_b3 | yes | 16:46 |
| steffen_b3 | so if you try to get in before rc | 16:46 |
| steffen_b3 | to delay it until the service is down | 16:47 |
| steffen_b3 | rc will never be run | 16:47 |
| Keybuk | Clint and James are working on a fix for that involving adding explicit "initctl emit" statements to the sysvinit shutdown | 16:47 |
| Keybuk | which will wait for the upstart jobs to stop | 16:47 |
| steffen_b3 | cool :) | 16:47 |
| steffen_b3 | vdr needs a couple of seconds to stop | 16:48 |
| steffen_b3 | and we try to run fsck at shutdown | 16:48 |
| steffen_b3 | at the moment fsck is not run, as the filesystem is busy | 16:48 |
| steffen_b3 | so that thing will also be taken care of by natty then i hope/guess ? | 16:49 |
| ion | Unrelated, but anyhoo: i’m using this to avoid fscks on startup: https://github.com/ion1/e2croncheck | 16:50 |
| Keybuk | steffen_b3: I would imagine so, yes | 16:51 |
| steffen_b3 | fsck on a mounted filesystem | 16:51 |
| steffen_b3 | ah on a lvm volume snapshot | 16:52 |
| Keybuk | yeah, I think fsck is one of those things the Linux world is collectively waiting for btrfs for | 16:53 |
| Keybuk | "we could fix it now, but it's hard, and btrfs doesn't need fixing" | 16:53 |
| steffen_b3 | i use xfs on the big disks | 16:53 |
| steffen_b3 | and ext4 on system | 16:54 |
| steffen_b3 | thing never seen fsck running | 16:54 |
| steffen_b3 | thing = think | 16:54 |
| steffen_b3 | " XFS is a journaling filesystem and performs recovery at mount(8) time if necessary, so fsck.xfs simply exits with a zero exit status. " | 16:55 |
| Keybuk | heh, XFS doesn't perform recovery | 16:56 |
| Keybuk | XFS abandons your data on a remote tropical island without so much a bottle of rum | 16:56 |
| steffen_b3 | :D | 16:57 |
| steffen_b3 | anyway its a lot but not mission critical data | 16:57 |
| steffen_b3 | i would prefer something reliable w/o fsck | 16:57 |
| steffen_b3 | but until then xfs works fairly well here since the last 5 years or so | 16:58 |
| Keybuk | well, you always need to fsck | 16:58 |
| Keybuk | but filesystems like btrfs support online fsck | 16:58 |
| Keybuk | so you don't need to stop everything for it | 16:58 |
| Keybuk | you just fsck when you feel a need | 16:59 |
| Keybuk | (e.g. it can go in cron) | 16:59 |
| steffen_b3 | ok let me rephrase | 16:59 |
| steffen_b3 | without waiting possibly hours for the FS to do "something" | 16:59 |
| steffen_b3 | before the machine boots/shuts down | 16:59 |
| Keybuk | indeed | 16:59 |
| steffen_b3 | not sure if btrfs is mature enough allready | 17:01 |
| Keybuk | it's at least as mature as ext4 | 17:02 |
| Keybuk | the only reason Ubuntu hasn't switched, at least for netbooks or desktops, is that there's still a licensing issue with the boot loader | 17:03 |
| Keybuk | the btrfs code, being kernel, is GPL 2 only | 17:03 |
| Keybuk | the boot loader (GRUB 2) is GPL 3+ | 17:03 |
| steffen_b3 | ok - so i should think about switching at next installation | 17:04 |
| steffen_b3 | i mean in the end its just hours of TV recordings | 17:05 |
| steffen_b3 | for my use case | 17:05 |
| Stevee | hello, i've a question / problem with upstart and a couple a network services - they should stopped bevore the network will shutdown | 17:41 |
| Stevee | so is there any change to do this without a static list of the services in the network job - like "stop on stopped service a and stopped service b and stopped service c ...." ? | 17:42 |
| steffen_b3 | you should stop them on the network signals then | 17:58 |
| steffen_b3 | not the other way around | 17:58 |
| Stevee | so you mean stop this services on "stopping network" ? | 18:00 |
| steffen_b3 | i'm not sure | 18:01 |
| steffen_b3 | but i think | 18:01 |
| steffen_b3 | net-device-down should exist | 18:01 |
| Stevee | the whole network is controlled by a python script | 18:01 |
| Stevee | so, there is no app for upstart to watch and to stop / wait | 18:02 |
| steffen_b3 | stop on net-device-down IFACE=*[0123456789] | 18:02 |
| steffen_b3 | would stop the service on any network device going down | 18:02 |
| steffen_b3 | except lo | 18:03 |
| Stevee | yes, but the service should stop bevore the network will stop | 18:03 |
| Stevee | the only way i image is, to define a kind of static list with every service | 18:05 |
| Stevee | and only if all of them are stopped the network service / job will stop | 18:05 |
| steffen_b3 | hmm | 18:06 |
| Stevee | but this list of jobs can change so this is no option | 18:06 |
| Stevee | is there any kind of define a group or something ? | 18:07 |
| steffen_b3 | you mean like create 1 job with your conditions | 18:09 |
| steffen_b3 | and let the other jobs | 18:09 |
| steffen_b3 | start on started | 18:09 |
| steffen_b3 | stop on stopping | 18:09 |
| steffen_b3 | that job | 18:10 |
| steffen_b3 | not sure if my thinking is to complex right now | 18:11 |
| steffen_b3 | but you could have a job which reacts on net-device-down (or net-device-removed?) which is checking the number of network interfaces up | 18:12 |
| steffen_b3 | if it reaches 0 or 1 (depending if you want to filter lo or not) | 18:12 |
| steffen_b3 | it issues a signal | 18:12 |
| steffen_b3 | which can stop the services | 18:13 |
| steffen_b3 | not sure if that is enough | 18:14 |
| Stevee | the amount of network interfaces also is dynamically | 18:14 |
| steffen_b3 | but not the amount of network interfaces where you would want to stop | 18:14 |
| steffen_b3 | which is 0 | 18:14 |
| steffen_b3 | allways | 18:14 |
| Stevee | that is true | 18:14 |
| steffen_b3 | net-device-added -> count++ | 18:15 |
| steffen_b3 | net-device-removed -> count-- | 18:15 |
| steffen_b3 | if count == 1 -> initctl --no-wait emit some-signal | 18:17 |
| steffen_b3 | stop on some-signal | 18:17 |
| Keybuk | you'd want to wait, surely? | 18:17 |
| Keybuk | your code would be: | 18:17 |
| Keybuk | initctl emit net-going-down | 18:17 |
| Keybuk | ifdown ... | 18:17 |
| Keybuk | initctl emit net-down | 18:17 |
| Keybuk | if you used --no-wait, you'd tear down the network without waiting for the services to stop | 18:17 |
| steffen_b3 | good point | 18:18 |
| Stevee | oh there is a own event net-going-down ? | 18:18 |
| Keybuk | Stevee: there is if you make one | 18:18 |
| steffen_b3 | :D | 18:18 |
| Stevee | yes, clearly, we emits that | 18:18 |
| Keybuk | Upstart has no fixed list of events | 18:18 |
| Keybuk | it's up to you to emit them when you want them | 18:18 |
| Keybuk | and up to you to decide when you emit whether or not you want to wait for Upstart to finish | 18:19 |
| Keybuk | an Ubuntu machine, for example, has a "net-device-down" event - but this isn't waited for | 18:19 |
| Keybuk | because Ubuntu takes the position that you can't control a network device going down, it could go down because the WiFi is out of range, because the user hit the kill switch, because the user pulled out the network cable or card, etc. | 18:19 |
| Keybuk | so since you can't guarantee "service is stopped before network goes down", it doesn't provide that facility | 18:19 |
| Keybuk | that's not an Upstart limitation though, just an Ubuntu policy decision | 18:20 |
| Stevee | yes, so my point is to kill all network services with an event | 18:22 |
| Stevee | and after they all has been stopped, to shut down the network | 18:23 |
| Stevee | but my only idea to perfom that is a kind of static list | 18:23 |
| Keybuk | nah | 18:23 |
| Keybuk | you can just use an event for that: | 18:23 |
| Stevee | like "stop on stopped service a and stopped service b and so on" | 18:23 |
| Keybuk | in your code just do: | 18:23 |
| Keybuk | initctl emit kill-all-network-services | 18:23 |
| Keybuk | ifconfig ... down | 18:24 |
| Keybuk | then the jobs that need to be killed have: | 18:24 |
| Keybuk | stop on kill-all-network-services | 18:24 |
| Stevee | yes | 18:24 |
| Keybuk | you don't need any kind of static list | 18:25 |
| Stevee | if i put this initctl kill-all-network-services into a jobfile | 18:26 |
| Stevee | will upstart wait on executing the next command ? | 18:26 |
| Keybuk | yes | 18:26 |
| Stevee | so at first it emits the event | 18:26 |
| Stevee | the services will stop | 18:26 |
| Stevee | and than it will shutdown the network ? | 18:27 |
| Keybuk | yup | 18:27 |
| Stevee | great, thanks | 18:27 |
| === Keybuk changed the topic of #upstart to: Upstart 0.6.7 "Return of the Mole" | http://upstart.at/ | ||
| Stevee | how is the correct syntax: stop on kill-all-network-services or stopped network ? | 19:00 |
| Keybuk | the two syntaxes are both correct, depending what you want to do | 19:07 |
| Stevee | both | 19:08 |
| Keybuk | then that's correct two | 19:08 |
| Keybuk | too | 19:08 |
| Stevee | thanks | 19:08 |
| Keybuk | that'll say stop on the k-a-n-s event OR if the network job gets stopped without emitting that event | 19:08 |
| Stevee | yes thats correct | 19:08 |
| Stevee | if the network ist stopped manually the net-services also should stop | 19:09 |
| Stevee | is it possible to add multiple initctl emit xyz init a script blog of a jobfile ? | 19:10 |
| Stevee | init = into | 19:10 |
| steffen_b3 | bye all :) | 19:10 |
| Stevee | good bye | 19:10 |
| Stevee | thanks for the help | 19:11 |
| Stevee | to slow :( | 19:11 |
| Stevee | Keybuk thanks for your great help | 19:24 |
| Keybuk | Stevee: sure, as many as you want | 19:47 |
| mbiebl | Keybuk: start on socket ... vs start on dbus-activation ... | 19:54 |
| mbiebl | would be nice to either add -activation to socket or drop -activation from dbus | 19:54 |
| Keybuk | mbiebl: yeah, they're just drafts at the moment | 20:06 |
| Keybuk | going to send the new draft of the dbus patches to the ML in a bit | 20:14 |
| Keybuk | been a week since the discussion on the common interface tailed off, so a good time for an RFC + patches to get it going again | 20:14 |
| Stevee | gn8 @all - thanks for hel | 20:45 |
| Stevee | p | 20:45 |
| ion | thanks for hell | 21:02 |
| Keybuk | ;- | 21:46 |
| Keybuk | ;-) | 21:46 |
| Keybuk | mbiebl: right, that's those patches sent | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!