Hi all,
as discussed on the matrix channel, there is the need for MicroOS Desktop users to be notified about needed reboots for updates.
Brainstorming about it one of the solutions could be:
1 - reintroduce transactional-update.timer 2 - set up rebootmgr to work well with desktop workloads 3 - notify the user that the system is updated and a reboot is needed 4 - nice-to-have: if I click the notification it calls the native reboot prompt of the installed DE.
What I'm proposing now is just a proof of concept.
As a starting idea, I've thought about patching rebootmgr to have a new strategy: notify
Here is the patched rebootmgr: https://github.com/89luca89/rebootmgr/tree/feature/add_notify_strategy
The patch consists in adding the strategy to rebootmgrctl and rebootmgrd. The new strategy should consist in notifying the user with a dbus notification. The problem that came up is that I couldn't find a way for a root service to de-privilege itself to use the user's dbus-session, I had various errors about DISPLAY variable, xauth and so on.
To work around it, I thought of creating an user-running service (systemctl --user), that would open a file socket in /run/user/$ID/ that would receive the command to launch the notification.
You can find the example daemon here (very example...): https://gist.github.com/89luca89/bd78f5e716a7bd9206f802756e6c10de
So you would have:
t-u -> rebootmgrctl reboot -> dbus message to -> reboomgrd -> contact file socket -> user_notification_daemon
The routine I've added to the rebootmgrd should find all the active sockets for all users and contact all of them so that all users are notified about the update.
I'd like to have a feedback on the implementation, I'm 100% sure there is a lot to improve and I'm surely missing something on that user's dbus-session issue I had. As it stands now this proof of concept is working right now on my installation.
Thanks, 89luca89
Hi,
Am Donnerstag, 5. Mai 2022, 13:44:50 CEST schrieb Luca Di Maio:
Hi all,
as discussed on the matrix channel, there is the need for MicroOS Desktop users to be notified about needed reboots for updates.
Brainstorming about it one of the solutions could be:
1 - reintroduce transactional-update.timer 2 - set up rebootmgr to work well with desktop workloads 3 - notify the user that the system is updated and a reboot is needed 4 - nice-to-have: if I click the notification it calls the native reboot prompt of the installed DE.
IMO ideally transactional updates get integrated into the usual (maybe DE specific) ways to perform updates. That way they're rather similar to PK offline upgrades which most of them can already handle.
What I'm proposing now is just a proof of concept.
As a starting idea, I've thought about patching rebootmgr to have a new strategy: notify
Here is the patched rebootmgr: https://github.com/89luca89/rebootmgr/tree/feature/add_notify_strategy
The patch consists in adding the strategy to rebootmgrctl and rebootmgrd. The new strategy should consist in notifying the user with a dbus notification. The problem that came up is that I couldn't find a way for a root service to de-privilege itself to use the user's dbus-session, I had various errors about DISPLAY variable, xauth and so on.
The best option is to just send a signal over DBus (system bus) that some updates were installed (ideally with some details). That can be picked up by any daemon in the user session and get translated to a persistent notification with a reboot button.
Ideally also update failures get announced that way. Currently it just silently fails, so unless the journal is getting looked at randomly it's currently too easy to miss that the system didn't get updated properly for a while.
Cheers, Fabian
To work around it, I thought of creating an user-running service (systemctl --user), that would open a file socket in /run/user/$ID/ that would receive the command to launch the notification.
You can find the example daemon here (very example...): https://gist.github.com/89luca89/bd78f5e716a7bd9206f802756e6c10de
So you would have:
t-u -> rebootmgrctl reboot -> dbus message to -> reboomgrd -> contact file socket -> user_notification_daemon
The routine I've added to the rebootmgrd should find all the active sockets for all users and contact all of them so that all users are notified about the update.
I'd like to have a feedback on the implementation, I'm 100% sure there is a lot to improve and I'm surely missing something on that user's dbus-session issue I had. As it stands now this proof of concept is working right now on my installation.
Thanks, 89luca89
On Thu, 2022-05-05 at 13:51 +0200, Fabian Vogt wrote:
Hi,
Hi from me as well, :-)
Am Donnerstag, 5. Mai 2022, 13:44:50 CEST schrieb Luca Di Maio:
1 - reintroduce transactional-update.timer 2 - set up rebootmgr to work well with desktop workloads 3 - notify the user that the system is updated and a reboot is needed 4 - nice-to-have: if I click the notification it calls the native reboot prompt of the installed DE.
IMO ideally transactional updates get integrated into the usual (maybe DE specific) ways to perform updates. That way they're rather similar to PK offline upgrades which most of them can already handle.
Indeed. In fact, that was and still is a plan. There's an outdated halfway working POC for that, which I hope to be able to get back to do some work on at some point... Which also means that we currently have nothing (and we may continue not to for a while, as far as we can tell).
Also, PackageKit/pkcon has its own issues. For instance, it doesn't always work, e.g.:
https://bugzilla.suse.com/show_bug.cgi?id=1196512
There's also the problem that snapshots marked with "transactional- update-in-progress=yes" are left around and not cleaned up, e.g.:
$ sudo snapper list # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata ----+--------+-------+---------------------------+------+------------+---------+------------------------+------------------------------------- 0 | single | | | root | | | current | 1 | single | | lun 21 feb 2022, 20:54:29 | root | 3,59 MiB | | first root filesystem | 2 | single | | lun 21 feb 2022, 21:00:31 | root | 57,27 MiB | number | after installation | important=yes 3 | single | | lun 21 feb 2022, 22:46:04 | root | 808,00 KiB | | Snapshot Update of #1 | 4 | single | | lun 21 feb 2022, 22:48:20 | root | 488,00 KiB | | Snapshot Update of #3 | 5 | single | | lun 21 feb 2022, 23:26:26 | root | 1,87 MiB | | Snapshot Update of #4 | 6 | single | | lun 21 feb 2022, 23:40:29 | root | 368,00 KiB | | Snapshot Update of #5 | 7 | single | | lun 21 feb 2022, 23:42:00 | root | 1,38 MiB | | Snapshot Update of #6 | transactional-update-in-progress=yes 8 | single | | lun 21 feb 2022, 23:50:22 | root | 128,00 KiB | | Snapshot Update of #6 | 9 | single | | lun 21 feb 2022, 23:51:25 | root | 128,00 KiB | | Snapshot Update of #8 | transactional-update-in-progress=yes 10 | single | | mar 22 feb 2022, 00:12:36 | root | 576,00 KiB | | Snapshot Update of #8 | 11 | single | | mar 22 feb 2022, 10:10:04 | root | 2,67 MiB | | Snapshot Update of #10 | 12 | single | | mar 22 feb 2022, 10:23:56 | root | 16,00 KiB | | Snapshot Update of #11 | 13 | single | | ven 25 feb 2022, 18:27:38 | root | 16,00 KiB | | Snapshot Update of #12 | transactional-update-in-progress=yes 15 | single | | ven 25 feb 2022, 18:33:02 | root | 353,36 MiB | | Snapshot Update of #12 | 17 | single | | mar 1 mar 2022, 15:18:50 | root | 49,01 MiB | | Snapshot Update of #15 | 18 | single | | mar 1 mar 2022, 19:40:35 | root | 7,00 MiB | | Snapshot Update of #17 | 20 | single | | sab 5 mar 2022, 16:43:43 | root | 4,35 MiB | | Snapshot Update of #18 | 21 | single | | mar 8 mar 2022, 13:56:35 | root | 4,36 MiB | | Snapshot Update of #20 | transactional-update-in-progress=yes 22 | single | | mar 8 mar 2022, 14:10:25 | root | 4,36 MiB | | Snapshot Update of #20 | transactional-update-in-progress=yes 23 | single | | mar 8 mar 2022, 14:14:46 | root | 4,36 MiB | | Snapshot Update of #20 | transactional-update-in-progress=yes 24 | single | | mer 16 mar 2022, 11:16:46 | root | 4,38 MiB | | Snapshot Update of #20 | transactional-update-in-progress=yes 26 | single | | mer 16 mar 2022, 11:22:40 | root | 4,33 MiB | | Snapshot Update of #20 | 27 | single | | gio 28 apr 2022, 12:29:32 | root | 4,38 MiB | | Snapshot Update of #26 | transactional-update-in-progress=yes 29 | single | | ven 29 apr 2022, 08:17:15 | root | 416,00 KiB | | Snapshot Update of #26 | 30 | single | | ven 29 apr 2022, 08:31:31 | root | 13,47 MiB | | Snapshot Update of #29 | transactional-update-in-progress=yes 31* | single | | ven 29 apr 2022, 22:30:50 | root | 128,00 KiB | | Snapshot Update of #29 | 32 | single | | ven 29 apr 2022, 22:33:34 | root | 128,00 KiB | | Snapshot Update of #31 | transactional-update-in-progress=yes 33 | single | | gio 5 mag 2022, 21:44:17 | root | 6,69 MiB | | Snapshot Update of #31 | transactional-update-in-progress=yes
Last thing I've noticed, I sometimes can't find packages, e.g.:
$ pkcon search ffmpegthumb Searching by details [=========================] Querying [=========================] Loading cache [=========================] Finished $
Even if they are there:
$ zypper se ffmpegthumb S | Name | Summary | Type ---+----------------------------+-----------------------------------------------------+-------- i+ | ffmpegthumbnailer | Video thumbnailer that can be used by file managers | package | ffmpegthumbs | FFmpeg-based thumbnail creator for video files | package | libffmpegthumbnailer-devel | Development files for ffmpegthumbnailer | package i+ | libffmpegthumbnailer4 | Video thumbnail generator | package
(and can actually be installed with `pkcon install ffmpegthumbnailer`, once I know the name!)
All these issues can probably be solved, but I do not think anyone is actively working on doing that, and IMO this is a problem for current (and potential! :-D) MicroOS Desktop users.
What Luca is proposing (and already experimenting on! :-P) can, hopefully, let us move forward and avoid all these problems. So, FWIW, I quite like the idea. :-)
It also shouldn't be the case that the approaches are completely mutually exclusive. In fact, users are already re-installing the transactional-update package, but at the same time using pkcon for package manipulation...
Ideally also update failures get announced that way. Currently it just silently fails, so unless the journal is getting looked at randomly it's currently too easy to miss that the system didn't get updated properly for a while.
+1
Regards, Dario
Hi folks, thanks for the replies!
The best option is to just send a signal over DBus (system bus) that some updates were installed (ideally with some details). That can be picked up by any daemon in the user session and get translated to a persistent notification with a reboot button.
That's what I'm trying now, but using a socket instead of dbus because using a system-dbus to notify users won't work, and using user's dbus-session from a root daemon also doesn't work. I didn't think about an user-daemon trying to read from system-dbus, I'll check if I manage, we could remove the socket file communication and stick to dbus
@being notified of failed updates
Completely agree that's something needed! Right now the update process work with
t-u launches /usr/bin/rebootmgrctl reboot
if it manages to update successfully
Right now we do not have any hook on update failure in t-u, so we will need to add to that. Adding an update-failed to the user-facing daemon is trivial
At this point I'm thinking about moving this "talk with user-facing daemon" thing away from rebootmgr and bake it into transactional-update, something on the lines of
transactional-update cleanup dup **notify**
And set up a notification path (instead of a reboot one) in t-u itself
Will have to investigate how involved this is, the aim of this was just to provide a working solution while packagekit integration (and so discover and gnome-software) integration is finished.
So the idea was not to move too much stuff around and do not interfere too much also with non-desktop (microos/kubic) setups
Regards, Luca
Hi,
Am Freitag, 6. Mai 2022, 08:58:06 CEST schrieb Luca Di Maio:
Hi folks, thanks for the replies!
The best option is to just send a signal over DBus (system bus) that some updates were installed (ideally with some details). That can be picked up by any daemon in the user session and get translated to a persistent notification with a reboot button.
That's what I'm trying now, but using a socket instead of dbus because using a system-dbus to notify users won't work, and using user's dbus-session from a root daemon also doesn't work. I didn't think about an user-daemon trying to read from system-dbus, I'll check if I manage, we could remove the socket file communication and stick to dbus
@being notified of failed updates
Completely agree that's something needed! Right now the update process work with
t-u launches /usr/bin/rebootmgrctl reboot
if it manages to update successfully
Right now we do not have any hook on update failure in t-u, so we will need to add to that.
That might actually be available already through the transactional-update systemd unit. State changes are broadcasted over the system bus, so it would be possible to handle those as well. The error output is only available through the journal though.
Cheers, Fabian
Adding an update-failed to the user-facing daemon is trivial
At this point I'm thinking about moving this "talk with user-facing daemon" thing away from rebootmgr and bake it into transactional-update, something on the lines of
transactional-update cleanup dup **notify**
And set up a notification path (instead of a reboot one) in t-u itself
Will have to investigate how involved this is, the aim of this was just to provide a working solution while packagekit integration (and so discover and gnome-software) integration is finished.
So the idea was not to move too much stuff around and do not interfere too much also with non-desktop (microos/kubic) setups
Regards, Luca
Hi Fabian
That might actually be available already through the transactional-update systemd unit. State changes are broadcasted over the system bus, so it would be possible to handle those as well. The error output is > only available through the journal though.
As suggested I was playing around with systemd dbus messages for Properies Change, but it's a bit noisy, we can see with a simple dbus client here:
https://gist.github.com/89luca89/e6142aa2625d498515d0ccbd5f6cfaa9
Which simply prints some info when a specific unit changes state. Was testing with a tester-unit that would just execute a script with either "exit 0" or "exit 1" to simulate failures.
Sadly it seems way too noisy, for example, when it fails:
Status Changed.... Status Changed.... inactive dead Status Changed.... Status Changed.... activating start Status Changed.... Status Changed.... failed failed Status Changed.... Status Changed.... failed failed
when it's successful:
Status Changed.... Status Changed.... failed failed Status Changed.... Status Changed.... failed failed Status Changed.... Status Changed.... activating start Status Changed.... Status Changed.... inactive dead Status Changed.... Status Changed.... inactive dead
But I must note, I'm totally a dbus newbie, so surely I'm missing something here! Or maybe it's like this and we can do some cleanup of the output to detect better when we have a successful>failed and failed>successful change
Any inputs?
Cheers Luca
Hi again :-)
Wanted to add on the previous mail:
I've considered listening for 'org.opensuse.RebootMgr' signals, but they do not expose properties, and are only used by rebootmgrd to receive "commands".
I've also thought that if we want more info about how the update went, we have to bypass rebootmgr (or systemd property) completely
We should modify transactional-update to add another action (like, notify instead of reboot), and create a dbus channel for that. Right now t-u simply hard-calls the rebootmgrctl binary, so it cannot provide the information we need
Cheers Luca
Luca Di Maio wrote:
as discussed on the matrix channel, there is the need for MicroOS Desktop users to be notified about needed reboots for updates.
Brainstorming about it one of the solutions could be:
1 - reintroduce transactional-update.timer 2 - set up rebootmgr to work well with desktop workloads 3 - notify the user that the system is updated and a reboot is needed 4 - nice-to-have: if I click the notification it calls the native reboot prompt of the installed DE.
Earlier this year I refactored logind a bit with exactly that use case in mind :-) logind already has means to schedule shutdowns and exposes the time via dbus properties. It also sends notifications. So far only via wall message though. Doesn't take much to extend that to also have dbus signals I suppose. IOW I'd eliminate rebootmgr from the equation and go for a generic solution based on logind. That would work on any system then, not just microos based ones :-)
cu Ludwig
Ludwig Nussel wrote:
Luca Di Maio wrote:
as discussed on the matrix channel, there is the need for MicroOS Desktop users to be notified about needed reboots for updates. Brainstorming about it one of the solutions could be: 1 - reintroduce transactional-update.timer 2 - set up rebootmgr to work well with desktop workloads 3 - notify the user that the system is updated and a reboot is needed 4 - nice-to-have: if I click the notification it calls the native reboot prompt of the installed DE. Earlier this year I refactored logind a bit with exactly that use case
in mind :-) logind already has means to schedule shutdowns and exposes the time via dbus properties. It also sends notifications. So far only via wall message though. Doesn't take much to extend that to also have dbus signals I suppose.
Thanks Ludwig so you suggest to go t-u -> logind?
This could also come handy, but we need to work on logind to allow graphical notifications right?
Can you point me to the docs for those signals? thanks! L.
Luca Di Maio wrote:
Ludwig Nussel wrote:
Luca Di Maio wrote:
as discussed on the matrix channel, there is the need for MicroOS Desktop users to be notified about needed reboots for updates. Brainstorming about it one of the solutions could be: 1 - reintroduce transactional-update.timer 2 - set up rebootmgr to work well with desktop workloads 3 - notify the user that the system is updated and a reboot is needed 4 - nice-to-have: if I click the notification it calls the native reboot prompt of the installed DE. Earlier this year I refactored logind a bit with exactly that use case
in mind :-) logind already has means to schedule shutdowns and exposes the time via dbus properties. It also sends notifications. So far only via wall message though. Doesn't take much to extend that to also have dbus signals I suppose.
Thanks Ludwig so you suggest to go t-u -> logind?
This could also come handy, but we need to work on logind to allow graphical notifications right?
Can you point me to the docs for those signals? thanks!
Sorry for the late reply, I actually didn't read the list folder for a while :-) There are no such signals yet. Would have to be implemented upstream still. Meanwhile logind logs to to the journal at least though https://github.com/systemd/systemd/pull/23870
cu Ludwig
Ludwig Nussel wrote:
There are no such signals yet. Would have to be implemented upstream still. Meanwhile logind logs to to the journal at least though https://github.com/systemd/systemd/pull/23870 cu Ludwig
Probably adding those stuff to logind is a bit too much for me :) (for now) Maybe if someone can help me with packaging and testing of the current solution we could have some stopgap before implementing properly via logind?
Little update after a lot of time :)
I've removed rebootmgr from the equation and just left t-u and the notification daemon
Here is the notification daemon that also acts like the notification sender:
https://github.com/89luca89/transactional-update-notifier
Simply "transactional-update-notifier daemon" should be ran as user for each user logged in graphically
"transactional-update-notifier client" is triggered by transactional-update as a reboot method
Here is a patched transactional-update with the method added
https://github.com/89luca89/transactional-update/tree/feature/notify-method
I'm open to suggestions on other ways to implement this if needed.
We've discussed the use of "systemd-notify" on the Matrix channel, that in the end just uses Unix Socket files, like this daemon also does.
Cheers L.
-
Dario Faggioli -
Fabian Vogt -
Luca Di Maio -
Ludwig Nussel