Reboot Required - Notification

[web31978]

Thank you for the reply on this Joseph. I have checked that /var/run directory and I do not see that file, however, I still see the reboot required in the UI.

[matix131997]

I was just about to write a topic about this problem.
I too have the same problem after updating the latest version of Cloudron. So far the reboot notification has disappeared after resetting the server. Currently, the reboot notification is still showing after resetting.

[web31978]

I can also confirm that even though I have Upgraded from 22.04 to Ubuntu 24.04 (Noble Numbat) following the official Cloudron docs at https://docs.cloudron.io/guides/upgrade-ubuntu-24/?ref=blog.cloudron.io and successfully upgrading I'm still seeing the persistent reboot notification in the UI. I have even tried rebooting from both the Vultr console and through the System Info panel within the Cloudron UI to no avail

[web31978]

I've also verified the non-existence of reboot-required, here was my steps:

First, check if the file exists:

ls -l /var/run/reboot-required

verify when your system was last rebooted using:

uptime

or

last reboot

After the reboot:

Check if the file still exists:

ls -l /var/run/reboot-required

check the system logs to verify the reboot actually occurred:

journalctl --boot

or

dmesg | grep -i 'Linux version'

[SansGuidon]

I confirm the notification persists also for me (Ubuntu 22.04) despite 2 successive reboots.

[joseph]

Note that the notification does not disappear. It simply becomes unread. I guess you are expecting the notification to be hidden/invisible after a reboot?

[SansGuidon]

@joseph said in Reboot Required - Notification:

Note that the notification does not disappear. It simply becomes unread. I guess you are expecting the notification to be hidden/invisible after a reboot?

Yes as the notification contains an action and as long as the notification and call to action remain active and visible I assume the reboot procedure has failed to be acknowledged by Cloudron.

I would expect the reboot action to be disabled after reboot is done - clearer for me. Mark read/unread is not enough it doesn't tell me the reboot and security patches are applied.

[nebulon]

Since we are working on replacing angular 1 with vuejs in the dashboard currently, we will also rework those notification styles to make this more clear then.

[web31978]

Previously, the notification disappeared after rebooting, but that's no longer happening. Like @SansGuidon mentioned, when I see the notification, I assume a reboot is needed - which is exactly why we implemented this notification system in the first place.

Very misleading in the current iteration.

[scooke]

@web31978 I don't understand this. You manage the Cloudron, or someone else? Active notifications have that small strip of color to the left. If there is no strip, it's been viewed and presumably acted upon. So, you look at Notifications... and don't act on them? I suppose I might forget, but in that case we have the Event Log, which can show you up to ONE HUNDRED events, to check if something needing action happened or not.

I wouldn't call this misleading, especially since you, the manager, aren't acting on the Notifications, or otherwise making note of what needs to happen. I mean, now you can even get an email notification about these things... will it be Cloudron's fault if your email client flags it as spam and you never see it?

All that said, I suppose having yet MORE options in the Notifications Dashboard would be useful. What will they do next though? The colours give an idea as to what's new, and it's seriousness. Once you've read them the colours disappear but you want something to remain visually that you didn't actually act on it?

[web31978]

@scooke I wanted to clarify my concern about this issue. Previously, after a system reboot was completed, the "reboot" button in notification would automatically fade to grey and disable the reboot button. This functionality appears to have changed (button remains clickable and red). The color difference you mentioned wasn't actually my concern. At this point, I understand this is the new expected behavior, so I consider this matter resolved.