[00:40] <tartar> I have a pair of conf files, one for a service SERVICE.conf and another for a task blocking its dependants from starting earlier, SERVICE-block-dependants.conf.
[00:41] <tartar> How do I block the pre-start of SERVICE.conf until mounted MOUNTPOINT=/ ?
[00:43] <tartar> Currently I wait for a writeable directory the service needs in its pre-start and absence of *fsck* processes.
[00:46] <tartar> This worked around the scenario when the dependants start early in /sbin/init, running "start SERVICE".  At that point / still mounts in memory and an mountall runs fsck for the root disk partition.  That fsck process may take a minute or more on exceeding the maximum count.
[00:47] <tartar>     while ! test -w /var || killall -0 --regexp fsck ; do
[00:47] <tartar>          sleep 1
[00:47] <tartar>      done > /dev/null 2>&1
[00:48] <tartar> But this still suffers from a timing window between the exit of fsck and the mount of /.
[00:50] <tartar> I would rather depend on "mounted MOUNTPOINT=/", but I find difficult to inject this hook into the pair.
[00:52] <tartar> It does not matter how long fsck runs, the timing window would present the same probability for SERVICE to use the fake /var.
[00:53] <tartar> If that happens, mountall's mounting / against the real disk partition causes the loss of file entries the service created in the fake /var.
[01:04] <tartar> I could use the output of "df /var" to tell if /var belongs in a disk, but this does not look as nice as "mounted MOUNTPOINT=/".
[01:07] <tartar> It would be nice if I could use a conjunction "and" against a set of "or" hook events in SERVICE-block-dependants.conf, but I heard this suffered from a bug and I am stuck with Lucid for now.
[01:11] <tartar> Using "and" in SERVICE-block-dependants.conf would mix up the existing hook events for SERVICE's dependants with the new hook event for SERVICE's requisite.  This would complicate reasoning for the SERVICE-block-dependants.conf.
[01:15] <tartar>  
[01:16] <tartar> To sum up, I need to wait for a hook or pass if the hook already went by.
[01:16] <tartar> Can initctl do that?
[01:24] <tartar> Alternatively, I would love to "initctl emit wait-for-mountall MOUNTPOINT=/" if mountall could receive upstart events.
[01:33] <tartar> I guess some mountall-watch.conf could "start on wait-for-mountall MOUNTPOINT=/ and mounted MOUNTPOINT=/"?  Will Lucid's upstart wait for 2 hook events in any succession before returning control to the above "initctl emit"?
[01:35] <tartar> I do not need MOUNTPOINT=/ in wait-for-mountall.
[01:41] <tartar> To shorten that, I do not need to send a hook, I could just "start on starting SERVICE and mounted MOUNTPOINT=/" in some root-block-SERVICE.conf.
[05:07] <keshav89> Hello everyone
[05:07] <keshav89> I am a newbee in upstart
[05:07] <keshav89> Just got to know about upstart
[05:07] <keshav89> as I was searching for a process management tool
[05:08] <keshav89> Requirement was running my flask app forever
[05:08] <keshav89> Basically I have ubuntu VM to which I ssh and run my "python flaskapp.py" - which starts a dev server
[05:09] <keshav89> but if ssh connection breaks that server comes down
[05:09] <keshav89> came to know about gunicorn and then upstart 
[05:09] <keshav89> read the doc of upstart a bit
[05:10] <keshav89> Here is what I understand:
[05:10] <keshav89> 1. I need to write one simple myflask.conf
[05:10] <keshav89> 2. Plcae it under /etc/init/
[05:10] <keshav89> *Place
[05:12] <keshav89> 3. in that script I will write something like : "pre-script chdir <flask_dir> end script exec python flaskapp.py"
[05:12] <keshav89> Am I correct?
[05:12] <keshav89> with script i meant myflask.conf which will be placed under /etc/init/
[05:13] <keshav89> Any help or assistance appreciated
[05:17] <keshav89> oh I should also have this line in the .conf file : "start on startup" right?
[05:31] <keshav89> anybody?
[05:32] <keshav89> :-[
[11:59] <keshav89> I have a small conf file under /etc/init/
[11:59] <keshav89> Which I am trying to run
[11:59] <keshav89> with initctl
[12:00] <keshav89> start on startup
[12:00] <keshav89> pre-start script
[12:00] <keshav89> # Changing directory to flask app
[12:00] <keshav89>    chdir /usr/src/test/ans/
[12:00] <keshav89> end script
[12:00] <keshav89> script
[12:00] <keshav89>    gunicorn -b 0.0.0.0:1234 testflask:app
[12:00] <keshav89>    console output
[12:00] <keshav89> end script
[12:00] <keshav89> Basically I am trying to keep flask server running
[12:01] <keshav89> Am I doing something wrong?
[12:01] <keshav89> I am trying initctl start myflask.conf
[12:16] <keshav89> Anyone?
[12:33] <keshav89> http://paste.ubuntu.com/5598674/
[13:38] <xnox> tartar: http://upstart.ubuntu.com/cookbook/ see "how to block another job"
[13:38] <xnox> you can create a job which will block your main one, until complete. I think that will work for you.
[13:39] <xnox> keshav89: http://upstart.ubuntu.com/cookbook/#chdir stanza?
[17:58] <jamescarr> SpamapS: this is a shot in the dark, but your name came up when I was frantically googling for libmysqlclient-dev help on ubuntu :)
[17:58] <jamescarr> SpamapS: do you know where I might find one of the maintainers on irc? Or at least someone familiar with it?
[18:15] <jamescarr> SpamapS: never mind, I see you're one of them
[19:05] <SpamapS> jamescarr: I'm a maintainer yes. Want to chat in #ubuntu-devel ?
[19:05] <jamescarr> sure
[19:06] <preyalone> I like to start little web servers on boot. I've been using upstart, but often my scripts fail, causing important services like sshd to fail to start. What's a safer way to do this?
[19:08] <jamescarr> preyalone: I've never seen sshd not get started, are you fooling with the maintainer provided upstart scripts?
[19:10] <preyalone> jamescarr: I haven't fooled with anything. I recently upgraded my hardware (I use Gandi VPS hosting), and the sysadmin helping me with the upgrade mentioned that when my upstart scripts fail, it can cause things like sshd to not start up.
[19:10] <SpamapS> preyalone: thats b.s.
[19:11] <jamescarr> yah what SpamapS said
[19:11] <preyalone> Understood.
[19:11] <SpamapS> preyalone: can you share your upstart job that sometimes fail?
[19:11] <jamescarr> just because an upstart script fail doesn't keep others from running
[19:11] <SpamapS> preyalone: I'd bet that you're starting things too early
[19:11] <preyalone> In any case, I've noticed that my upstart scripts DO fail a lot, so when my server restarts, I'll notice that a service isn't running at all. Example: https://github.com/mcandre/node-ios7crypt/blob/master/upstart.conf
[19:11] <SpamapS> jamescarr: well, a failing job could certainly have also somehow cancelled another one. But.. yeah
[19:12] <SpamapS> yep
[19:12] <SpamapS> preyalone: man upstart-events
[19:12] <SpamapS> preyalone: startup is *WAY* too early
[19:12] <SpamapS> preyalone: no network, no disks, nothing
[19:12] <SpamapS> preyalone: its only by a miracle that 'start on startup' ever works.
[19:12] <SpamapS> preyalone: you want 'start on runlevel [2345]'
[19:12] <preyalone> SpamapS: Thanks. :P
[19:13] <SpamapS> preyalone: also, 'shutdown' is not an event. So you want 'stop on runlevel [016]'
[19:13] <SpamapS> man
[19:13] <SpamapS> there are a few examples that use those two events
[19:13] <SpamapS> and they are like *weeds*
[19:13] <SpamapS> kill 1, 5 more pop up
[19:16] <preyalone> Can upstart scripts use hard tabs, soft, or what?
[19:18] <SpamapS> preyalone: doesn't matter
[19:18] <SpamapS> preyalone: they are not whitespace sensitive
[19:18] <preyalone> Is that standard for .conf files, or just upstart .conf files?
[19:23] <SpamapS> upstart
[19:23] <SpamapS> .conf means nothing
[19:24] <SpamapS> /etc/init/*.conf == upstart
[19:31] <preyalone> SpamapS: Thanks for the info. I'm just thinking about configuring indentation in my text editor.
[20:06] <preyalone> My Rails app works when I start it manually. But when I try to call the same command via upstart, my server doesn't start up. https://github.com/mcandre/doesrailswork/blob/master/upstart.conf
[20:08] <xnox> preyalone: no need to use script, the exec and chdir are top level stanzas just like "start on"
[20:09] <preyalone> xnox: Thanks, but that doesn't alter the behavior.
[20:09] <xnox> there is no command line executable "chdir" so that's where the script fails.
[20:10] <xnox> as the whole script is executed as if it's shell, with set -e
[20:12] <preyalone> "rails server" needs to be executed in a specific current directory. What's the best way to do this in upstart?
[20:19] <preyalone> xnox: I tried moving chdir and exec outside of script, but the problem still exists: the Rails app isn't running after I do "sudo start doesrailswork".