[07:05] <vanguarde9> Hello hackers
[07:06] <vanguarde9> I have simple upstart script 
[07:06] <vanguarde9> but its not working as it should
[07:06] <vanguarde9> can somebody point me what can be wrong ?
[07:06] <vanguarde9> http://pastebin.com/b0vydm7j
[07:07] <vanguarde9> Im using variable $PORT in it 
[07:07] <vanguarde9> when I make echo $PORT >> some file
[07:08] <vanguarde9> Its properly wrintten into file
[07:08] <vanguarde9> but when I use it as argument , aplication fails to start
[07:10] <vanguarde9> Also any suggestion to improve this upstart service are welcomed
[07:14] <vanguarde9> I used upstart 0.6.5 from Centos 6
[10:55] <ion> vanguarde9: An Upstart job instance won’t track two processes. Also, “expect fork” might not match the exact forking behavior of the program even with one process. It might be better to avoid forking altogether.
[18:09] <Tv`> I can't seem to get "start on file" to work in 13.04
[18:10] <Tv`> what can i do to debug it? i see upstart-file-bridge activity in strace when i fiddle with the files, but it doesn't seem to trigger the event
[18:22] <Tv`> okay so now i can trigger it manually, but postfix delivering mail into a maildir doesn't trigger it.. curious
[18:24] <Tv`> let's do the same link trick as proper maildir delivery does..
[18:24] <Tv`> linkat(AT_FDCWD, "tmp/foo", AT_FDCWD, "new/sdfsdfdsgg", 0) = 0   <-- doesn't trigger it :(
[18:24] <Tv`> it's watching new/
[18:35] <Tv`> inotifywait on the dir reports a create happily :-|
[19:08] <Tv`> https://bugs.launchpad.net/upstart/+bug/1211472
[20:48] <ianco> hey all :) Im just getting started with upstart, im wondering how I can best handle doing a hot restart for a service
[20:49] <ianco> normally, id just create a hot-restart command in my sysV init script. but can i handle this with upstart in a better way?
[20:49] <Tv`> ianco: what would the hot-restart command do?
[20:51] <ianco> hot restart is probably the wrong description. in this case, its for haproxy and it would be more of a graceful restart command
[20:51] <ianco> it would use the -sf optins
[20:51] <ianco> *options
[20:53] <ianco> basically, stop listening without breaking existing connections, for new config or even new version after upgrade
[20:53] <ianco> really though, im just not sure how best to let upstart would handle something like that, or even if it should handle it
[20:53] <Tv`> that gets into mucky territory
[20:53] <Tv`> as the old instance will still be running
[20:54] <Tv`> and you'd want to start the new instance
[20:54] <ianco> yeah, it would likly require be a series of commands
[20:55] <Tv`> i've always managed that on the LVS level
[20:55] <ianco> so, not really something upstart would handle normally?
[20:56] <Tv`> i am no authority on upstart
[20:56] <Tv`> but i'd say it used to work only because pidfiles and all such are so fuzzy, and upstart bookkeeping is more strict (& correct)
[20:57] <ianco> ah, i see
[21:12] <Tv`> oh well, bug filed, workaround implemented, time to move on
[21:35] <ikarius> hullo.  I'm trying to put together an upstart task, and unfortunately, I've run into an area I don't think the cookbook covers.  I've got a "task" type service, which needs pre-start, start and pre-stop methods
[21:36] <ikarius> the pre-start and script stanzas are working fine, but then when I call stop, it complains of "unknown instance".  I've declared it a task, so it should know that there's nothing running long-term for it to track, it should just kick off the "pre-stop" stanza
[21:36] <ikarius> what else am I missing?