[OpenWrt-Devel] [PATCH] base-files: procd initscriptsrestartonreload
nbd at openwrt.org
Tue Sep 16 05:36:52 EDT 2014
On 2014-09-15 11:42, Tristan Plumb wrote:
>> On 15/09/2014 10:36, Tristan Plumb wrote:
>> >>>> which specific package is causing issue ?
>> >>> In my setup, I've noticed this with dnsmasq and babeld. That is,
>> >>> that I needed to restart and instead of reload to get things to
>> >>> take effect. Everything else I run is configured by command line
>> >>> arguments.
>> >> what do you want to do ? track a file and if changed trigger a reload ?
>> > Nope, I want /etc/init.d/foo reload to work as expected.
>> vagueness == no fix
>> if you wont this fixed you need to be more elaborate than "as expected"
> The current behavior with a procd service is that unless the service has
> declared its own routine /etc/init.d/foo reload will restart the service
> if the command line changes, but otherwise take no action to alert the
> service of new configuration files. The expected behavior is that reload
> will reload changed configuration by whatever means necessary, including
> restarting the service.
> Which is what /etc/init.d/foo help claims it does.
> Lacking information about how the service is configured, it must
For procd based services, the assumption should be that all information
is there to decide whether a service should be restarted on reload.
If a service does not get enough information to handle reload properly,
that's a bug which should not be worked around by using an unconditional
restart on reload.
> Knowing the configuration files, it must restart if they, the command
> line arguments, or the enviroment have changed, but not otherwise.
> Knowing that the service takes SIGHUP to reread configuration files, it
> must restart if the command line arguments, or environment, have changed,
> but only be sent a signal otherwise.
That is currently not implemented within procd, but should be easy to add.
> Knowing that the service manages this itself nothing need happen.
> And there are mixtures of the four, some services manage data one way and
> connections another. It might be useful to have one name for data and
> another for connections, but that's not what we've inherited, merely
> reload means to reload the configuration.
What do you mean by "connections"?
By the way, you mentioned in an earlier email that procd_set_param file
did not work for you to restart your service when a config file changes.
Can you produce a test case for that? I just tested it myself on a
simple service and it worked just fine.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel