=== nikias_ is now known as nikias [10:14] Hi. Is there any way I can reliably tell that a service is started with upstart? [10:16] from what I see upstart reports that it managed to start the service regardless of success [10:22] Madkinder: afaik the service tells upstart that is has started successfully [10:22] there are different ways to do this. see the "expect" flag in the cookbook [10:22] take a look: http://pastebin.com/ZNhwKTVs [10:22] this starts like a charm [10:24] maybe because of the respawn flag? [10:26] Madkinder: Upstart will report that it successfully started the job when you "start" it, but "status " will show you it is not (no longer) running. [10:27] jodh: that's the problem I'd like to fix [10:28] Madkinder: look at 'post-start' in init(5). I hope your service isn't as flaky as /bin/false though :) [10:30] jodh: you mean I should check whether my process started manually and emit a failure event or something like that, right? [10:38] Madkinder: no, I mean that if your job is really likely to fail at startup, you should use pre-start or post-start to handle that scenario. Generally, pre-start would setup the required environment. If you make the pre-start fail, the job will fail to start and "start " will indicate that clearly. [10:39] unfortunately not all the services have a way to check the environment [10:40] for example, nginx and apache to with their -t flag, but they are rather an exception then a rule :( [10:41] I'm trying to configure my servers with configuration management tools (salt/ansible). The problem is that they both report that a service is started and running successfully while it might not be true. [10:42] most of the services with ancient sysvinit scripts work like a charm and report start failures, most upstart ones do not :( [16:12] anyone know what the proper `start on` target is for networking ? [16:12] I've tried just `networking` but doesn't seem to startup === JanC_ is now known as JanC === broder_ is now known as broder === stgraber_ is now known as stgraber