[OpenWrt-Devel] [PATCH] procd: Allow override of default respawn parameters

John Crispin blogic at openwrt.org
Fri Sep 18 05:52:35 EDT 2015



On 18/09/2015 11:40, Etienne Champetier wrote:
> Hi,
> 
> 2015-09-18 11:03 GMT+02:00 Helmut Schaa <helmut.schaa at googlemail.com
> <mailto:helmut.schaa at googlemail.com>>:
> 
>     Hi John,
> 
>     On Fri, Sep 18, 2015 at 10:18 AM, John Crispin <blogic at openwrt.org
>     <mailto:blogic at openwrt.org>> wrote:
>     > Hi
>     >
>     > On 18/09/2015 09:59, Helmut Schaa wrote:
>     >> Allow to pass RESPAWN_THESHOLD_DEFAULT, DRESPAWN_TIMEOUT_DEFAULT
>     >> and RESPAWN_RETRY_DEFAULT as parameters to cmake to change the
>     >> default respawn behavior.
>     >>
>     >
>     > technically ok but why cant you tweak them in your packages initd script
>     > ? i am wondering what the use case is and if there are other possible
>     > solutions
> 
>     In our tree we've patched most (maybe even all) services to respawn
>     forever
>     (respawn_retry=-1). Including all OpenWrt provided services. Instead
>     of keeping
>     these local modifications to several packages it's easier to just
>     override procds
>     default behavior.
> 
>     I think there might be other people around running OpenWrt on
>     headless boxes
>     where the respawn retry should not be limited by default. However,
>     this is of course
>     not suitable for a default OpenWrt box.
> 
>     If there are good reasons not to include this in procd feel free to
>     drop this patch.
>     However, it causes zero runtime overhead and is quite simple.
> 
>     As a followup I'd add a config flag for procd "respawn_forver_mode"
>     or so that
>     just sets respawn_retry to -1.
> 
>     Helmut
> 
> It would be great to be able to configure these settings at runtime (ie
> in an uci file)
>
> Etienne
>

agreed, i think the best would be to add support for -1 == endless
respawn and then change procd.sh to use current values as default but
allow overriding them vom /etc/config/system or similar. would that
solve your use case ?

	John
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list