@unipo :
Je pense que l'info d'authentification est générée puis envoyée par ubus à odhcp6c. Il semblerait que ton script de régénération ne soit pas appliqué.
uci commit on the cli will not trigger service reloads, you'll have to manually call /sbin/reload_config afterwards.
LuCI uses the ubus uci namespace (ubus call uci commit ...) which will emit change events for any committed /etc/config/xxx file which are then in turn processed by services having a reload trigger installed (grep -r procd_add_reload_trigger /etc/init.d/)
Hyperlien : https://forum.openwrt.org/t/addition-of-new-services-to-openwrt/40479/3
Cette commande vérifie l'état des configurations et déclenche un événement ubus "config.change".
Specifying triggers
While start_service() takes care of setting service instances states and submitting them to the procd (for a potential service restart), it has to be explicitly called to do so. In most cases it should happen on some related change.
That's where service_triggers() comes in handy and allows specifying triggers. Most system important changes result in generating events that service_triggers() can use for triggering various actions. There are multiple procd_add_*_trigger() helpers for that purpose.
Every configurable service has to specify what system changes should result in its reconfiguration. Those events should be defined in the service_triggers() using available helpers. When related procd service event occurs it will result in executing /etc/init.d/<foo> reload.
Example:
service_triggers()
{
procd_add_reload_trigger "<uci-file-name>" "<second-uci-file>"
procd_add_reload_interface_trigger <interface>
procd_add_reload_mount_trigger <path> [<path> ...]
}
Function Arguments Event used Description
procd_add_reload_trigger list of config files config.change Uses /etc/init.d/<foo> reload as the handler
procd_add_reload_interface_trigger interface name interface.* Uses /etc/init.d/<foo> reload as the handler
procd_add_reload_mount_trigger paths to watch for mount.add Uses /etc/init.d/<foo> reload as the handler
procd_add_restart_mount_trigger paths to watch for mount.add Uses /etc/init.d/<foo> restart as the handler
When using uci from command line uci commit doesn't generate config.change event. It requires calling reload_config afterwards.
This does not apply to using uci over rpcd plugin.
Hyperlien : https://openwrt.org/docs/guide-developer/procd-init-scripts#specifying_triggers
Je crois que cela exécute la fonction reload_service() définit dans le service
network.
reload_service() {
local rv=0
init_switch
ubus call network reload || rv=1
return $rv
}
Il me semble que c'est équivalent à
service network reload.
#!/bin/sh
main() {
local service="$1"
shift
local boot status
if [ -f "/etc/init.d/${service}" ]; then
/etc/init.d/"${service}" "$@"
exit "$?"
fi
if [ -n "$service" ]; then
echo "Service \"$service\" not found:"
exit 1
fi
echo "Usage: $(basename "$0") <service> [command]"
for service in /etc/init.d/* ; do
boot="$($service enabled && echo "enabled" || echo "disabled" )"
status="$( [ "$(ubus call service list "{ 'verbose': true, 'name': '$(basename "$service")' }" \
| jsonfilter -q -e "@['$(basename "$service")'].instances[*].running" | uniq)" = "true" ] \
&& echo "running" || echo "stopped" )"
printf "%-30s\\t%10s\\t%10s\\n" "$service" "$boot" "$status"
done
}
main "$@"
reload If the service supports this operation (usually by sending SIGHUP signal) then reload configuration files on the fly without stopping. Otherwise if the service does not implement reload then make a full restart (stop then start).
Hyperlien : https://openwrt.org/docs/guide-user/base-system/managing_services
Cela (procd avec reload_config) appelle la commande
ubus call network reload. Les clients DHCP sont gérés par
netifd. Je crois qu'udhcpc ne supporte pas de mécanisme inter-processus.
Je ne sais pas comment cela fonctionne. Peut-être que cela redémarre udhcpc ?
Messages récents
Câblage / Meilleure façon de monter un AP Wifi au plafond
Installation Bbox fibre
Actus Orange
Box 5G Free Mobile
Installation fibre SFR