snapstate: Check the status of refresh-pending snaps #12155
Conversation
sergio-costas
force-pushed
the
DT-576-snapd-refresh-awareness-ux-implementation
branch
3 times, most recently
from
0c01599
to
0800477
Compare
sergio-costas
changed the title
sergio-costas
force-pushed
the
DT-576-snapd-refresh-awareness-ux-implementation
branch
2 times, most recently
from
ed5006d
to
fce6679
Compare
|
The current code uses polling to detect when the process has ended, but it is only used while there is a pending refresh; when there are no snap refreshes blocked by a running process, it doesn't do polling, but waits to receive data from a Golang Channel. I tried to use "wait4" ("waitpid" seems to not be available) to avoid polling, but since the snap's processes aren't a child of snapd, the call returns directly. I could use inotify to detect when the cgroup files disappear without using polling, but that requires an external library because it isn't supported in "naive go"... is that OK? Finally, to re-launch the refresh process I'm currently calling the shell "snap refresh XXXXX". I preferred to do it that way because I'm still not very familiar with the code. Also, since it is being called from a thread, I'm afraid of race conditions. Anyway, I'm checking the "doSnapAction" call. |
|
doSnapAction isn't exported... |
sergio-costas
force-pushed
the
DT-576-snapd-refresh-awareness-ux-implementation
branch
2 times, most recently
from
7390066
to
d9d8c9c
Compare
sergio-costas
force-pushed
the
DT-576-snapd-refresh-awareness-ux-implementation
branch
from
d9d8c9c
to
5bdbaeb
Compare
|
@pedronis Can you check again this? |
|
@mvo5 I did the migration to a no-polling code using fsnotify (https://pkg.go.dev/gopkg.in/fsnotify/fsnotify.v1); but if you dislike that module (it's quite big), it is possible to just copy the two files of "inotify" (https://pkg.go.dev/k8s.io/utils/inotify) and have everything integrated. |
sergio-costas
force-pushed
the
DT-576-snapd-refresh-awareness-ux-implementation
branch
from
f148d62
to
999bb16
Compare
sergio-costas
force-pushed
the
DT-576-snapd-refresh-awareness-ux-implementation
branch
from
c1e786b
to
7ccf8e8
Compare
sergio-costas
force-pushed
the
DT-576-snapd-refresh-awareness-ux-implementation
branch
from
7ccf8e8
to
da9d8a7
Compare
sergio-costas
force-pushed
the
DT-576-snapd-refresh-awareness-ux-implementation
branch
4 times, most recently
from
b26f54c
to
5a27362
Compare
|
Ok, I created #12231 , which contains only the Snap monitoring code, as requested. That should simplify the revision process. When that MR is approved and merged, I will include the second part. |
This allow to not having to import UUID
Create and remove other folders in the folder being monitored to ensure that it doesn't affect the monitoring.
InDeleteSelf isn't triggered in /sys/fs, so we must monitor the parent folder.
Under some circumstances there can be a race condition when closing the inotify object. This code uses the native os.File functions to fix this.
If the main program stops reading from the Event channel and closes the inotify object, the read gofunc can get blocked. This patch fixes this by ensuring that it exits on close if it is waiting to write an event to the Event or Error channels.
If two threads try to monitor a snap, and it's the first time that MONITOR is called, there can be a race condition. This patch ensures that inotify is initialized once.
The "unsafe" pointer seems pointless. Also, there is no way that n is less than the size of an event, because, according to inotify documentation, if the buffer is too small, zero will be returned, and that's a case already being managed. Anyway, with a buffer of 64KBytes there is always size for, at least, one event (taking into account that NAME_MAX is 255 bytes in linux).
InDeleteSelf isn't triggered in /sys/fs
Now it shows a notification when the autorefresh begins, and another one when the snap has completed the autorefresh.
sergio-costas
force-pushed
the
DT-576-snapd-refresh-awareness-ux-implementation
branch
from
24d36cd
to
7a3d031
Compare
|
Closing this because all the work is being done in other branches. |
Every time snapd tries to refresh a snap and fails, sending to the user a message to close it, will monitor that snap to detect when it is closed, and issue a new refresh command in that precise moment.
Thanks for helping us make a better snapd!
Have you signed the license agreement and read the contribution guide?