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