I found that if I restore a previously backed up configuration, it never restores the disabled state of the services that I have disabled.
Somewhat understandable technically, as enabled state is a symlink in /etc/rc.d, and how to restore the non-existence of a link? Well, there are methods of course, but this is probably the technical explanation why this is not working.
But surely I am not the first to find this. So equally surely there is a reason why this was not fixed a long time ago.
Anyone care to tell me what the reasons may be?
PS: I think a simple method would be instead of deleting the rc.d symlink, upon disable we could make the symlink to /dev/null, and simply add /etc/rc.d to the list of folders that are backed up.
Maybe as a safely, always enable certain essentials like network and dropbear upon restore.
Yes this is exactly the expected behavior for services. One reason for this could be that if user is restoring configuration it's not always the case that they have those programs/services installed. This is why it's better not to backup the services' states.
Even if a user has packages/services installed and it would be perfectly fine to restore the services' states then you have the option to do it manually through /etc/sysupgrade.conf. You can edit it and save whatever you think you need to save while saving configuration. So then when you create a backup it should save all those that you put in there along with other config.
That sounds reasonable at first glance, but really only applies to additional packages, and only to their enabled states.
If I for example disable build-in dnsmasq, then I really feel that should be part of the saved config. Starting dnsmasq on a device that is not supposed to could really cause trouble. And yes, I could also put in a safety by ignoring all interfaces in dnsmasq config, but please do not distract from the principle, the fact I disabled a build in package is part of the config.
And to be honest, even as to the enabled state of additional packages: So I may restore a /etc/rc.d/ that point to a non-existing package. I see no problem with that. The non-existing package will not run. Until I remember to install it, when it does run, which is exactly what I want.
So is there any other argument to not save these links?
Anyway, indeed a combination of your and my suggestions works quite well:
Add a link to a non existing file that can be saved as disabled state.
The fake link even nicely shows as 'disabled' in Luci.
add to the sysupgrade.conf which states you want to save.
## This file contains files and directories that should
## be preserved during an upgrade.
# /etc/example.conf
# /etc/openvpn/
/etc/init.d/wifi-disconnect-low-signal
/usr/bin/wifi-disconnect-low-signal.lua
# add this folder to also save startup state of installed packages
# add link to non-existing file disabled to also save/restore disabled state of any services
# example: ln -s -f ../init.d/disabled S60dnsmasq
/etc/rc.d/S19firewall
/etc/rc.d/S50telnet
/etc/rc.d/S50uhttpd
/etc/rc.d/S60dnsmasq
/etc/rc.d/S99wifi-disconnect-low-signal
If you aren't afraid of CLI, you can create a script to configure the system from zero including package and service management.
In that case you basically do not need to perform configuration backup.
@cybermaus You should know that OpenWrt is not limited to just one scenario. If services' states were to be saved, for instance, it can cause problems for those who are fairly new to the project. But anyways as I said before everyone has a different scenario to work with so if you want something done for your use-case, you have to make it work yourself.
You can also create a custom firmware and bake the configuration in there so it is part of the firmware and you would not need to do anything after that. Most of the users are happy with the configuration that gets deployed with it.