rm2fb service is not stopped on uninstall

[matteodelabre]

• Install Toltec stable (or testing).
• Install rm2fb.
• Remove rm2fb.
• Notice that the rm2fb service is still active, and that the remarkable-shutdown process is still running.

Since the systemd unit is actually removed, this is fixed after a reboot, or if you do systemctl stop rm2fb. The package uninstall script should normally stop the service by itself, though.

[Eeems]

Looks like it should be stopped: https://github.com/toltec-dev/toltec/blob/stable/package/rm2fb/package#L58

[raisjn]

this is semi purposeful. it leaves the system in a usable state until they reboot and doesn't restart xochitl. I believe instructions say to reboot to finalize

[matteodelabre]

I ran into this while writing an uninstall script (#295). The script cannot unmount /opt as long as the rm2fb server process is running. If possible, I’d prefer to avoid having to reboot the tablet in the middle of the uninstall script, since it would make the script unnecessarily complicated (requires setting up a one-time hook that gets executed after the reboot).

[raisjn]

that makes sense. some things to pay attention to:

• launchers don't depend on rm2fb, so uninstall of rm2fb can leave launcher running
• need to restart xochitl to get new preload
• current app on screen can be non xochitl. it will no longer work but potentially still be running with the preload attached
• what happens on upgrades? (i think will get double flash and lose screen content)

i think that 1 and 2 combined can leave two xochitl running at same time, too

[Eeems]

* launchers don't depend on rm2fb, so uninstall of rm2fb can leave launcher running

As soon as the rm2fb changes that make it noop on rM1 is in stable, we might want to change this.

* what happens on upgrades? (i think will get double flash and lose screen content)

Upgrades don't run preremove or postremove, they run preupgrade (from old package), postupgrade (from old package), and configure (from new package): https://github.com/toltec-dev/toltec/blob/stable/docs/package.md#install-section

• need to restart xochitl to get new preload

• current app on screen can be non xochitl. it will no longer work but potentially still be running with the preload attached

Is there a way to easily enumerate all the locations that have the preload in place? That or figure out a way to modify how rm2fb's server works such that it can reload itself on the fly?

[matteodelabre]

As for the uninstall script, we can always lazy-unmount /opt, remove the systemd unit, then reboot. This will work even if there are remaining processes with opened files in /opt.

[danshick]

I know it was discussed before, but was it determined that there is no good way to make rm2fb a device specific hard dependency for applications on rM2?

There's another issue open (mine, I think) to add "PROVIDES" support to package recipes. We had discussed a "display" metapackage that is provided by rm2fb for rM2 and could be satisfied by a shim on rM1.

Either way, rm2fb as a non-broken thing on rM1 is still a good idea.

[matteodelabre]

I’m working on it on the tooling/split-architectures branch. The PR should be ready by tomorrow. EDIT: #310.

[danshick]

I’m working on it ... #310.

This is excellent!

[Eeems]

Is this still an issue?

[matteodelabre]

I'll have to test again.

[matteodelabre]

Issue is still present (although the package is now called display; the service is still rm2fb).