| semiosis | i'm working on writing an upstart job that will start a service after the network interface is up, but before remote filesystems are mounted. or at least start the service after the network interface is up, then reattempt mounting of remote filesystems. emitting remote-filesystems doesnt seem to have any effect on the _netdev entries in /etc/fstab. any ideas? | 18:16 |
|---|---|---|
| semiosis | this is on ubuntu maverick | 18:16 |
| Keybuk | semiosis: a lot of that stuff is custom to Ubuntu | 18:21 |
| semiosis | i'm sure it is. any pointers? | 18:26 |
| Keybuk | I've no idea, sorry | 18:33 |
| Keybuk | I haven't been able to keep track of Ubuntu's fork so far | 18:33 |
| semiosis | ok, thanks anyway. i'm sure i'll figure something out :) | 18:33 |
| SpamapS | semiosis: so you really need to block the mounting of remote filesystems, right? | 19:29 |
| SpamapS | semiosis: sounds like you may need to block some of the 'mounting' events until your service is started. | 19:32 |
| semiosis | SpamapS: not sure what i need, but i figured out that emitting a 'startup' event caused a retry of the mounts. not sure what the other implications of that are though | 19:33 |
| SpamapS | semiosis: emitting startup seems a bit bass-ackwards. ;) | 19:33 |
| semiosis | SpamapS: yeah it does! | 19:33 |
| semiosis | SpamapS: but mountall service goes away, so emitting a remote-filesystems (which would trigger the mountall-net job) does nothing at all | 19:34 |
| SpamapS | semiosis: so what you want, I think, is start on mounting TYPE=nfs ... | 19:35 |
| semiosis | SpamapS: actually it's glusterfs I'm working with, but it might be similar enough | 19:35 |
| SpamapS | semiosis: mounting is a hook point, so mountall blocks on anything that uses that event... | 19:35 |
| SpamapS | Ah gluster. Ok.. is mountall "gluster aware" ? | 19:36 |
| semiosis | SpamapS: i dont know. | 19:36 |
| SpamapS | seems its not | 19:36 |
| SpamapS | so gluster will be treated like a local filesystem unless given the 'nobootwait' flag, I think. | 19:36 |
| * SpamapS is still wrapping his head around mountall | 19:36 | |
| SpamapS | so tiny, but so twisted.. :) | 19:36 |
| semiosis | SpamapS: basically, gluster service starts up & exports directories over the network (which could be eth0 or lo) then I have a client mount of the glusterfs volume in my fstab, which never gets mounted during bootup, unless i put 'mount -a' or similar in rc.local | 19:37 |
| semiosis | SpamapS: hmm that woudl explain why _netdev didnt seem to make any difference. in fact, nobootwait didnt seem to make any difference either | 19:38 |
| SpamapS | semiosis: right, you might just try adding _netdev=eth0 to the options | 19:38 |
| SpamapS | err | 19:39 |
| SpamapS | just _netdev | 19:39 |
| SpamapS | semiosis: no _netdev should make it a "remote" filesystem | 19:39 |
| SpamapS | semiosis: so you're saying in order for gluster to be able to mount a remote fs, it needs a service, right? | 19:40 |
| semiosis | SpamapS: not at all | 19:40 |
| SpamapS | Ok.. then thats very odd that _netdev didn't work | 19:40 |
| semiosis | SpamapS: this host is a server and a client, in order for it to be a client of its own served volume, the service needs to be up | 19:41 |
| SpamapS | semiosis: AHHH | 19:41 |
| semiosis | SpamapS: so the server name here is localhost | 19:41 |
| SpamapS | yeah so you *do* need it to start on mounting TYPE=glusterfs | 19:41 |
| semiosis | SpamapS: hmm i was hoping this could be solved by adding an upstart job to my custom glusterfs package, but are you saying it requires changes to mountall? | 19:42 |
| SpamapS | semiosis: you might just try a task that is 'start on mounting TYPE=glusterfs' that starts the service (exec /etc/init.d/glusterfs start) | 19:42 |
| semiosis | SpamapS: ok then where does the mounting TYPE=glusterfs event get emitted? | 19:42 |
| SpamapS | semiosis: by mountall, whenever it tries to mount glusterfs volumes | 19:43 |
| semiosis | SpamapS: ooh neat | 19:43 |
| SpamapS | and, importantly, it waits for that task to finish | 19:43 |
| SpamapS | semiosis: you could also, of course, convert glusterfs to an upstart job completely.. which would improve boot speed and be super cool. ;) | 19:44 |
| semiosis | SpamapS: thats what i'd like to do | 19:45 |
| semiosis | SpamapS: and it shouldnt be too hard, the service is super easy to manage (it really manages itself, just needs a kick) i just need to figure out these events | 19:45 |
| SpamapS | semiosis: the one tricky thing about mounting TYPE=glusterfs is you're going to see that event multiple times and sometimes the network won't be up... but don't be tempted to do 'and net-device-up' ;) | 19:46 |
| semiosis | SpamapS: actually i was thinking 'or net-device-up' | 19:47 |
| semiosis | SpamapS: but first things first | 19:47 |
| SpamapS | see if you do 'or net-device-up' you may not block mounting TYPE=glusterfs | 19:50 |
| SpamapS | unless you add instance $UPSTART_EVENTS | 19:51 |
| SpamapS | and even then I'm not sure if that will work | 19:51 |
| semiosis | SpamapS: hmm no luck yet. i've got a trivial upstart job to start glusterd, it has 'start on mounting TYPE=glusterfs' and 'exec /usr/sbin/glusterd -N -p /var/run/glusterd.pid' which will execute the daemon and have it stay in foreground (-N = no fork) | 19:55 |
| semiosis | SpamapS: now this job does get run at boot, the service is up when I login, but the mount from fstab is still not mounted | 19:55 |
| SpamapS | semiosis: one thing that may cause that to fail is that it will be considered "started" as soon as it execs glusterd .. | 19:56 |
| SpamapS | semiosis: but it may not be ready to service things yet. | 19:56 |
| semiosis | SpamapS: i also tried adding _netdev to the fstab but no effect | 19:56 |
| SpamapS | semiosis: weird. I wonder if your glusterfs partitions are even being attempted on 'net-device-up' | 19:56 |
| semiosis | SpamapS: well doing 'initctl emit -n startup' does mount the volume from fstab | 19:58 |
| SpamapS | semiosis: but.. that seems a bit .. silly. | 19:59 |
| SpamapS | semiosis: maybe just 'start mountall' | 19:59 |
| SpamapS | but even that is counter intuitive | 19:59 |
| semiosis | SpamapS: i know but as a test it suggests to me that the mount in fstab is being evaluated due to upstart events | 19:59 |
| SpamapS | semiosis: boot with '--verbose' and see if the mounting event is even being emitted | 20:00 |
| semiosis | SpamapS: the service does start up, and mounting is the only event in its 'start on' line | 20:00 |
| semiosis | SpamapS: where do I add --verbose? grub boot line? | 20:00 |
| SpamapS | semiosis: yeah | 20:02 |
| SpamapS | semiosis: ahh ok so the service does start ... then that makes me think the gluster mount just fails | 20:02 |
| semiosis | SpamapS: checking client logs... looks like it's trying the mount before the service is started, which has been the issue all along | 20:04 |
| SpamapS | semiosis: right, so you need to add a post-start to your job that spins until gluster is ready | 20:10 |
| semiosis | SpamapS: interesting, sounds reasonable, i'll work on that. | 20:11 |
| === Md_ is now known as Md | ||
| semiosis | SpamapS: you rock!!! adding a post-start script of just 'sleep 5' did the trick! now i know what's needed I can get it down to the minimum necessary. thanks for your help! :-D | 20:20 |
| semiosis | SpamapS: also as a side note, thanks for the quick tutorial on mountall & the events it generates, i've found a whole new area of man pages to study based on that quick tip. | 20:22 |
| SpamapS | semiosis: in natty, 'man upstart-events' is really good | 20:22 |
| semiosis | SpamapS: nice, i'll check that out on the web, i dont have a natty install set up yet | 20:23 |
| SpamapS | semiosis: manpages.ubuntu.com has it | 20:23 |
| semiosis | SpamapS: i'm there | 20:23 |
| SpamapS | "we're there dude" | 20:23 |
| jMCg | oh wow. I'm absolutely flabbergasted. Since when does that exist? | 20:28 |
| jMCg | O_o | 20:29 |
| jMCg | How do you fuck up man pages? | 20:30 |
| semiosis | i dont know, how? | 20:39 |
| * semiosis likes a good joke | 20:40 | |
| jMCg | semiosis: compare manpages.ubuntu.com with http://www.freebsd.org/cgi/man.cgi | 20:40 |
| jMCg | It's actually a bad joke. | 20:40 |
| jMCg | Also try finding that site from: http://www.ubuntu.com/ or https://help.ubuntu.com/ (th eofficial documentation) | 20:41 |
| jMCg | Keybuk: what's it take to port upstart to FreeBSD :) | 20:56 |
| Keybuk | jMCg: a FreeBSD developer being interested enough to do it | 20:57 |
| JanC | jMCg: the manpages site is linked from https://help.ubuntu.com/community but I agree it should probably be linked from the frontpage... | 20:59 |
| jMCg | JanC: or at least from help.ubuntu.com | 21:02 |
| JanC | yes, that's what I meant, the frontpage of the help site | 21:02 |
| Keybuk | jMCg: the trouble is, of course, that FreeBSD developers don't need Upstart | 21:05 |
| Keybuk | they still haven't moved off the one big shell script approach | 21:05 |
| Keybuk | (at least, don't think they need :oP) | 21:06 |
| mastamind | hi. can i use upstart without dbus? | 23:31 |
| ion | The daemon? Sure. | 23:31 |
| mastamind | it seems, that the tools only use dbus to communicate with the daemon. | 23:32 |
| mastamind | shutdown, telinit, ... | 23:32 |
| ion | The daemon? Only optionally if it happens to be there. | 23:32 |
| mastamind | sysv_change_runlevel requires dbus. | 23:33 |
| Keybuk | it requires the dbus protocol, not the dbus daemon | 23:33 |
| Keybuk | there is a miniature dbus daemon built into upstart that it connects to | 23:33 |
| mastamind | ok :-) | 23:34 |
| mastamind | so the upstart daemon will "emulate" the dbus daemon? | 23:34 |
| Keybuk | not so much, but close enough for government work | 23:35 |
| mastamind | ok | 23:35 |
| mastamind | thank you for your help. | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!