[00:17] <SpamapS> tartar: start on starting will block *every* starting event... BUT, only while it transitions from stop/waiting to start/running
[00:17] <SpamapS> tartar: so, the second starting event will not block, because the goal will now be 'start'
[00:35] <tartar> hmm
[01:25] <tartar> It would be nice if "start SERVICE" could give the status of the already starting or started job.
[01:26] <tartar> It seems "start SERVICE" will say "already running" regardless of the status such as start/starting or start/running.
[01:27] <tartar> Using "status SERVICE" before "start SERVICE" goes against possibility of an atomic check-vs-start.
[01:29] <tartar> Ah, I should use the error code of "start SERVICE" and tell the difference between the starting and the running states by looking at "status SERVICE" on receiving a non-zero code.
[01:48] <tartar>  
[01:48] <SpamapS> tartar: I'd also question the use case. If you want it started, start just asserts that the goal will at least have been set to start once.
[01:49] <SpamapS> tartar: so its more of an assertion "make sure its at least in a state trying to start"
[01:53] <tartar> Thanks.
[01:53] <tartar>  
[01:53] <tartar> On an unrelated note, I love the rare occasions when pressing Ctrl-Alt-Delete brings up shell instead of rebooting a locked startup.
[01:54] <tartar> I am not sure if this came as under-developed intent or by chance.
[01:55] <tartar> Err. brings up the login prompt
[03:15] <tartar> I wonder where can I read... It appears that "task" will return its starting hooks on completion of its script.  Does pre-start of a service block the service's "start on" hook in the same way?
[03:17] <tartar> SpamapS: your comment about blocking starting events seems to imply yes.
[03:22] <tartar> Yay, "6.32 task" confirms this.  "Without the 'task' keyword, the events that cause the job to start will be unblocked as soon as the job is started. This means the job has emitted a starting(7) event, run its pre-start, begun its script/exec, and post-start, and emitted its started(7) event."
[10:54] <afournier> do a job that does an "start on starting job2" will run even if job2 fails to start ?
[10:55] <afournier> i'd say yes
[10:56] <afournier> but the real question would then be, does job2 will run even if the job fails
[16:52] <SpamapS> afournier: a very easy thing to test. I believe the answer is yes
[16:53] <afournier> yes