[05:09] <mborzecki> morning
[05:09] <brlin> morning
[05:12] <zyga> Hey hey
[05:13] <mborzecki> today's gonna be interesting
[05:22] <zyga> Why? :-)
[05:36] <mborzecki> zyga: alleged memleak, or rather trying to find out if we are the memory hogs
[06:07] <mborzecki> pulled down some random ubuntu core 16 image, came with snapd 2.32.5, can't refresh core because no updates available, wth?
[06:17] <wgrant> mborzecki: core updates have been disabled for the last 14h due to the memory hog situation
[06:17] <wgrant> But I'm minutes away from reenabling them
[06:17] <mborzecki> wgrant: thanks for the info
[06:28] <zyga> Interesting
[06:29] <zyga> Certainly more likely than pushing a deb to a repo
[06:29] <mborzecki> this is actually quite interesting 2.32.5 vs 2.38 vs 2.37.4/2.38 classic https://paste.ubuntu.com/p/Vs65Wyg8XW/
[06:29] <wgrant> mborzecki: core should be refreshable now.
[06:29] <zyga> s/likely/fun/
[06:30] <zyga> I’m with the dog outside
[06:30] <zyga> I’ll check back in the office
[06:30] <mborzecki> wgrant: thanks, updating :)
[06:31] <zyga> mborzecki: I have an idea
[06:31] <zyga> Is it hotplug?
[06:34] <mborzecki> zyga: idk, we can't turn off the feature anyway
[06:34] <mborzecki> zyga: fwiw, this doesn't look so bad
[06:35] <pedronis> mborzecki: to be clear, we more looking at kernel memory, than process memory at this point
[06:36] <zyga> Did we change compiler version?
[06:36] <pedronis> zyga: of course, remember we went from go 1.6 to go 1.10/1.11
[06:36] <mborzecki> pedronis: yeah, what i mean is that there doesn't seem to be an easily visible regression
[06:37] <mborzecki> pedronis: 2.32.5 was surely go 1.6
[06:37] <pedronis> yes
[06:37] <pedronis> think so
[06:38] <zyga> Mmmmm
[06:39] <zyga> Go changed the memory model recently
[06:39] <zyga> Well it maps much larger structures into memory without compression
[06:39] <zyga> But the garbage collector also changed significantly
[06:39] <pedronis> zyga: 6621 has two reviews,  and is now used, could just land, no?
[06:40] <pedronis> zyga: the question is, does it make the kernel use more space
[06:41] <pedronis> anyway I made a suggestion in email to test that to mborzecki
[06:41] <mborzecki> zyga: also memory is given back gradually in background, so rss will decrease but only after a while, we could call https://golang.org/pkg/runtime/debug/#FreeOSMemory though if the memory is lost elsewhere all this is in vain
[06:41] <zyga> pedronis: I think Chipaca wanted it to have an approved dependency first
[06:41] <zyga> But I will look
[06:41] <zyga> Still afk
[06:43] <zyga> pedronis: to the best of my knowledge it does use more kernel memory but it is a static, compile time decided cost
[06:44] <pedronis> we need to find out how much it is on arm 32
[06:45] <zyga> It is pretty huge AFAIK, dominates binary size
[06:45] <zyga> But
[06:45] <zyga> It is not a growing number
[06:46] <pedronis> we are probably talking past each other
[06:47] <mborzecki> pmap on 2.35.2 and 2.38 https://paste.ubuntu.com/p/xdm4tFhDwz/
[06:48] <mborzecki> hm .text grew, idk what's the r---- section of snapd, but it changed a bit, rw--- snapd is probably .bss, there's a change there, but rather insignificant
[06:52] <pedronis> mborzecki: you have email
[06:53] <pedronis> mborzecki: as I said, I don't think there is something obvious happening that relates only to user space mem
[06:54] <pedronis> no mvo yet to sync
[06:56] <mborzecki> pedronis: btw. rebuilding with 1.6 might be some effort, we made a transition to "context" and updated some http request context related things in the process
[06:56] <mborzecki> pedronis: 1.7 is probably worth a try though
[06:56] <pedronis> mborzecki: we can do the reverse
[06:56] <pedronis> buld 2.37 with 1.10
[06:57] <pedronis> if the issue is really only go runtime
[06:57] <zyga> back in the office now
[06:57] <pedronis> it might be apparent just that way
[06:57] <mborzecki> pedronis: right, that too
[06:57] <pedronis> (it might be a combination of a lot of things, then it's harder)
[06:57] <zyga> mborzecki: good idea on 2.37 with 1.10
[07:07] <pstolowski> mornings
[07:08] <mborzecki> ok, got 1.11 set up, and it's quite funny, https://paste.ubuntu.com/p/YFTYBSTmPJ/
[07:08] <mborzecki> going to try 1.10 next
[07:15] <zyga> mborzecki: ha
[07:15] <zyga> fun indeed
[07:16] <pedronis> mborzecki: interesenstingly though vsz is somewhat larger for 2.38 (not a problem, unless it really cuts into kernel resources though). anyway reminder the devices are arm 32
[07:17] <abeato> mvo, morning!
[07:18] <abeato> mvo, which is the current status of the systemd daemon-reload race? is the fix already in stable?
[07:19] <zyga> HOOOOLY MOLY
[07:19] <zyga> pidfd!!!!!
[07:19] <zyga> hahahaha
[07:19]  * zyga is super happy
[07:21] <mvo> abeato: the systemd fix went to the distro yesterday, it will be part of the next stable core
[07:21] <mvo> abeato: if its import for the customer we can do a .1 with just these changes
[07:22] <abeato> mvo, hm, when is the next stable core snap expected?
[07:23] <mvo> abeato: 4-6 weeks if nothing else comes up
[07:23] <mvo> abeato: because 19.04 is released soonish we may do a .1 if we find any bigger issues this is why its a bit up in the air right now
[07:24] <mvo> abeato: we are debugging a customer issue that may require a .1 but its a bit unclear where we stand on this right now (i.e. if its a snapd, kernel, $unknown issue)
[07:24] <abeato> mvo, ok, I do not think it is extremely urgent, will let you know if that changes - it depends mostly on when we release the GA image
[07:48] <mborzecki> 2.37 & 2.38 with go 1.10 https://paste.ubuntu.com/p/Snt9mqK3m5/
[07:54] <pedronis> ~0.5G more vmem
[08:00] <mup> PR snapd#6629 closed: overlord/snapshotstate: helpers for snapshot expirations (automatic snapshots 2/4) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6629>
[09:08]  * zyga spends some time to manage paperwork and the endless list of open browser tabs
[10:35] <mup> PR snapd#6595 closed: tests: add regression test for systemctl race fix <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6595>
[10:44] <zyga> mvo: what shall we do about core18?
[10:44] <mvo> zyga: aha, sorry, I forgot about this, let me look at this
[10:44] <zyga> mvo: do you want to HO?
[10:44] <zyga> might be easier
[10:47] <mvo> zyga: let me quickly poke at this for some minutes to familiarize myself
[10:49] <mup> PR snapcraft#2522 closed: build providers: add API for friendly instance type names <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2522>
[10:59] <pedronis> zyga: mvo: I need to be in that HO
[10:59] <pedronis> if/when we have one
[11:03]  * pstolowski lunch
[11:07] <Chipaca> ask me if my parents' wifi goes away when they use the microwave
[11:12] <mvo> zyga: lets talk after the standup, I have lunch now and then I have a meeting, maybe if this meeting is shorter we can also talk before
[11:12] <zyga> mvo: ping me when you are ready to talk
[11:12] <mvo> zyga: but yeah, we need to decide, I think I hvae a slightly better idea now what is going on.
[11:12] <mvo> zyga: thanks again for raising this!
[11:13] <pedronis> mvo: zyga: ping me when you have it
[11:13] <zyga> ack
[11:23]  * Chipaca ⇝ lunch
[11:31] <mup> PR snapd#6691 opened: Move extractkernelassets <Created by kubiko> <https://github.com/snapcore/snapd/pull/6691>
[11:32]  * zyga break
[11:33] <zyga> ondra: reworded that PR a little
[11:34] <ondra> zyga yeah more fitting
[11:34] <ondra> zyga thanks :)
[11:40]  * zyga really break now
[11:52] <pstolowski> re
[12:07] <zyga> Son_Goku: hey, on F30 I cannot get snapd update because of some gnome-software dependency mismatch,
[12:07] <zyga> Son_Goku: is that expected?
[12:08] <Son_Goku> no?
[12:08] <Son_Goku> what are you seeing?
[12:09] <zyga> I don't have that machine with me but it was saying something that gnome-software depends on snapd-auth-provider or something to that vein
[12:09] <zyga> and that was it, no 2.38
[12:09] <Son_Goku> fuck
[12:09] <Son_Goku> snapd-login-service dependency is still in gnome-software
[12:09] <Son_Goku> damn it
[12:10] <Son_Goku> I have to put it back now
[12:11] <zyga> :D
[12:11] <zyga> Son_Goku: so what just happened?
[12:11] <Son_Goku> well, I decided to rip out an old Provides
[12:11] <Son_Goku> when snapd-login-service was retired, I obsoleted it by snapd
[12:11] <Son_Goku> but gnome-software-snap requires it still :(
[12:12] <zyga> sorry I didn't vote on the update before, I noticed others did
[12:12] <zyga> but those must have been headless machines
[12:12] <zyga> my laptop complained
[12:22] <mborzecki> zyga: yup i tried the update in a headless vm
[12:24] <pstolowski> mborzecki: https://github.com/snapcore/snapd/pull/6661 has 3 +1s, can land?
[12:24] <mup> PR #6661: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6661>
[12:24] <mborzecki> pstolowski: i'm pushing the fix for the test zyga suggested
[12:24] <pstolowski> ack
[12:26] <jdstrand> oSoMoN: hey, I'm still slogging through the chromium approvals. it is a large snap so it takes a while for the next revision to be reviewed after I approve one
[12:28] <oSoMoN> jdstrand, thanks!
[12:36]  * Chipaca shakes his fist at doLinkSnap
[12:43] <mvo> zyga, pedronis I am free now if you want we can chat about /var/lib/snapd/void and friends
[12:44] <pedronis> mvo: I can join standup
[12:45] <mvo> pedronis: I'm there now, ready when you are
[12:45] <mvo> zyga: -^
[12:47] <zyga> mvo: same
[12:48] <zyga> joining
[13:28] <mup> PR snapcraft#2520 closed: snap: set core as a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2520>
[13:30] <mup> PR snapd#6616 closed: boot: add flag file "meta/force-kernel-extraction" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6616>
[13:51] <mup> Bug #1823343 opened: Getting Started Intro out of date <Snappy:New> <https://launchpad.net/bugs/1823343>
[14:08] <mup> PR snapd#6692 opened: interfaces: cleanup internal tool lookup in system-key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>
[14:09] <mup> PR snapd#6693 opened: cmd: tweak internal tool lookup to accept more possible locations <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6693>
[15:16] <mup> PR snapcraft#2523 opened: ci: improve travis integration conditionals <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2523>
[17:04] <Chipaca> pedronis: you can't have an alias for a snap name, right?
[17:07] <noise][> Chipaca: correct, no such thing
[17:07] <Chipaca> noise][: I meant, an alias in one snap that was the name of a different snap
[17:07] <Chipaca> noise][: like, aliasing tree-classic to 'tree', which is the name of a snap
[17:08] <noise][> nope
[17:10] <pedronis> Chipaca: you can but is very much discouraged because you cannot then install conflicting snaps around it in any way at the same time
[17:11] <pedronis> we don't let you override the commands of another snap
[17:11] <Chipaca> so this tree-strict and nano-strict thing is not gonna fly
[17:11] <noise][> oh, i think i misunderstood
[17:12] <pedronis> Chipaca: it depends, it means you cannot install nano and nano-strict at the same time
[17:12] <Chipaca> pedronis: right, but what happens if you try?
[17:12] <noise][> but you wouldn't
[17:12] <pedronis> you get an error
[17:13] <pedronis> about namespace conflicts
[17:13] <Chipaca> i mean i'd like to see that ux
[17:13] <pedronis> when you install the 2nd
[17:13] <Chipaca> … but i have enough on my plate already
[17:13] <noise][> but the existence of `tree`, not installed, does not preclude a snap tree-strict from aliasing 'tree' , right?
[17:13] <pedronis> no
[17:14] <pedronis> it's up to the alias reviewer in the store
[17:14] <pedronis> we didn't implement strict checks there about this
[17:14] <Chipaca> I should clarify in the forum then
[17:14] <Chipaca> pedronis: what do you mean by 'strongly discouraged' btw
[17:15] <Chipaca> because the people reviewing and approving aliases didn't even bring it up
[17:15] <pedronis> that if the snaps  are unrelated
[17:15] <pedronis> you will just bring confusion into the world
[17:15] <pedronis> a snap owns its name
[17:15] <pedronis> you are basically giving it away
[17:16] <Chipaca> pedronis: that doesn't sound like 'strongly discouraged' beyond the abstract sense. I mean, what steps have been taken to discourage it?
[17:16] <noise][> it seems perfectly reasonable to me to allow for 'foo' and 'foo-classic' snaps that are the same thing but one with classic confinement.
[17:17] <pedronis> noise][: there yare related though, which is actually not a typical case at all
[17:17] <noise][> for the case outlined with tree or jq or whatever where there's a desire to be able to use them on Core systems
[17:17] <pedronis> at it wasn't a typical case when aliases were designed
[17:17] <noise][> both from the same publisher
[17:17] <noise][> or i mean that would be the preferred scenario
[17:19] <pedronis> Chipaca: the guideline around aliases as always been to avoid clashes
[17:19] <brlin> popey suggested using a separate `classic` track for the alternative classic confined versions, which may mitigate the problem
[17:20] <pedronis> Chipaca: that included with other snap names, maybe is not splelt out but was in our mind
[17:21] <brlin> For the alias problem if there's a popular fork the same name software, like `blender-some-popular-edition`, people might want to make alias of the original name
[17:21] <Chipaca> brlin: o/
[17:22] <Chipaca> now I just want to have a snap with an alias for another snap just to see how it explodes
[17:23] <pedronis> Chipaca: I can point you at the errors
[17:23] <noise][> classic confinement is at the snap level, can't be per-track
[17:23] <pedronis> noise][: classic confinement just means you can have classic confinement in some revisions
[17:24] <pedronis> whether we enforce more I don't know
[17:24] <pedronis> Chipaca: to be clear we didn't design thinking that this would be a common case that we would need to guide people around
[17:25] <noise][> right, i mean we don't have a way to selectively enforce
[17:25] <Chipaca> brlin: updated both topics with a summary of the above. I don't think [revoked] is correct … even if I were correct, i'm not a reviewer :-)
[17:25] <brlin> noise][: Then I guess the separate name space and overriding alias is the only way to go :-/
[17:25] <Chipaca> to be clear, _allowing_ classic is not per-track, but a snap being classic is per revision
[17:25] <noise][> what Chipaca said :)
[17:26] <Chipaca> so you _could_ have a channel be classic and a channel be strict, but you could ship a classic one in the strict track by accident
[17:26] <noise][> this certainly could bear more discussion, but it's Friday afternoon
[17:26] <noise][> yeah, so it's possible we could allow that route for some snaps and just have to trust the publisher not to break people on the strict track
[17:26] <Chipaca> also bears don't like discussion
[17:27] <noise][> and then at some point add guardrails, but i'd like to explore this more before recommending such an approach
[17:27] <pedronis> Chipaca: errors are here  https://github.com/snapcore/snapd/blob/master/overlord/snapstate/aliasesv2.go#L339 and here https://github.com/snapcore/snapd/blob/master/overlord/snapstate/aliasesv2.go#L368
[17:28] <brlin> The snap edit page on LaunchPad seemed to support this fashion AFAICT https://usercontent.irccloud-cdn.com/file/prUHOKkw/image.png
[17:31] <brlin> FYI the users of the `nano` snap are currently blocked from auto-updates due to the confinement switch
[17:32] <Chipaca> yeah, confinement switches are nasty
[17:32] <Chipaca> they'll be getting warnings at some point
[17:32] <noise][> that's why, e.g. with tree, that i suggest not messing with confinement of the existing snap
[17:32] <Chipaca> that's #1811063 FWIW
[17:33] <mup> Bug #1811063: "snap refresh" does not report failure to update because snap switched to classic confinement <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1811063>
[17:33] <noise][> anyway, i need to run, happy weekend!
[17:33] <Chipaca> same here
[17:33] <Chipaca> brlin: ttfn, have a good one
[17:33] <pedronis> also to be clear you can install both snaps, but you need to manouver around, and the one with the actual name (vs the alias) needs to win
[17:33] <pedronis> (you'll need to use snap unalias and/or install --unaliased)
[17:34] <brlin> Chipaca: Bye!
[17:55] <mup> PR snapcraft#2523 closed: ci: improve travis integration conditionals <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2523>
[18:12] <cachio> mvo, hey
[18:13] <cachio> mvo, I know which is the problem with the install --dangerous in core18
[18:31] <zyga> cachio: tell us!
[18:33] <cachio> zyga, so, the problem is in the tests
[18:34] <cachio> basically when it is installing --dangerous is downloading the core snap as part of that process
[18:34] <cachio> even when we have the core snap in /var/lib/snapd/snaps
[18:34] <zyga> oh
[18:34] <zyga> that's very curious
[18:34] <zyga> cachio: thank you
[18:36] <cachio> zyga, do you know if snapd is searching in the state to define if a snap could be in the cache?
[18:36] <zyga> cachio: I don't know yet, we will check it out
[18:36] <zyga> snapd uses the cache for sure
[18:36] <zyga> but repackaged core has different cache
[18:36] <zyga> so perhaps that's one issue
[18:36] <zyga> s/cache/hash/
[18:38] <cachio> zyga, https://paste.ubuntu.com/p/J3w8bxrqfm/
[18:38] <cachio> in the first install it downloads the core snap, even when it is already in /var/lib/snapd/snaps/
[18:38] <cachio> but second time it is not downloading it
[18:39] <cachio> zyga, I don't know why
[18:39] <zyga> cachio: what is in /var/cache/snapd?
[18:39] <zyga> the one in /var/lib/snapd/snaps is, I think, irrelevant now
[18:39] <zyga> the one in /var/lib/cache/snapd matters
[18:39] <zyga> I mean, irrelevant only if not installed
[18:40] <cachio> zyga, https://paste.ubuntu.com/p/qvj5QCgkwK/
[18:40] <zyga> that's odd
[18:40] <zyga> so some back story
[18:40] <zyga> last week, for local testing in qemu
[18:41] <zyga> I wrote some patches that let me seed /var/cache/snapd with heavy snaps
[18:41] <zyga> then tests only fetch assertions online, speeding up testing tremendously
[18:41] <zyga> the way I did this was by keeping /var/cache/snapd.tar.gz in the qemu image and unpacking it early in the test prepare
[18:41] <zyga> it works for that purpose
[18:42] <zyga> the files there are not .snap files but instead long file names based on some hash of the content
[18:42] <zyga> snapd uses that cache as hardlink source AFAIK
[18:42] <zyga> so I'm surprised to see none of that in the cache directory here?
[18:42] <zyga> ah
[18:42] <zyga> sorry
[18:42] <zyga> I'm mistaken
[18:42] <zyga> the path is different
[18:43] <zyga> the correct path is /var/lib/snapd/cache
[18:43] <zyga> that's the one
[18:43] <zyga> I was arguing with chipaca to change it because it's odd that we have two cache directories
[18:43] <zyga> anyway
[18:43] <zyga> please look at /var/lib/snapd/cache
[18:43] <zyga> before / after snap install --dangerous
[18:44] <cachio> https://paste.ubuntu.com/p/RdbGtyc79c/
[18:44] <cachio> zyga, seems to be there
[18:44] <zyga> that's more like it
[18:44] <zyga> what happens when you remove and install a snap?
[18:44] <zyga> it should reuse that cache and do things "instantly"
[18:46] <cachio> zyga, the core is not installed in my machine but it is in cache dir
[18:46] <cachio> so, I think I know what I need to change to cache snaps in the tests
[18:46] <zyga> I will check later (eating dinner now) but perhaps --dangerous implies some of the hash based logic doesn't get used
[18:46] <cachio> what we are doing currently doesn't work
[18:46] <zyga> cachio: cool
[18:47] <zyga> cachio: looking forward to that patch :D
[18:47] <cachio> zyga, --dangerous works well
[18:47] <cachio> but basically we need to install/remove the snap to cache it before we save the state
[18:47] <cachio> that should be enough
[18:47] <zyga> yep
[18:48] <cachio> currently we are copying to /var/lib/snapd/snaps the .snap file but it is not enough
[18:48] <zyga> cachio: as a hint
[18:48] <zyga> cachio: perhaps to speed things up more
[18:48] <zyga> cachio: instead of creating a tarball of /var/lib/snapd/cache
[18:49] <cachio> zyga, yes, could be, I'll make then change
[18:49] <zyga> cachio: make a directory, say /var/lib/snapd-cache
[18:49] <cachio> zyga, thanks for the help
[18:49] <zyga> cachio: wait :)
[18:49] <zyga> cachio: and hardlink the cache items there
[18:49] <zyga> cachio: then instead of unpacking that tarball
[18:49] <zyga> cachio: hardlink them back
[18:49] <zyga> cachio: this will be instant
[18:49] <zyga> cachio: and will work just like a tarball would
[18:49] <cachio> zyga, perfect, I'll do that
[18:50] <cachio> thanks for the info
[18:50] <zyga> cachio: cp has some options, perhaps there are some that do hardlink copies
[18:50] <zyga> cachio: good luck!
[18:51] <cachio> zyga, thnanks
[18:51] <cachio> enjoy your weekend
[18:51] <zyga> likewise :)
[18:54] <pedronis> --dangerous doesn't use the cache
[18:54] <pedronis> (the cache is for downloads)
[18:54] <zyga> pedronis: oh?
[18:54] <pedronis> why would it
[18:54] <pedronis> you are giving it a snap here
[18:54] <zyga> pedronis: for dependencies
[18:54] <zyga> pedronis: it downloads core over and over
[18:54] <pedronis> that is stranger
[19:22] <cachio> pedronis, I think install --dangerous is using the cache
[19:22] <cachio> I just see that the core is not being downloaded it is correctly cached
[19:24] <cachio> pedronis, the problem we have is that we are caching the snaps in the wrong way on our test suite
[19:25] <cachio> so when I run on the boards and vms 5/6 in parallel in my home all the installs we do are downloading hte core
[19:25] <cachio> and this is the bottleneck which is causing the install --dangerous is getting stuck
[19:45] <mvo> 6687 needs a second review, should be simple
[19:45] <mup> PR snapd#6689 closed: tests: run create-user on core devices <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6689>
[20:38] <mup> PR snapd#6694 opened: tests: improve how snaps are cached <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6694>
[20:43]  * cachio afk
[21:32] <mup> PR snapcraft#2524 opened: Snapcraft try <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2524>
[21:45] <jdstrand> pedronis: ok, I got through all the store review stuff and knocked out 5 PR reviews (well, one was asking for a different approach). I will do PR 6502 and PR 6605 on monday
[21:45] <mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6502>
[21:45] <mup> PR #6605: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/6605>
[21:45] <jdstrand> zyga: fyi ^
[21:46] <jdstrand> there is a small chance I'll look at those over the weekend, but let's say 'by my eod Monday'
[21:46] <jdstrand> pedronis: I also responded to https://forum.snapcraft.io/t/phase-1-of-opt-in-per-snap-users-groups-aka-the-daemon-user/10624/15
[21:52] <ijohnson> jdstrand: hey! the dockerd daemon now needs to use data inside $XDG_RUNTIME_DIR, which ends up being /run/user/0 for the daemon, but this dir isn't created... what's the eventual resolution to lp #1656340 do you think?
[21:52] <mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340>
[21:52] <ijohnson> for now I will just overwrite that to be $SNAP_COMMON/run and it works, but just curious as I seem to recall discussion around that bug recently on this channel