| mborzecki | morning | 05:21 |
|---|---|---|
| mardy | 'morning! | 05:33 |
| mborzecki | mardy: heya | 05:55 |
| * _moep_ waves… | 05:59 | |
| pstolowski | morning | 06:04 |
| zyga | good morning | 06:14 |
| zyga-mbp | o/ | 07:19 |
| mborzecki | pstolowski: zyga-mbp: hey | 07:42 |
| pstolowski | hey mborzecki ! | 07:43 |
| 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:10 |
| mborzecki | pstolowski: https://forum.snapcraft.io/t/snap-files-go-missing-after-reboot/25544 btrfs, sounds familiar to the problem we investigated before? | 09:31 |
| pstolowski | mborzecki: indeed, there was a similar problem with zfs | 09:33 |
| 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 | 09:34 |
| * 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:01 |
| 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:11 |
| zyga-mbp | I see 4.0.26-1 | 11:12 |
| mborzecki | zyga-mbp: 4.0.33 | 11:12 |
| zyga-mbp | heh | 11:14 |
| zyga-mbp | it's gnu | 11:14 |
| zyga-mbp | so no git | 11:14 |
| mborzecki | zyga-mbp: haha yeah, svn :P | 11:16 |
| mvo | fwiw, latest mtools in 21.10 is 4.0.32 | 11:19 |
| mborzecki | hmm this looks like a problem: `max available root directory slots: 0` | 11:24 |
| mborzecki | hm .0.32 works ok | 11:29 |
| mborzecki | anyway, i downgraded to 4.0.32 and filed https://bugs.archlinux.org/task/71547 | 11:53 |
| pedronis | pstolowski: I (re-)reviewed the open validation-sets PRs | 12:03 |
| 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:07 |
| degville | ijohnson[m]: feel free to edit directly, but whatever's easier for you - thanks for looking. | 12:08 |
| pstolowski | pedronis: thank you | 12:25 |
| ijohnson[m] | degville: ack, let me see how many edits I want to make and I'll let you know | 12:29 |
| futuretim_ | are any of snapd's spread test used to test the store? my guess is no.. but was curious about that | 14:14 |
| 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:18 |
| zyga-mbp | do you know what makes that socket? | 14:19 |
| 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:20 |
| zyga-mbp | so where does the group comes from | 14:21 |
| zyga-mbp | s/comes/come/ | 14:23 |
| pstolowski | my guess it lxc does chown somewhere | 14:23 |
| 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:24 |
| zyga-mbp | yeah | 14:25 |
| zyga-mbp | nothing about lxd in the .socket file | 14:25 |
| zyga-mbp | (snap.lxd.daemon.unix.socket) | 14:25 |
| 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:26 |
| 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:30 |
| zyga-mbp | hmmm | 14:31 |
| 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:32 |
| stgraber | the socket really shouldn't get re-created, that may seriously confuse long running client tools | 14:54 |
| 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:55 |
| 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:57 |
| 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:58 |
| stgraber | inotify may be able to pick it up | 14:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| pstolowski | nb i see we have a TODO about supporting uid/gid | 15:04 |
| 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:05 |
| ijohnson[m] | oh well yeah there's very little chance we will properly support that with system-usernames any time soon | 15:06 |
| stgraber | yeah, figured as much ;) | 15:08 |
| ijohnson[m] | :-D | 15:08 |
| 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 | 16:47 |
| zyga-mbp | stgraber lxd refreshed about an hour and a half ago and socket is back to root:root | 20:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!