[05:21] morning [05:33] 'morning! [05:55] mardy: heya [05:59] * _moep_ waves… [06:04] morning [06:14] good morning [07:19] o/ [07:42] pstolowski: zyga-mbp: hey [07:43] hey mborzecki ! [09:10] pstolowski: hi, https://github.com/snapcore/snapd/pull/10264 needs a re-review [09:10] pedronis: hi, sure, will do [09:10] thx [09:31] pstolowski: https://forum.snapcraft.io/t/snap-files-go-missing-after-reboot/25544 btrfs, sounds familiar to the problem we investigated before? [09:33] mborzecki: indeed, there was a similar problem with zfs [09:34] pstolowski: although root is on ext4, so it shouldn't matter [09:34] yeah, noticed that too [09:34] anyways, bit weird [11:01] * pstolowski lunch [11:01] hmm hmm, building images does not work for me anymore https://paste.ubuntu.com/p/Ggt7cW2VFK/ [11:01] not sure if it's due to the mtools update or something else [11:01] most likely the former [11:11] mborzecki no -f here [11:11] zyga-mbp: hm? [11:11] mborzecki which version of mtools do you have [11:11] upstream has 4.0.33 [11:12] I see 4.0.26-1 [11:12] zyga-mbp: 4.0.33 [11:14] heh [11:14] it's gnu [11:14] so no git [11:16] zyga-mbp: haha yeah, svn :P [11:19] fwiw, latest mtools in 21.10 is 4.0.32 [11:24] hmm this looks like a problem: `max available root directory slots: 0` [11:29] hm .0.32 works ok [11:53] anyway, i downgraded to 4.0.32 and filed https://bugs.archlinux.org/task/71547 [12:03] pstolowski: I (re-)reviewed the open validation-sets PRs [12:07] degville: would you rather I edit the forum page docs for quotas directly or should I make a gdoc to make suggestions? [12:08] ijohnson[m]: feel free to edit directly, but whatever's easier for you - thanks for looking. [12:25] pedronis: thank you [12:29] degville: ack, let me see how many edits I want to make and I'll let you know [14:14] are any of snapd's spread test used to test the store? my guess is no.. but was curious about that [14:18] pstolowski LXD socket broke againi [14:18] this time I had a LXD refresh [14:18] $ ls -ld /var/snap/lxd/common/lxd/unix.socket [14:18] srw-rw---- 1 root root 0 Jul 19 15:54 /var/snap/lxd/common/lxd/unix.socket [14:18] but I also rebooted [14:18] I suspect it's a racy operation somewhere [14:19] do you know what makes that socket? [14:20] doesn't lxd snap have a listen-stream in it's service definition in the snap.yaml [14:20] yeah, listen-stream: $SNAP_COMMON/lxd/unix.socket [14:20] * zyga-mbp looks [14:20] it does [14:20] it has a mode [14:20] but not group [14:21] so where does the group comes from [14:23] s/comes/come/ [14:23] my guess it lxc does chown somewhere [14:24] hmm [14:24] then I guess it is racy [14:24] whatever it does [14:24] maybe it only runs it sometimes [14:24] I bet we created the socket [14:24] and it just had the vanilla group ownership [14:25] yeah [14:25] nothing about lxd in the .socket file [14:25] (snap.lxd.daemon.unix.socket) [14:26] well ideally snapd would support system-usernames for the lxd user/group [14:26] then snapd would also support specifying the user/group in the service definition of the snap.yaml [14:30] zyga-mbp: /snap/lxd/current/commands/daemon.activate does it [14:30] chgrp "${daemon_group}" /var/snap/lxd/common/lxd/unix.socket [14:30] looking [14:31] hmmm [14:32] that's a one-shot command [14:32] if the socket gets re-created after it runs [14:32] then it's all broken [14:32] bummer [14:32] I wonder what exactly triggers this [14:54] the socket really shouldn't get re-created, that may seriously confuse long running client tools [14:55] we could probably paper over this behavior/issue using a refresh hook or something, but that seems to indicate something being more wrong elsewhere [14:57] stgraber: it happened twice to me on a hirsute server, I rebooted it once for some updates and otherwise just keep using it daily [14:58] I wonder if there's something I can set up to monitor that file, any file notification magic [14:58] in case it happens again [14:59] inotify may be able to pick it up [15:00] zyga-mbp: did you say it was after a refresh? [15:00] I don't think it was immediately after a refresh [15:01] but lxd did refresh earlier today at around 14:40 [15:01] I didn't use it for a few hours [15:01] I only mentioned it because earlier it happened (the problem) without a refresh [15:01] can you check the state of the snap.lxd.activate unit? [15:02] I've seen systems where it somehow got masked/disabled by snapd for some unknown reason [15:02] i think snapd would re-generate systemd units on refresh (and then it's system recreating the socket) [15:03] yeah, as much as I don't like snapd disabling/re-enabling everything, that should be fine, so long as it also starts the activate unit again which will then go and fix the ownership [15:03] but as I said, I've seen some systems where for some reason it would be stuck in disabled state, maybe that's what's hitting zyga-mbp [15:03] right [15:04] nb i see we have a TODO about supporting uid/gid [15:05] yeah, the tricky part with snapd supporting a user/group owner there is that it'd need to be user configurable and would need to be retrievable by the snap too [15:05] stgraber: what do you mean by user configurable ? [15:05] currently users can do "snap set lxd daemon.group=foo", so we wouldn't want to regress that [15:06] oh well yeah there's very little chance we will properly support that with system-usernames any time soon [15:08] yeah, figured as much ;) [15:08] :-D [16:47] in my mount-control branch, I'm unconditionally removing all systemd mount units for the snap in removeGeneratedWrappers() (which is in the link backend). Is this correct, or can it cause issues? [16:47] I'm asking because now the unit tests are failing, and I wonder if I should fix the tests or revert my change [20:02] stgraber lxd refreshed about an hour and a half ago and socket is back to root:root