| 2024-04-05 15:05:36 |
Alfonso Sanchez-Beato |
bug |
|
|
added bug |
| 2024-04-05 15:06:03 |
Alfonso Sanchez-Beato |
description |
On UC24 (noble based) I see warnings like this on boot:
Apr 05 14:36:55 qemuname systemd[1]: snapd.service: Got notification message from PID 1002, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1039, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1040, but reception only permitted for main PID 917
where PID XXXX is the snapd pid. This seems to happen because some process is sending requests to the systemd-notify socket while not being the main snapd PID. This can be reproduced in scenarios where snapd is reexeced, but not for instance if we stop snapd and socket and launch snapd from the command line.
On installation, quite a few of these happen, but they are seen also in run mode.
Adding "NotifyAccess=all" in snapd.service "fixes" the issue, but it is not clear if that is the right approach as we might be sending wrong notifications (like notifying a stop when snapd exits because another snapd process is already running).
So the right fix might be more in the direction of avoiding systemd notifications if not running as a service.
References:
[1] systemd-notify(1)
[2] |
On UC24 (noble based) I see warnings like this on boot:
Apr 05 14:36:55 qemuname systemd[1]: snapd.service: Got notification message from PID 1002, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1039, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1040, but reception only permitted for main PID 917
where PID XXXX is the snapd pid. This seems to happen because some process is sending requests to the systemd-notify socket while not being the main snapd PID. This can be reproduced in scenarios where snapd is reexeced, but not for instance if we stop snapd and socket and launch snapd from the command line.
On installation, quite a few of these happen, but they are seen also in run mode.
Adding "NotifyAccess=all" in snapd.service "fixes" the issue, but it is not clear if that is the right approach as we might be sending wrong notifications (like notifying a stop when snapd exits because another snapd process is already running).
So the right fix might be more in the direction of avoiding systemd notifications if not running as a service.
References:
[1] systemd-notify(1)
[2] sd_notify(3) |
|
| 2024-04-05 15:11:58 |
Alfonso Sanchez-Beato |
description |
On UC24 (noble based) I see warnings like this on boot:
Apr 05 14:36:55 qemuname systemd[1]: snapd.service: Got notification message from PID 1002, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1039, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1040, but reception only permitted for main PID 917
where PID XXXX is the snapd pid. This seems to happen because some process is sending requests to the systemd-notify socket while not being the main snapd PID. This can be reproduced in scenarios where snapd is reexeced, but not for instance if we stop snapd and socket and launch snapd from the command line.
On installation, quite a few of these happen, but they are seen also in run mode.
Adding "NotifyAccess=all" in snapd.service "fixes" the issue, but it is not clear if that is the right approach as we might be sending wrong notifications (like notifying a stop when snapd exits because another snapd process is already running).
So the right fix might be more in the direction of avoiding systemd notifications if not running as a service.
References:
[1] systemd-notify(1)
[2] sd_notify(3) |
On UC24 (noble based) I see warnings like this on boot:
Apr 05 14:36:55 qemuname systemd[1]: snapd.service: Got notification message from PID 1002, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1039, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1040, but reception only permitted for main PID 917
where PID XXXX is the snapd pid. This seems to happen because some process is sending requests to the systemd-notify socket while not being the main snapd PID. This can be reproduced in scenarios where snapd is reexeced, but not for instance if we stop snapd and socket and launch snapd from the command line. If we just stop snapd and launch snapd from the command line the messages appear though.
On installation, quite a few of these happen, but they are seen also in run mode.
Adding "NotifyAccess=all" in snapd.service "fixes" the issue, but it is not clear if that is the right approach as we might be sending wrong notifications (like notifying a stop when snapd exits because another snapd process is already running).
So the right fix might be more in the direction of avoiding systemd notifications if not running as a service.
References:
[1] systemd-notify(1)
[2] sd_notify(3) |
|
| 2024-04-05 17:42:23 |
Alfonso Sanchez-Beato |
description |
On UC24 (noble based) I see warnings like this on boot:
Apr 05 14:36:55 qemuname systemd[1]: snapd.service: Got notification message from PID 1002, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1039, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1040, but reception only permitted for main PID 917
where PID XXXX is the snapd pid. This seems to happen because some process is sending requests to the systemd-notify socket while not being the main snapd PID. This can be reproduced in scenarios where snapd is reexeced, but not for instance if we stop snapd and socket and launch snapd from the command line. If we just stop snapd and launch snapd from the command line the messages appear though.
On installation, quite a few of these happen, but they are seen also in run mode.
Adding "NotifyAccess=all" in snapd.service "fixes" the issue, but it is not clear if that is the right approach as we might be sending wrong notifications (like notifying a stop when snapd exits because another snapd process is already running).
So the right fix might be more in the direction of avoiding systemd notifications if not running as a service.
References:
[1] systemd-notify(1)
[2] sd_notify(3) |
On UC24 (noble based) I see warnings like this on boot:
Apr 05 14:36:55 qemuname systemd[1]: snapd.service: Got notification message from PID 1002, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1039, but reception only permitted for main PID 917
Apr 05 14:36:56 qemuname systemd[1]: snapd.service: Got notification message from PID 1040, but reception only permitted for main PID 917
where PID XXXX is the snapd pid. This seems to happen because some process is sending requests to the systemd-notify socket while not being the main snapd PID. This can be reproduced in scenarios where snapd is reexeced, but not for instance if we stop snapd and socket and launch snapd from the command line. If we just stop snapd and launch snapd from the command line the messages appear though.
On installation, quite a few of these happen, but they are seen also in run mode.
Adding "NotifyAccess=all" in snapd.service fixes the issue, but it is not clear if that is the right approach as we might be sending wrong notifications (like notifying a stop when snapd exits because another snapd process is already running).
So the right fix might be more in the direction of avoiding unnecessay systemd notifications.
References:
[1] systemd-notify(1)
[2] sd_notify(3) |
|
| 2024-04-08 20:36:46 |
Sergio Cazzolato |
snapd: status |
New |
Fix Committed |
|
| 2024-04-08 20:36:49 |
Sergio Cazzolato |
snapd: importance |
Undecided |
High |
|
| 2024-04-10 16:04:18 |
Ernest Lotter |
snapd: milestone |
|
2.63 |
|
| 2024-04-15 16:38:22 |
Laurent Bonnaud |
bug |
|
|
added subscriber Laurent Bonnaud |
