crohr / pkgr

Package any app into deb or rpm packages, using heroku buildpacks
http://crohr.me/pkgr/
MIT License
590 stars 66 forks source link

Delay service restart time to not trigger as quickly #149

Closed rbclark closed 5 years ago

rbclark commented 6 years ago

I am running into an issue where I need RabbitMQ running for my service. The issue is even if I require RabbitMQ as a startup service for my worker, I still have an issue where RabbitMQ is not stable in that amount of time and my service crashes. With slightly slower restarts my service is able to start successfully once RabbitMQ stabilizes.

obfuscoder commented 6 years ago

I certainly would not have my service restart being delayed only for one specific use case. Some may have a timer to check the service after restart which might break due to the forced delay. If you need that, make it configurable, but keep this setting off by default.

rbclark commented 6 years ago

This doesn't actually mess with the speed of running systemctl restart <servicename> unless your service itself fails to start on the first try. Systemctl restart still happens instantly for me when things are up correctly, it only when the service start command fails. Without this the service will fail and never actually start properly for me since it will quickly reach the max number of allowed retries by systemd.

obfuscoder commented 6 years ago

Uhm right. Sorry my bad. The default value is 100ms which can cause the error counter to reach the limit pretty fast if your service fails fast. Setting the restart value to something reasonable (like in your case) helps.

I would still recommend to make this value configurable and leave it at its default value if not configured.

rbclark commented 6 years ago

I am okay with making it configurable, @crohr do you have any preference on how I would go about implementing that?

rbclark commented 6 years ago

Our team has since since solved this in my application by making it more resilient to failures on initial startup. With that said, this feature may still be useful for some people, would there be interest in this PR still or should I just close it?