[BUG?] Service status is not saved after sysupgrade

For Developers
1

I build the OpenWRT 23.05 sysupgrade image, which provides the watchcat service, but its autostart is not activated.

After install sysupgrade image user enable service watchcat:

root@OpenWrt:~# /etc/init.d/watchcat enable

root@OpenWrt:~# find /etc/rc.d -name ???watchcat
/etc/rc.d/S97watchcat
/etc/rc.d/K01watchcat

root@OpenWrt:~# [ $(/etc/init.d/watchcat enabled; echo $?) == 0 ] && echo svc_enabled || echo svc_disabled
svc_enabled

User reinstall sysupgrade image (without -n option):

root@OpenWrt:~# sysupgrade /tmp/sysupgrade.bin
verifying sysupgrade tar file integrity
Wed Nov 29 02:48:49 UTC 2023 upgrade: Saving config files...
Wed Nov 29 02:48:50 UTC 2023 upgrade: Commencing upgrade. Closing all shell sessions.

After booting:

root@OpenWrt:~# find /etc/rc.d -name ???watchcat

root@OpenWrt:~# [ $(/etc/init.d/watchcat enabled; echo $?) == 0 ] && echo svc_enabled || echo svc_disabled
svc_disabled

And the user is again required to manually enable service watchcat.
But the status of the service should relate to the system settings, which were required to be preserved.

It seems to me that this behavior can partly be considered a bug.

OPKG info 
root@OpenWrt:~# opkg info watchcat
Package: watchcat
Version: 1-17
Depends: libc
Status: install user installed
Section: utils
Architecture: all
Size: 4433
Filename: watchcat_1-17_all.ipk
Conffiles:
 /etc/config/watchcat a0d13bff5d150fa9908d373423cedaaa96e13920a66cbcc7f6e06adf691ec299
Description: Restart network interfaces or reboot if pings to hosts fail, or set up periodic reboots. Configured via UCI /etc/config/watchcat
Installed-Time: 1699969091
2

This is not a bug. It is expected behavior.

I cannot speak to the reasons for the fact that non-default services are not enabled upon upgrade when they were previously (and default services are enabled, even if they had been disabled previously), but this known and expected.

3

And if the user uses service Attended Sysupgrade, then absolutely all installed services will turn into default and after installing the image, all services will be enabled.
Some unobvious behavior results.

2 Likes
4

Well... Only in the sense that if you get hit over the head often enough when doing something, it becomes expected behavior. (If this behavior were to change, say if sysupgrade -b/-r maintained service state across upgrades, I would characterize that as a "bug fix".)

I've been compiling a big list of bugs, features and feature differences for sysupgrade, auc and Luci Attended Sysupgrade, this one is listed as a missing feature for all of them.

2 Likes
5

Check the functions service_save and service_restore here:
https://openwrt.org/docs/guide-user/advanced/sysupgrade_extras
There's also a uci-defaults script to restore the saved state.

2 Likes
6

I believe this issue has been resolved in sysupgrade with this commit:

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=bf304d10e97c11de8c637fda02578cce79a3a0b4

1 Like
7

Well, it turns out that I was right from the start!

But you turned out to be wrong. And you didn’t even delve into what I wrote about.
And I immediately wrote that the behavior was not logical at all.

1 Like
8

No need to gloat. Peter was just reflecting the way things have worked for many, many years.

1 Like
9

Maybe so, but I didn't notice it.

10

Two things here:

  1. I've never claimed to be infallible. I was reporting on the behavior as it has been for many years.
  2. It is possible that it was indeed not a bug... sometimes things may be working as intended (WAI) based on the design intent, despite the fact that it was not obvious/logical (and/or the conditions/expectations have subsequently changed as to make this PR possible). (perhaps @efahl might know about the history -- bug or intended behavior at the time that was the result of a decision in the past.)

I read what you wrote, but I responded based on the information I had available at the time. This commit happened within the last week, and you raised the issue 3 months ago. I don't know if this thread served as a catalyst for the PR, but the behavior had been present for a long time prior -- bug or not -- so it wasn't necessarily a surprise.

I completely agree that it was not logical... and I said at the time:

To be clear, what is known and expected is not always logical.

I'd also like to point out that we try to keep the forum civil. It seems that you were writing this in an "I told you so" type tone of voice (but that could be just how it looks, maybe you didn't intend it as such). That said, please be mindful of how you write -- instead of a (potentially) confrontational tone, a more neutral tone could be reached with something like "FYI - the behavior has been fixed to maintain the enabled/disabled state in this PR."

1 Like
11

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.