[00:01] how do i compile "snap" command in order to test it? [00:01] before i submit a patch [00:01] shawn@shawn-desktop:~/git/snapd$ go get github.com/snapcore/snapd [00:01] package github.com/snapcore/snapd: no Go files in /home/shawn/go/src/github.com/snapcore/snapd [00:10] * scientes just found HACKING.md === chihchun_afk is now known as chihchun [05:08] morning [05:22] Hi [05:24] zyga: new, intersting developments from flock? [05:24] some hands-on session on AWS CLI snap [05:25] our presentation is today so I'llbe focusing on that [05:25] what is wrong with master? /home/gopath/src/github.com/snapcore/snapd/tests/lib/prepare.sh: line 413: 1: command not found [05:25] + /snap/bin/ubuntu-image -w /home/image /home/image/pc.model --channel edge '' --extra-snaps /home/image/snapd_2.34.3_amd64.snap --output /home/image/core18-amd64.img [05:25] /home/gopath/src/github.com/snapcore/snapd/tests/lib/prepare.sh: line 288: 29999 Segmentation fault (core dumped) /snap/bin/ubuntu-image -w "$IMAGE_HOME" "$IMAGE_HOME/pc.model" --channel "$IMAGE_CHANNEL" "$EXTRA_FUNDAMENTAL" --extra-snaps "${extra_snap[0]}" --output "$IMAGE_HOME/$IMAGE" [05:28] mborzecki: can you please ask mvo to ack the last two revisions of fedora29 again [05:29] mborzecki: unfortunately the store has no memory so it blocks every upload I do [05:34] zyga: https://github.com/snapcore/snapd/pull/5625 [05:36] zyga: anyways, for all we know that check will be passing now, but the segfault will probably still be there [05:36] thanks === chihchun is now known as chihchun_afk [06:05] zyga: maciek@corsair:~ ubuntu-image --help [06:05] zsh: segmentation fault (core dumped) ubuntu-image --help [06:05] Must be Friday [06:07] zyga: all channels have the same version, it's also a classic snap, maybe it's something else that's causing this [06:23] mborzecki: could be [06:23] zyga: can you install ubuntu-image snap locally? [06:25] re [06:25] mborzecki: trying [06:26] it doesn't crash here [06:26] but then python complains about lack of dpkg [06:27] is mvo around today? [06:31] mvo: hello [06:31] mvo: may I ask you to approve fedora29 uploads again [06:31] zyga: goood morning! when is your presentation? [06:31] zyga: sure [06:31] mvo: 11:20 [06:31] mvo: I found some more bugs but worked around them [06:32] mvo: and this should also make it work on ubuntu now [06:32] zyga: you can always telegram me when things are urgent [06:32] (just btw) [06:32] zyga: nice! [06:32] mvo: thank you! I didn't want to bother you last night [06:33] mvo: https://gitlab.com/zygoon/fedora29 in case you want to cross ref what you approve [06:33] zyga: thanks looking [06:33] there are tags referencing store uploads [06:34] * zyga is pretty happy with the makefile there :) [06:35] zyga happy with the makefile :) heh [06:35] it looks nice as a makefile :) [06:36] hehe [06:37] yay, only 3 builds for snapcraft left, meaning snapd will start soon right? [06:38] mvo: thank you, you should be able to refresh fedora29 now [06:38] and it, _fingers crossed_ should work [06:38] zyga: i'm stepping through ubuntu-image with gdb now, take a look at this https://paste.ubuntu.com/p/RQWc2Rcr2f/ [06:39] that's why snap run --shell also exits with a segfault here [06:39] mborzecki: woah? [06:39] I have no idea why this would crash, do you have any clues? [06:41] zyga: heh, LD_LIBRARY_PATH=/snap/ubuntu-image/100/usr/lib:/snap/ubuntu-image/100/lib:/snap/ubuntu-image/100/usr/lib/lib-arch:/snap/ubuntu-image/100/lib/lib-arch /bin/bash -> segfault [06:42] mborzecki: which linker is this using? [06:44] mvo, mborzecki: is hello-fedora working for you guys now? [06:44] zyga: the host's, the segfault is actually in the liner #0 0x00007f7c49694b31 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2 [06:44] mborzecki: that's the bug [06:44] it should use ld-so from the core snap [06:46] zyga: but it's a script, https://paste.ubuntu.com/p/XGsxrdjTWP/ [06:46] right [06:46] but _broken_ [06:47] it must invoke the linker [06:47] to avoid using the host linker [06:47] but anyway [06:47] why did it break, what changed? [06:47] let me check some other classic snaps [06:47] zyga: there was a glibc & python update i believe [06:49] mborzecki: try python0 [06:49] it should work everywhere [06:49] but it was made by me [06:49] so it's a bit more special [06:49] if that crashes then the world is broken [06:49] zyga: heh upgraded glibc (2.27-3 -> 2.28-1) [06:49] it if works then we can look for more clues [06:50] mborzecki: good morning! [06:50] mvo: heya [06:51] btw, I see red tests in the most recent PRs, anything going on with CI? or just some bad PRs ;) [06:51] zyga: let me check [06:51] mvo: ubuntu-image segvfaults [06:51] mvo: maciej is looking at that [06:51] boooo [06:51] mborzecki, zyga: thanks [06:51] heh [06:51] there was a new release [06:52] and it went all the way from edge to stable with a single push [06:52] because … [06:52] reasons [06:53] mborzecki: where do we pull from? beta/edge? stable? [06:53] well slack works, python0 works, so it's ubuntu-image that's borked [06:53] mvo: same version in every channel [06:53] mborzecki: yeah, I think I have the privs to "fix" that [06:53] mborzecki: I just need to know where we pull from [06:53] mvo: edge [06:53] mborzecki: excellent [06:54] mborzecki: fixed [06:54] mvo: refreshing [06:54] mborzecki: and next we need to have a word with the uploader of the snap :) [06:55] lukasz? :) [06:55] * mvo won't name names [06:56] mvo: https://paste.ubuntu.com/p/pXgtFBFVHd/ better, at least no segfault, no clue if it's intended to be used outside of ubuntu though ;) [06:56] mborzecki: heh [06:56] mborzecki: why on earth would it need dpkg? [06:56] mborzecki: well, I guess I should look at the code to answer that [06:57] mvo: well, why it's not bundled in the snap? :) [06:57] mborzecki: looks like its using it to detect its own arch [06:57] mborzecki: another great question [06:59] wow, snapcraft travis jobs are really ~7h long? [06:59] mborzecki: to be fair it looks like the snapcraft.ymal has not changed [07:00] mborzecki: so maybe a snapcraft change broke u-i [07:00] mborzecki: it was failing inside travis too, right? not just on arch? [07:00] mborzecki: I think thats correct, snapcraft runs a ton of integration tests that build stuff (at least AIUI) [07:00] mvo: yes, my guess is some library pulled in through LD_LIBRARY_PATH got updated/changed [07:01] mborzecki: ok [07:01] mvo: https://paste.ubuntu.com/p/vFfwvBsHH7/ [07:02] mborzecki: nice! [07:02] mborzecki: I also like your hostname in the pastebin :) [07:02] mvo: whatever it is it's inside /snap/ubuntu-image/100/lib/lib-arch [07:03] mborzecki: there is probably a lot inside there === pstolowski|afk is now known as pstolowski [07:04] mornings! [07:04] mvo: i see mostly glibc, readline [07:04] pstolowski: hey [07:06] mvo: well, maybe libc shouldn't be there after all https://paste.ubuntu.com/p/KhT6SbWYj4/ it's not there in rev 98 which works [07:07] pstolowski: hey [07:07] pstolowski: can you do a quick test for me please [07:08] zyga: hello-fedora still works [07:08] mborzecki: thank you! [07:09] mborzecki: worth a shoot [07:10] zyga: I have fedora29 r9 and hello-fedora r5 but still get the error launching it but I don't have the latest snapd maybe [07:10] zyga: same missing file error [07:10] mvo: you should not need the lasted snapd [07:10] drat :/ [07:10] ok, thank you [07:10] (perhaps you do, because the fix in dirs.go) [07:10] the hack I did only works on simpler implementation in snap-confine [07:10] that's okay [07:10] thank you for trying [07:11] mvo: I suspect swapping ID=... lines in $SNAP/usr/lib/os-release in fedora29 would fix it [07:11] mvo: if you want to unpack the squashfs and "snap try" it to check [07:11] but don't worry, it's better to fix this through mater [07:13] zyga: once your snapd PR lands it will work, no? [07:13] mvo: I think so, yes [07:13] zyga: if so, lets just make sure it does land [07:13] mvo: it's passing tests [07:13] (except core prepare is broken) [07:13] yeah [07:17] mborzecki: hey, do you have any PR you want reviewed? [07:17] mborzecki: i mean, you have a few, but what's the 1st in the queue? [07:17] pstolowski: https://github.com/snapcore/snapd/pull/5614 if you could [07:18] sure [07:18] pstolowski: thanks [07:22] mvo, mborzecki: should we disable core if we cannot fix ubuntu-image for a while? [07:22] zyga: it is "fixed" [07:22] zyga: it should be possible now [07:23] Son_Goku: I'm happy with the slides, I think [07:24] zyga: do you have the slide deck available anywhere? [07:24] https://docs.google.com/presentation/d/1Vf3wfC8O7D4_f_zyPBvvy6U6YBBRQd_3ncR6sWszTQM/edit?usp=sharing [07:25] it's mostly a "talking" presentation so we have a few slides but most of the content will be verbal [07:28] suggestions welcome! [07:29] zyga: nice [07:35] * sil2100 ordere [07:35] * sil2100 ordered a raspi3 [07:35] (cat's tail pressed enter too soon) [07:37] sil2100: yay === chihchun_afk is now known as chihchun [07:42] Is there any way to rename a snap's internal name without deleting and re-adding it? [07:44] Son_Goku: snap install copr # [07:44] # exercise for the reader [07:44] :D [07:44] mborzecki: https://github.com/CanonicalLtd/ubuntu-image/pull/157 should fix the issue of running ubuntu-image on arch [07:45] grrr [07:45] mvo: ta [07:46] mvo: oh! Yeah, none of us really thought about u-i on a non-ubuntu system ;) [07:46] sil2100: yeah, I haven't either, just mborzecki did [07:46] :) [07:46] * mvo hugs mborzecki [07:47] wait. There are non-ubuntu systems?!? [07:47] this changes everything [07:47] * Chipaca tries "snap changes everything" just to make sure [07:47] Chipaca: apparently! [07:47] * Chipaca grins like an idiot [07:54] mvo: yup, i can run ubuntu-image --help now :) [07:55] btw. took a bit of trial & error to track down all dependencies with a clean venv [07:55] mborzecki: *nod* [07:55] mborzecki: thanks for confirming [07:59] Hi all. [08:07] I'm just setting up a new company laptop with Fedora 28, and I could not run "sudo lxd init". I just came back with "command not found". However, running it without the "sudo" worked fine. [08:08] Gargoyle: sudo's path is probably different to your user's path [08:08] Am I likely to run into issues further down the line - if I've done something wrong early on, I'd prefer to catch it now than in a few days time when I have everything setup on the system. [08:11] Chipaca: I noticed that inside cmd/snap ; go test will fail for me. it looks like it will print the new (nice) green checkmarks but the tests do not expect those [08:11] Chipaca: is that just me? [08:11] Chipaca: when i run "go test | more" its fine again [08:11] mvo: let me see... [08:12] mvo: how do you run it, exactly? [08:13] Chipaca: I "cd cmd/snap ; go test" [08:13] Chipaca: inside a mate terminal [08:14] mvo: huh === chihchun is now known as chihchun_afk [08:14] mvo: and what about 'go test .'? === chihchun_afk is now known as chihchun [08:19] Chipaca: that is fine [08:19] Chipaca: interessting [08:19] mvo: here it fails with a dbus error [08:19] Chipaca: wuut? what does it try to talk to? [08:19] ... value *errors.errorString = &errors.errorString{s:"cannot obtain bus name 'io.snapcraft.Launcher'"} ("cannot obtain bus name 'io.snapcraft.Launcher'") [08:20] mvo: test runner is weird [08:20] mvo: results change depending on whether I set -v or not [08:20] might be something inside our test not properly mocked [08:21] mvo: 'go test -v .' -> colour errors [08:21] mvo: 'go test .' -> just the dbus error (also present with -v) [08:21] Chipaca: go test -v gives me also the \x1b bits inside the test output [08:23] mvo: so, the colours in the output mean that Stdout is a terminal [08:23] Chipaca: yeah, I wonder why. this is normal bionic [08:24] mvo: this here is "normal" xenial [08:24] mvo: I'll dig into it and see what i learn [08:24] Chipaca: aha! can you please try with "go1.10" from the snap? I will try with go 1.6 [08:24] mvo: ah, about the same with a snapped 1.10 === chihchun is now known as chihchun_afk [08:27] Chipaca: yeah, no difference for me either [08:28] sigh [08:28] mvo: the problem probably arises because colour support checks whether stdout is a terminal just once [08:29] mvo: so it needs mocking in tests [08:29] mvo: I don't know why it only needs mocking in some cases and not in others [08:31] mvo: doing this now fwiw [08:34] Chipaca: ta [08:35] mvo: could i get a review of #5617? [08:36] Chipaca: yes [08:46] mvo: when you run the tests, do you have a "DBUS_SESSION_BUS_ADDRESS" env var? [08:47] Chipaca: I do have that set [08:47] mvo: here I need to explicitly unset it for tests to pass when running from the directory (but not otherwise) [08:48] mvo: the funny thing is testutil/dbustest.go saves that env var but doesn't unset it nor set it to anything [08:48] mvo: so i'm not sure what's supposed to be doing it [08:48] Chipaca: woah [08:49] mvo: ikr [08:49] in any case, pr coming with these fixes [08:51] Chipaca: \o/ [08:54] pstolowski: hey, got a question about udev, udev monitor will start before dumping current device db right? [08:55] yes, this will be visible in the PR i'm working on which integrates monitor and udevadm parser [08:56] ah ok [08:56] mborzecki: i'm starting the monitor and queue monitor events until db dump finishes, then i flush accumulated events [08:57] pstolowski: then dedup is based on devpath/devname? [08:58] mvo: https://github.com/snapcore/snapd/pull/5627 addresses the 'go test' weirdness [09:01] mborzecki: not sure yet, probably, i haven't tought much about that aspect yet [09:28] boo [09:28] Failed project prepare: 4 [09:28] boooh [09:34] Chipaca: hmm something isn't right https://paste.ubuntu.com/p/JmVDynrPCF/ [09:36] mborzecki: mhmm [09:45] mborzecki: ah [09:45] mborzecki: i think i know what's happening [09:45] Chipaca: takes a while for socket to appear [09:45] mborzecki: exactly :-) [09:45] we don't wait for it to start [09:46] Chipaca: added a loop with 20s wait, but still no socket, maybe it's started wrong? http://paste.ubuntu.com/p/VnwfFwjn4s/ [09:46] mborzecki: are you fixing it, or should i? [09:47] Chipaca: go ahead :P [09:48] k [09:49] omg silly me [09:51] Chipaca: http://paste.ubuntu.com/p/mwvRRjjqzf/ if you want to use it [09:58] mborzecki: want to try https://pastebin.ubuntu.com/p/mX8x6BZDps/ ? [09:58] nice [09:59] mborzecki: interestingly the printed address looks like unix:path=/tmp/check-6227058902689785204/0/user_bus_socket,guid=c22feadfc799529b07be91f75b6d603a [10:00] Chipaca: works all right here [10:10] Chipaca: don't know if you got that, your patch works fine [10:10] mborzecki: i hadn't, thank you [10:10] i'll push it now [10:11] mborzecki: did you get the bit about how the printed address has more stuff than just user_bus_socket? [10:12] yeah, saw that here too, apparently it's not critical as i was doing setenv without that and it worked too [10:21] mborzecki: I could've also done --print-pid and waited for that [10:21] eh, it works this way [10:21] w/e [10:47] mvo, did the pi3 gadget ever get updated in stable to include all the gpio interfaces (it is in edge since 1.5y, but i dont know if/when you pushed pi3 into stable) [10:48] (i'D have expected it to be updated along with the push of pi2-kernel to stable) [10:49] ogra: it has not bee updated [10:49] damn [10:49] ogra: the kernel is done by the kernel team they can't push the gadgets [10:50] ogra: gadgets are foundations territory nowdays [10:50] it has various firmware fixes for thermal and power management and the stable one seems to miss all gadget based interfaces [10:50] ogra: yeah, I think it should go out, we just need a) QA b) somoeone driving this :/ [10:51] ogra: fwiw, the LP page is owned by foundations and steve has the required privs to push the snaps [10:51] i honestly have not run stable gadgets since the above stuff landed ... so for a) i can clearly give you a thumbs up :) [10:52] and *all* interfaces missing is clearly a downer [10:52] my network is having a fun day [10:53] but on the other hand so is travis [10:53] Chipaca: and so is LP - arm builds are very slow (the builders look a bit overworked) [10:56] eight hour workday for workers! rabble rabble rabble [10:56] drat, i meant builders [11:37] hello :) [11:37] how are things? [11:40] is travis working now, it was pretty slow when I tried to use it yesterday [11:47] zyga: wrt travis, everything is terrible, slow, horrible, raining on the ice cream [11:48] zyga: Son_Goku: how's your flocking? === pstolowski is now known as pstolowski|lunch [11:58] Chipaca: we're done with our presentation, it went very good [11:58] we had lots of questions and interaction with the audience [11:58] zyga: people weren't asleep and hung over? [11:58] and we have a working fedora29 base now :) [11:58] no, today is the first day when it's not 999999C outside [11:59] I still want to catch some infrastructure people to discuss the hand off [11:59] and the fedora project leader to get an ack of the use of the fedora log [11:59] logo [12:01] Chipaca: and people are surprisingly extremely sober [12:01] drink responsibly, said the spiritual ghost of jono [12:07] * mvo weeps about the fact that he still has no arm PPA build for snapd 2.35~pre1 [12:08] need another coffee [12:09] mvo: i've updated https://github.com/snapcore/snapd/pull/5584 with your patch, thanks! [12:09] mborzecki: \o/ happy that you liked it [12:10] mvo: yeah, i feel like i should rewrite that snap name validation too [12:11] mvo: also played around trying to get the bits of validation code shared between update-ns and libsnap-confine-private, so far no other idea than a separate file and a symlink to update-ns, the simplicity of go build is not making it too easy [12:16] mborzecki: I think rewrite of the snap name validation is not a good idea [12:16] mborzecki: but yeah, sharing is probably hard, but I have not put much thought into it yet, its just mildly annoying [12:19] mvo, hey [12:22] cachio: hey he [12:22] cachio: how are you? [12:22] mvo, fine [12:23] you? [12:23] cachio: yeah, doing well. need more tea though [12:23] :) [12:23] hehe, I have 2 issues to fix on core 18 [12:23] cachio: tell me more please [12:23] mvo, https://paste.ubuntu.com/p/Z7m38nK6VY/ [12:24] cachio: aha, nice find. we need to kill this one I think [12:24] cachio: like remove the service entirely [12:25] mvo, yes, makes sense [12:25] cachio: I need to finish a PR first but once that is done I can look into it or maybe sil2100 has some spare cycles for ensuring update-motd.service is removed from core18 [12:25] mvo, sure [12:39] I can! [12:40] wow a thunderstorm [12:41] mborzecki: we had this yesterday - it was wild [12:43] hmm snap-update-ns segfaulting now :P [12:45] i suppose by internet will be choppy a bit today [12:48] mborzecki, while yoyu duck and cover, just think about the fact that the air is breathable afterwards ;) [12:48] (it definitely helped a lot here) === pstolowski|lunch is now known as pstolowski [13:23] mvo: ok, responded to 5621 (twice! :) [13:26] jdstrand: thank you! [13:26] * mvo reads [13:28] mvo: let me know if what I said doesn't make sense [13:30] mvo: pre-patch version works [13:31] mborzecki: ok, let me look at the diff again, I wonder what I broke [13:32] mvo: well the code looks correct, maybe i broke sth when doing little tweaks [13:32] mborzecki: how can I reproduce? just build and copy in place and run a snap? [13:33] mvo: sec, let me see if the same happens with non instance keyed snaps [13:34] mvo: snaps without instance key work [13:36] mborzecki: is "go test cmd/snap-update-ns " enough to trigger the crash? [13:37] mvo: nope, the tests are passing [13:37] mvo: heh, and even the hello-world_foo is used in the test suite :) [13:37] mborzecki: so its crashing only when used for real(tm) ? [13:38] mvo: yes [13:46] mborzecki: fyi, https://github.com/snapcore/snapd/pull/5584#pullrequestreview-145243262 [13:47] jdstrand: thanks! [13:47] mborzecki: is this the pr that you and mvo are discussing now? [13:47] mborzecki: I played around a bit but did not managed to reproduce [13:47] jdstrand: yes [13:48] hmm, I verified the new 'i' handling. let me look again [13:48] mvo: https://paste.ubuntu.com/p/ZGS8QwfWXt/ [13:49] mborzecki: there is an off by one, no? [13:49] for (i = 0; instance_key[i] != '\0'; i++) { [13:49] ... [13:49] else if (i > 10) { [13:50] 0123456789\0: i will be 11 here [13:50] no, that's right [13:51] jdstrand: the s is +1 because of this [13:54] mborzecki: if you are still inside gdb, does "print instance_key[i]" yield anything? [13:54] mborzecki: the gdb output looks all legit or am I missing something? [13:55] looking for reviews on #5617 plz (not a trivial, unless you look at each commit individually) [13:55] mvo: replaced islower/isdigit with own code and it works (?!?) [13:55] mborzecki: heh [13:55] mborzecki: optimization this smells like (in best yoda voice) [13:55] mborzecki: can you build with -O0 ? is this arch/ubuntu? [13:56] mvo: i'm building with -O0 [13:56] :( [13:57] mvo: heh :P [13:57] mborzecki: I didn't mean on the buffer, I meant on the length check, but it is fine [13:58] one thing about strsep() is that it is going to modify the string [13:58] jdstrand: yeah, there's a copy made in validate_instance_name [13:59] right, I recall verifying that was ok [13:59] mborzecki: what is the failure? [14:00] mborzecki: is that on arch or ubuntu? what go version and gcc --version is in use? [14:00] actally, shouldn't char s[52] = {0,}; be char s[53] = {0,};? [14:00] 40 char snap_name + 10 char instance_key + 1 NULL + 1 extra to detect overflows [14:01] doesn't that not account for the valid '_'? [14:01] jdstrand: #0 0x000000000055406e in instance_key_validate (instance_key=0x7ffe6a68b55c "foo") at bootstrap.c:286 [14:01] 286 if (islower((int)instance_key[i]) || isdigit((int)instance_key[i])) { [14:01] segfaulting in this line, instance_key is "foo" [14:01] jdstrand: oh, I think you are correct! [14:01] some40charname_instance\0 [14:01] mborzecki: hm, hm, that cast [14:02] mvo: added it just now to test things, but it's segfaulting without that too [14:02] mborzecki: hm, no, that should be fine [14:02] mvo: jdstrand: instance_key address is well within the bounds of validate_instance_name:s [14:03] mborzecki: does it make a difference if you only have "islower" or "isdigit" ? [14:04] mborzecki: of replacing it with if(instance_key[i] != '\0') [14:04] mvo, how are we looking on getting snapd 2.35 out the door? [14:05] Son_Goku: its in beta now [14:05] Son_Goku: beta does not yet include the fedora base fix but the next one will be [14:05] Son_Goku: next beta will be early next week [14:06] mvo, cool [14:06] zyga wants me to update Fedora and my beta CentOS packages to 2.35, which is why I was asking [14:06] Son_Goku: +1 [14:07] the talk went really well (aside from the questions about the store), and there was definitely interest in Fedora-based snaps [14:08] well, even the questions about the store weren't that bad, but the talk went over so well that we went ~15 minutes over time [14:09] mainly for Q&A [14:10] mvo: omg, i'm stupid after all, it's working all right [14:10] mvo: i obviously did not built it as a static binary [14:10] mborzecki: puhhh, ok [14:10] mborzecki: there is an off-by-one with the strncpy() that will result in an unterminated string. you need sizeof(s) + 1 [14:11] * mvo finds it amusing that "close()" is defined in unistd.h but open in sys/types.h [14:12] mvo: heh funny that it failed, thought that gcc has builtin primitives for isblahblah by now [14:12] mborzecki: it is interesting that because you use a for loop instead of strlen() for the length, it didn't end up being a problen, [14:12] mborzecki: I think there is some magic going on with these, iirc they get replaced at init time with optimized versions or something [14:13] jdstrand: thanks for double checking [14:13] mvo: and here i thought that the world is coming down :) [14:14] mborzecki: same here, I was really confused [14:14] mborzecki: thanks for getting to the bottom of it [14:15] mborzecki: the '+ 1 extra to detect overflows' actually accounts for the '_'. Perhaps it would be better to rephrase that comment to be: '// 40 char snap_name + '_' + 10 char instance_key + 1 NULL [14:17]