[06:02] morning [06:04] mborzecki: hi! [06:04] mardy: heya [06:12] morning [06:15] pstolowski: hi! [06:17] pstolowski: and hey [06:23] mborzecki: do you have a moment for 2nd review of https://github.com/snapcore/snapd/pull/10539 ? [06:23] pstolowski: will do, i have it open already [06:23] ty [07:12] https://github.com/snapcore/snapd/pull/10542 is simple and needs a 2nd review [07:29] mborzecki: added a +1, but mine is just a formal review [07:32] good morning :) [07:46] zyga: hey [07:50] zyga: hi! [07:50] hey mardy :) [08:27] uh... I'm getting the unit tests to hang in my branch stuck for 10 minutes in TestHappyOrthogonalRefreshAutoAliases. Any ideas of what could be wrong? https://paste.ubuntu.com/p/VQrNm8GjJJ/ [08:33] mardy: hard to say, when this happens to me I usually add a loop to print all tasks (kind + status) right before assert around settle [08:35] mardy usually deadlock [08:35] or state waiting forever [08:35] ah, but this doesn't return from settle [08:35] right [08:35] so yeah, something is probably holding the lock so Wait() deadlocks [08:39] pstolowski: mardy hm i just directly add a couple of printfs in taskrunner before the handler runs [08:49] ok, let's go back to a more basic question :-) How do I run a single test? I tried `go test -v -run TestHappyOrthogonalRefreshAutoAliases ./overlord/` but it doesn't find any tests to run [08:49] mardy: go test -check.f [08:50] pstolowski: aahhhh, thanks :-) [08:50] it took me a while to query check command line options [08:50] mardy note that check and testing are separate beasts [08:51] mardy testing sees one test [08:51] check has internal structure [08:51] it's a bit annoying at times [08:51] I could be wrong but my attempts to use testing specific features didn't work [08:53] mines either: $ go test -v -check.f TestHappyOrthogonalRefreshAutoAliases ./overlord/ [08:53] can't load package: package github.com/snapcore/snapd: no Go files in /home/mardy/go/src/github.com/snapcore/snapd [08:55] grrr, power outages today [08:58] pstolowski: you probably missed my last question then: if I add the -check.f parameter, then it doesn't find the packages to test anymore: [08:58] $ go test -v -check.f TestHappyOrthogonalRefreshAutoAliases ./overlord/ [08:58] can't load package: package github.com/snapcore/snapd: no Go files in /home/mardy/go/src/github.com/snapcore/snapd [08:58] mardy: run it from the actual subdirecotry [08:58] pstolowski oh? [08:58] pstolowski more storms? [08:58] mardy yeah [08:59] pstolowski: wow, so easy, yet so hidden :-) [08:59] mardy it looks like a bug in check [08:59] I ran into that lately a lot [08:59] zyga-mbp: not storms right now, might be just some maintenance work [08:59] *no storms [09:00] zyga-mbp: yes, I guess it can't be a design decision [09:11] pstolowski_: mmm... actually, the fault is not only in my branch: that test times out even in the master branch, in my machine [09:12] mardy which directory? overlord? [09:12] mardy: checking [09:12] zyga-mbp: yep [09:12] mardy: passes here [09:12] I bet missing dependency [09:12] zyga-mbp: I run `go test -check.f HappyOrthogonalRefreshAutoAliases -v .` [09:12] wot [09:12] it relies on squashfstools [09:13] trying [09:13] let me check... [09:13] wait [09:13] I mean, give me a sec [09:14] I need older go [09:14] I use 1.17 [09:14] I do have squashfs-tools installed, do I need squashfs-tools-ng? [09:15] apt-get build-dep . [09:15] this will give you the right list [09:15] testing overlord with go 1.10 [09:15] btw, what does mardy and pstolowski_ use for go version? [09:15] nope, seems like I have all the needed deps [09:15] ... [09:15] 1.13.8 [09:15] (it's sure taking a long time) [09:16] passed [09:16] on 1.10 [09:16] go version go1.13.8 linux/amd64 [09:16] yes it's slow for all tests in overlord [09:17] trying 1.13 [09:17] mardy what sort of machine do you have? I'm doing this on a 8 core laptop [09:17] maybe it's just slow [09:18] 32 seconds on 1st run on go 1.13 [09:18] just HappyOrthogonalRefreshAutoAliases is relatively fast [09:23] zyga-mbp: it's an intel i5 from... uh... 2011 I think :-) I upgraded it to 8GB of RAM a couple of years ago [09:23] mardy do you have a hdd there? [09:23] could be that IO is just slow [09:25] zyga-mbp: mmm... no, it's an SSD, but in the background I'm creating a copy of an external 1TB drive into another 1TB drive; I wonder if this has an impact... [09:25] ops on my root partition seem to be fast, though [09:27] mardy no idea though [09:27] are you swapping? [09:27] 8GB is a bit thin [09:30] these tests have 45s timeout for Settle though [09:30] should be more than enough ;) [09:31] mardy: ah, i missed what you said about 1TB copy op in the background... yeah, maybe [09:31] let's see how CI goes then :-) [13:40] pstolowski, ijohnson[m]: so, the issue with "snapctl start" happens because, unless --enable is given, I build a list of the snap's disabled services and I pass that to wrappers.StartServices() [13:40] I've verified that if I set this to nil, then everything works [13:40] when building this list I do exclude those snaps explicitly mentioned in the command line, but this does not seem to be enough [13:41] (indeed, the explicitly mentioned services are not part of the disabledServices list) [13:42] but I guess that some of these disabled services are a dependency for the explicitly requested one? [13:43] we do not track service dependencies, AFAIK [13:45] mardy: I don't think dependencies have anything to do with it [13:45] mardy: pstolowski I wrote a simple reproducer test expanding our current existing spread test [13:47] ijohnson[m]: can you push it somewhere? [13:48] ijohnson[m]: I guess that some of those units which I'm not starting are sockets needed by the requested snap [13:48] mardy: sorry I thought I linked it here but I forgot to paste it https://github.com/snapcore/snapd/pull/10548 [13:49] ijohnson[m]: ah, so existing test didn't pass --enable, that's why it was happy [13:49] yes [13:54] pstolowski: it's actually the opposite: the test *did* pass --enable, that's why it was happy :-) [13:55] mardy: yes you're right [13:58] uh sorry my test modification as proposed isn't working, let me fix it [14:00] mardy: anyway, the if !enable {... case is most likely the culprit but it's not clear to me how, needs some printf debugging [14:07] ouch [14:08] explicit service is "snap.edgexfoundry.postgres.service", but the string being compared to it is "edgexfoundry.postgres" [14:08] I think I saw some patch from Samuele addressing snap service names [14:11] mardy: pstolowski ok, the test if fixed now, it fails as expected :-) [14:11] ijohnson[m]: thanks a lot for it and for finding the regression! [14:35] ijohnson[m], pstolowski: this works for the edgexfoundry snap, now I'll try to pull the spread test and see how it goes with that: https://github.com/snapcore/snapd/pull/10549 [14:41] mardy: we didn't have a unit test for !enable or was it using incorrect input names? [14:44] pstolowski: don't remember, but maybe it was receiving the proper names, being that they are mocked [14:58] ijohnson[m]: yep, your test passes with my changes [14:59] mardy: \o/ nice thanks for looking into this so quickly [15:05] awesome [16:14] * cachio lunch [20:28] * cachio afk