Custom actions based on uci changes with luci app

[stangri]

I hope @jow can shed some light on this:

I'm trying to either restart or reload my service based on which uci entries have been changed with the luci app (model-cbi).

I'm tracking changes made with m.on_before_commit here and I'm taking action based on that with m.on_before_apply here.

However, unless I do uci:commit() the service restart/reload runs on settings which were not affected by the changes in the luci-app, so at the on_before_apply the changes had not been written to the config file.

I've tried the on_after_apply, but with or without the ucitrack entries it just seems to never trigger.

The only reason I don't like to do the uci:commit() in on_before_apply is that on 18.06.0 it briefly shows the message "There are no changes to apply" message.

Any suggestions?

[jow]

The approach you describe sounds rather brittle. The best solution would be to alter your service init script to decide between a process reload or restart, based on the desired configuration state and stop overriding the default behaviour.

I will need to think some more about it, but right now I consider to simply change the "There are no changes to apply" message to "Changes applied". The message merely indicates that there's been no supervised uci changes, not that nothing got applied.

[stangri]

@jow

The approach you describe sounds rather brittle. The best solution would be to alter your service init script to decide between a process reload or restart, based on the desired configuration state and stop overriding the default behaviour.

How can I differentiate which action to take in the init script without knowing what settings have been changed?

Anyways, I've RTFM which says: "on_after_apply || All changes where completely applied (only works on Map instances with the apply_on_parse attribute set) "

And seems to have got it working with on_after_apply.

[jow]

@stangri

How can I differentiate which action to take in the init script without knowing what settings have been changed?

I didn't look closely at your service init script yet but usually by comparing the current uci values with those cached by a prior run of the init script.

I would write the interesting config bits during startup into a /var/run/simple-adblock.state or similar and then compare those with the current uci get values on the next invocation. Depending on your particular needs you might not even need to store the actual values but e.g. an md5sum hash of the values to compare later.