[PATCH v2] base-files: restore status of system-services after sysupgrade
Martin Schiller
ms at dev.tdt.de
Wed Jan 13 00:54:41 EST 2021
On 2021-01-12 23:03, Sven Roederer wrote:
> Am Dienstag, 12. Januar 2021, 19:56:54 CET schrieb Hannu Nyman:
>> Martin Schiller kirjoitti 12.1.2021 klo 9.25:
>> > On 2021-01-11 23:07, Sven Roederer wrote:
>> >> Restore the status of the system-services after sysupgrade.
>> >> Create a file with the status of all known services and keep it during
>> >> upgrade. After upgrade run a uci-default script to restore every
>> >> single service.
>> >
>> > Doing the restore in an uci-default script is to late, because then you
>> > are already in the procd rcS helper "loop" and new added init links
>> > won't get called.
>> >
>> > Also, have you thought about a backup/restore of the configuration?
>> > The whole thing should/must work there as well.
>> >
>> > I would do the restore at the end of the pre-init stage.
>> >
>> > Martin
>>
>> My two cents to the discussion:
>>
>> * I assume that a small minority of users actually disable services,
>> or at
>> least disable several services, so defaulting to "lets by default
>> always
>> store status of all services" sounds like overkill.
>>
>> * Backuping always info that the dozens of standard services are
>> enabled
>> sounds unncessary. As services are installed by default as "enabled"
>> to the
>> image, it might make sense to store only info about "disabled"
>> services and
>> disable those when restoring the backup in sysupgrade. (Re-enabling
>> the
>> already enabled services is unnecessary.) That would also help to
>> keep the
>> amount of new backup info small.
>>
>> * make clear in sysupgrade script help texts and documentation that
>> saving/restoring service status depends on "keep settings". If
>> settings are
>> not kept, the service status can not be copied in sysupugrade as there
>> is no
>> sysupgrade.tar.gz to be passed. (And naturally it would not even make
>> sense
>> to e.g. revert network settings to defaults but keep selected network
>> services disabled. Easy to cause soft-bricks that way.)
>>
>>
> Hannu,
>
> as long as no service was disabled with the "DISABLED_SERVICES" option
> of the
> imagebuilder the explicit "enable" is not required.
> Indeed enabling a service that have been disabled during image creation
> is a
> bit edge-case, but I prefer here the "full featured" way. Not enabling
> such a
> service also breaks the user experience like the disable case.
I totally agree. If you do this, you should cover all cases.
More information about the openwrt-devel
mailing list