inconsistent restart behavior for scripted services with different defaults

additionally, is there actually a reason scripted services can't restart on failure exit code?

additionally, is there actually a reason scripted services can't restart on failure exit code?

additionally, is there actually a reason scripted services can't restart on failure exit code?

i guess what i'm asking is a behavior where:

1. all services restart by default due to dependencies, no matter the service type (unless inhibited with restart = no)
2. process services don't restart if their process exits with 0

i guess making scripted services restart on failure doesn't make much sense as they are one-shot and therefore have no real supervision, even though it would be possible? maybe with an explicit restart = yes? not sure

i guess what i'm asking is a behavior where:

1. all services restart by default due to dependencies, no matter the service type (unless inhibited with restart = no)
2. process services don't restart if their process exits with 0

i guess making scripted services restart on failure doesn't make much sense as they are one-shot and therefore have no real supervision, even though it would be possible? maybe with an explicit restart = yes? not sure

i guess what i'm asking is a behavior where:

1. all services restart by default due to dependencies, no matter the service type (unless inhibited with restart = no)
2. process services don't restart if their process exits with 0

i guess making scripted services restart on failure doesn't make much sense as they are one-shot and therefore have no real supervision, even though it would be possible? maybe with an explicit restart = yes? not sure

i guess what i'm asking is a behavior where:

1. all services restart by default due to dependencies, no matter the service type (unless inhibited with restart = no)
2. process services don't restart if their process exits with 0

i guess making scripted services restart on failure doesn't make much sense as they are one-shot and therefore have no real supervision, even though it would be possible? maybe with an explicit restart = yes? not sure

Agreed, restart = on-failure should apply if a dependency fails. I.e. dependency failure should count as failure for purposes of restart.

additionally, is there actually a reason scripted services can't restart on failure exit code?

There's no particular reason why a retry couldn't be attempted. It's not technically a restart (at service level) since the service never reached "started" state in this case. None of the service types currently support retry.

Agreed, restart = on-failure should apply if a dependency fails. I.e. dependency failure should count as failure for purposes of restart.

additionally, is there actually a reason scripted services can't restart on failure exit code?

There's no particular reason why a retry couldn't be attempted. It's not technically a restart (at service level) since the service never reached "started" state in this case. None of the service types currently support retry.

Agreed, restart = on-failure should apply if a dependency fails. I.e. dependency failure should count as failure for purposes of restart.

additionally, is there actually a reason scripted services can't restart on failure exit code?

There's no particular reason why a retry couldn't be attempted. It's not technically a restart (at service level) since the service never reached "started" state in this case. None of the service types currently support retry.

oh, i didn't consider that - indeed, regardless of the restart value, a start will only be attempted once...

then scratch my question :) i guess retry would be a separate functionality should it ever be added

the rest of the issue still stands - i would like to configure dinit with default restart method of on-failure, but have dependency fails be considered a failure for restart purposes (which, as far as i can tell, should apply to any service type, not just process and bgprocess)

the current behavior can't accommodate that as far as i can tell, as it will alter scripted services behavior?

the current behavior goes like "if restart mode is on-failure, only set autorestart flag if the exit status was a fail, and only for process services" - as far as i understand it should be more like "if restart mode is on-failure, always set the autorestart flag for any service type, except when the service is a (bg)process service and explicitly exited with zero or term signal" perhaps?

oh, i didn't consider that - indeed, regardless of the restart value, a start will only be attempted once...

then scratch my question :) i guess retry would be a separate functionality should it ever be added

the rest of the issue still stands - i would like to configure dinit with default restart method of on-failure, but have dependency fails be considered a failure for restart purposes (which, as far as i can tell, should apply to any service type, not just process and bgprocess)

the current behavior can't accommodate that as far as i can tell, as it will alter scripted services behavior?

the current behavior goes like "if restart mode is on-failure, only set autorestart flag if the exit status was a fail, and only for process services" - as far as i understand it should be more like "if restart mode is on-failure, always set the autorestart flag for any service type, except when the service is a (bg)process service and explicitly exited with zero or term signal" perhaps?

oh, i didn't consider that - indeed, regardless of the restart value, a start will only be attempted once...

then scratch my question :) i guess retry would be a separate functionality should it ever be added

the rest of the issue still stands - i would like to configure dinit with default restart method of on-failure, but have dependency fails be considered a failure for restart purposes (which, as far as i can tell, should apply to any service type, not just process and bgprocess)

the current behavior can't accommodate that as far as i can tell, as it will alter scripted services behavior?

the current behavior goes like "if restart mode is on-failure, only set autorestart flag if the exit status was a fail, and only for process services" - as far as i understand it should be more like "if restart mode is on-failure, always set the autorestart flag for any service type, except when the service is a (bg)process service and explicitly exited with zero or term signal" perhaps?

as far as i understand it should be more like "if restart mode is on-failure, always set the autorestart flag for any service type, except when the service is a (bg)process service and explicitly exited with zero or term signal" perhaps?

Well, maybe, or maybe only actual failure should cause restart even of dependents. Eg:

• scripted service A
• process service B
• A depends on B
• B stops with no error (a clean exit). Should A restart in this case? Or in other words should any dependency stopping automatically count as failure even if it stopped "cleanly"?

I've been thinking about this a bit (sorry for the slow reply), but you might have a better sense of which behaviour would be better than I do, to be honest.

as far as i understand it should be more like "if restart mode is on-failure, always set the autorestart flag for any service type, except when the service is a (bg)process service and explicitly exited with zero or term signal" perhaps?

Well, maybe, or maybe only actual failure should cause restart even of dependents. Eg:

• scripted service A
• process service B
• A depends on B
• B stops with no error (a clean exit). Should A restart in this case? Or in other words should any dependency stopping automatically count as failure even if it stopped "cleanly"?

I've been thinking about this a bit (sorry for the slow reply), but you might have a better sense of which behaviour would be better than I do, to be honest.

i'd lean towards not restarting

if a service depends on another and that other dependency stops cleanly, it should probably leave anything depending on it stopped, as we don't want to bring it back up spuriously