[OpenWrt-Devel] [PATCH] base-files: procd initscriptsrestartonreload

[tristan at trstn.net]

Felix Fietkau wrote:
> ...
> 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.

So I just made a test service:

root at hg:~# cat /etc/openwrt_version 
r42538
root at hg:~# cat /etc/init.d/test 
#!/bin/sh /etc/rc.common

START=70
USE_PROCD=1

start_service() {
	procd_open_instance
	procd_set_param command /bin/sleep 10000
	procd_set_param file /tmp/test
	procd_set_param respawn
	procd_close_instance
}

root at hg:~# cat /tmp/test
hello
root at hg:~# /etc/init.d/test start
root at hg:~# pidof sleep
6958
root at hg:~# /etc/init.d/test reload
root at hg:~# pidof sleep
6958
root at hg:~# echo goodbye > /tmp/test
root at hg:~# pidof sleep
6958
root at hg:~# rm /tmp/test
root at hg:~# pidof sleep
6958
root at hg:~# echo hello > /tmp/test
root at hg:~# pidof sleep
6958
root at hg:~# /etc/init.d/test restart
root at hg:~# pidof sleep
6985

Which more or less bears out what I was seeing with dnsmasq.

Note, that adding:

reload_service() {
	restart
}

didn't change anything, except that reload did restart the service.


> 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.

I suppose it is reasonable to make any of the reload methods the default,
and assume that the service will override the default if needed. I just
found the current default to be surprising, as it doesn't match other
handlers' defaults.

> > 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"?

"Connections" is probably too narrow a word, control is maybe better?

The properties of how the service interacts with the outside world. As
in, dnsmasq will reload hosts and ethers on SIGHUP, but will quickly
notice any change in it's upstream resolv.conf, yet won't change what
ports it listens to or the how it allocates addresses without a restart.

The general idea though is that reloading different parts of a services
configuration may use different means. I think there is some history of
using reload for one purpose and restart for another, but that's not born
out by procd's default either.

Tristan

-- 
All original matter is hereby placed immediately under the public domain.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel