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 > restart. 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. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel