[12:21] <stiang> How can I convince upstart that "no, there is no process 26428 anymore, please start solr even if you think it is still running"?
[16:34] <pdtpatr1ck> Question - upstart returns 0 whether the app is running or stopped. I've read many bug reports and the back and forth, haven't seen any solution 
[19:57] <SpamapS> pdtpatr1ck: upstart *prints* the actual status
[21:04] <JanC> an option to return a status might be useful though
[21:05] <JanC> e.g. in scripts
[21:33] <SpamapS> JanC: I agree
[21:33] <SpamapS> JanC: I believe there is also a feature request to have something like --oknodo for start/stop
[21:34] <SpamapS> JanC: so that you can just say 'start --ok-no-do foo' and then it will just make sure foo is started, not that it changed from stop->start
[21:34] <SpamapS> JanC: given that, status would become less relevant in scripting
[21:34] <JanC> depends
[21:36] <JanC> that isn't useful if you want to be sure it's not running  ;)
[21:37] <JanC> or if you just want to do something different based on that status
[21:45] <SpamapS> JanC: stop --oknodo is the same thing
[21:45] <SpamapS> JanC: if its stopped, you return 0. If you move from start->stop, you return 0. You only return 1 if there's an error.
[21:45] <SpamapS> JanC: for the other cases, parsing status is fine
[21:50] <JanC> parsing is always prone to errors (unless the output is guaranteed never to change)
[21:50] <JanC> and you do not always want to change the started/stopped status
[22:15] <SpamapS> the output is guaranteed never to change
[22:16] <SpamapS> goal/state is set in stone
[22:16] <SpamapS> JanC: we agree, but there are two things.. goal and state.. and status's return code cannot possibly handle all of the combinations of those sanely.
[22:41] <JanC> SpamapS: let's say I feel more comfortable with separate output for machines & humans...   ;)
[22:43] <SpamapS> JanC: what would you have status do then? 0 only for start/running, 1 for all others?
[22:46] <JanC> even if the output would be printed to stdout or stderr, or whatever mechanism is used, there should probably be a difference between output for humans and for computers
[22:47] <JanC> and both should be optimized for their purpose
[22:48] <SpamapS> JanC: $jobname[space]$goal/$state is pretty darn easy to parse for human and machine
[22:48] <SpamapS> JanC: no probably, show me the money. I want to know how you envision it. :)
[22:51] <JanC> that's already not going to work...
[22:51] <JanC> e.g. "network-interface-security (network-manager) start/running"
[22:52] <JanC> or "tty6 start/running, process 1811"
[22:55] <JanC> (well, that's with list output, but you don't always know the exact thing to query without parsing that)
[22:57] <JanC> and maybe not even by parsing that  ;)
[22:58] <JanC> also, sometimes an PID is added, sometimes not
[22:59] <JanC> and maybe in the future other things will be added