| Age | Commit message (Collapse) | Author |
|---|
|
It is possible that the uci configuration file will be added to the system
later. Therefore, ucitrack json definitions are always added to ucitrack
triggers and it is not checked whether the uci configuration file exists.
Reported-by: Chen Minqiang <ptpt52@gmail.com>
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
|
|
The 'ucitrack' configuration under '/etc/config' defines which service must
be restarted on a LuCI change. This uci file defines how all this works
together. Additionally there are 'uci-defaults' scripts in the various
applications that add additional configurations parameters to this ucitrack
file if a service must be reloaded/restarted on a LuCI change.
There are some problems with the current implementation:
* The uci should be used to configure the system and not for this kind of
reload/restart dependency handling on LuCI changes.
* On a system update with configuration restore of the 'ucitrack' file
the new behavior on LuCI reload/restart could not take into account
because the new file is *not* used.
This commit converts the handling from uci to json.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
|
|
Changes on a given configuration should trigger change events on affected
configurations, not the other way around.
Fixes: #5745
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
In file `/etc/config/ucitrack`
```
config fstab
option exec '/sbin/block mount'
```
`/sbin/block mount` never be called after fstab changed.
Signed-off-by: jjm2473 <1129525450@qq.com>
|
|
Ship an /etc/init.d/ucitrack for spawning a virtual service with the sole
purpose to track the configurations and dependencies formerly handled by
luci-reload.
Once all LuCI supported services ship with procd compatible init scripts,
the uci track support can be dropped.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
