[12:21] 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] 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] pdtpatr1ck: upstart *prints* the actual status === marrusl is now known as marrusl-ebayqbr [21:04] an option to return a status might be useful though === marrusl-ebayqbr is now known as marrusl [21:05] e.g. in scripts [21:33] JanC: I agree [21:33] JanC: I believe there is also a feature request to have something like --oknodo for start/stop [21:34] 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] JanC: given that, status would become less relevant in scripting [21:34] depends [21:36] that isn't useful if you want to be sure it's not running ;) [21:37] or if you just want to do something different based on that status [21:45] JanC: stop --oknodo is the same thing [21:45] 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] JanC: for the other cases, parsing status is fine [21:50] parsing is always prone to errors (unless the output is guaranteed never to change) [21:50] and you do not always want to change the started/stopped status [22:15] the output is guaranteed never to change [22:16] goal/state is set in stone [22:16] 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] SpamapS: let's say I feel more comfortable with separate output for machines & humans... ;) [22:43] JanC: what would you have status do then? 0 only for start/running, 1 for all others? [22:46] 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] and both should be optimized for their purpose [22:48] JanC: $jobname[space]$goal/$state is pretty darn easy to parse for human and machine [22:48] JanC: no probably, show me the money. I want to know how you envision it. :) [22:51] that's already not going to work... [22:51] e.g. "network-interface-security (network-manager) start/running" [22:52] or "tty6 start/running, process 1811" [22:55] (well, that's with list output, but you don't always know the exact thing to query without parsing that) [22:57] and maybe not even by parsing that ;) [22:58] also, sometimes an PID is added, sometimes not [22:59] and maybe in the future other things will be added