[06:32] morning [06:41] hI! [06:55] mardy: heya, i see you pushed some tests to raw-input, let me look at those [06:58] mborzecki: I mostly copied them from those for the joystic interface, but please don't tell anyone ;-) [06:59] that's fair, there are some repeated patterns in the tests [07:05] morning [07:08] pstolowski: hey [07:10] mardy: btw. there's a spread-shellcheck tool, which is a tiny wrapper around shellcheck that takes a spread.yaml|task.yaml file, extracts the bits that execute under shell and feeds them to shellcheck [07:37] mardy: https://github.com/snapcore/snapd/pull/10251#issuecomment-840380873 [07:37] PR #10251: interfaces/builtin: introduce raw-input interface [07:53] mborzecki: thanks, will fix === ackk is now known as ack [08:49] mborzecki: it's still failing, but this time I don't think that the failure is due to my changes: https://github.com/snapcore/snapd/pull/10251/checks?check_run_id=2573757599 [08:49] PR #10251: interfaces/builtin: introduce raw-input interface [08:49] mborzecki: is that kind of failure familiar to you? [08:53] looking [08:54] mardy: ah yes, the mystery gpg problem, we've been hitting it randomly, but so far the source of the problem has not been identified, we suspect that it had something to do with running out of entropy [08:55] mardy: then pedronis suspected there may be something in the go stdlib implementation of gpg [09:11] mardy: all tests passing is unfortunately very rare :/ due to the number of tests and systems (some of which constantly move), and external factors (store or gce hiccups etc) [09:25] meh cherry-picking the whole kernel command line branches into 2.50 [09:25] seems like we missed it, or decided to push it to 2.51 (which i don't recall, but that wouldn't be the first time my memory is bad) [09:34] pstolowski: hi! The Status() method in systemd/systemd.go, is it the one you said I should avoid using? [09:36] pstolowski: the getUnitStatus() is private; I'll make it public as QueryUnitStatus() [09:36] mardy: no, feel free to use it if it's usable (I was talking about getUnitStatus but Status() uses it) [09:38] ah, ok [09:41] pstolowski: I will apply the same logic to both "restart" and "reload" operations, right? Or should only "restart" be affected by my changes? [09:46] mardy: i think both should have same logic [10:10] PR snapd#10265 opened: many: backport kernel command line for 2.50 <⛔ Blocked> [10:56] #10182 and #10187 for refresh control need 2nd reviews [10:56] Bug #10182: Can not logout of gnome when xcompmgr is running [10:56] PR #10182: o/snapstate: autorefresh phase1 for refresh-control [10:56] Bug #10187: debconf fails to install [10:56] PR #10187: o/hookstate, o/snapstate: print revision, version, channel with snapctl --pending [11:28] pstolowski: is there a snap command to disable a service, or should I use systemctl (the context is the spread tests)? [11:29] mardy: snap stop [11:30] "snap stop --disable", even [11:30] yep [11:31] it doesn't maintain any extra state outside of systemd though, so using systemctl on a snap service shouldn't break anything [11:41] thanks! But I don't want to stop the service, so I guess I'll use systemctl [11:55] PR snapd#10266 opened: wrappers/services.go: do not restart disabled or inactive services [12:31] The unit tests are failing in my branch: https://github.com/snapcore/snapd/pull/10266/checks?check_run_id=2575132725 [12:31] PR #10266: wrappers/services.go: do not restart disabled or inactive services [12:31] I've added some debug info, and I see that the systemctl command being run is: show --property=Id,ActiveState,UnitFileState,Type snap.test-snap.foo.service snap.test-snap.bar.service snap.test-snap.abc.service [12:31] the output is: [65 99 116 105 118 101 83 116 97 116 101 61 105 110 97 99 116 105 118 101 10] [12:32] and the error generated by snapd is: cannot get unit "" status: missing Id, UnitFileState in ‘systemctl show’ output [12:33] mardy: have you mocked snapctl? [12:33] mardy: sorry, systemctl [12:33] pstolowski: no, but I didn't touch these tests [12:33] so I don't get why they are failing now [12:35] mardy: you changed RestartServices impl to get statuses, you now need to update all existing tests that use restart to mock systemctl accordingly [12:36] mborzecki, hi [12:36] mborzecki, I see https://paste.ubuntu.com/p/VyRynqBcfW/ [12:36] cachio: let me see [12:36] when running tests on fedora 34 [12:36] mardy: because the existing mock doesn't expect extra systemctl callsą [12:36] it is getting stuck on reset [12:37] mborzecki, this is an example https://paste.ubuntu.com/p/s8nGk8vKnr/ [12:44] mborzecki, I have a debug session open [12:44] if you want to take a look [12:44] cachio: yeah, send me the ip and password [13:20] PR snapd#10267 opened: snap-bootstrap: start drafting run-cloudimg mode [13:27] cachio: hm no idea yet [13:27] cachio: is it reproducible after this test? [13:27] if you run few tests it is reproducible 100% [13:28] mborzecki, this is the log for that machine https://paste.ubuntu.com/p/nMgJPm8JJG/ [13:29] hmm w8, so that's diferent [13:35] cachio: hm not sure what's happening, so snapd is started and is active, but that nc command sometimes get stuck (i could reproduce it a couple of times), it gets the response from snapd but then hangs [13:36] mborzecki, weird [13:36] nc is hanging :) [13:37] cachio: fwiw, this is the backtrace: https://paste.ubuntu.com/p/Bz4ssw8cJ2/ [13:38] it's waiting on poll, i suspect the connection shoudl be closed next, but isn't [13:39] hm maybe it's something systemd related ? or new go idk [13:40] perhaps we can use [13:40] -w timeout Timeout for connects and final net reads [13:41] as a workaround [13:42] cachio: can't reproduce it anymore [13:42] heh [13:42] looks like a race [13:45] cachio: this is enough to trigger it sometimes `systemctl stop snapd snapd.socket;systemctl start snapd.socket; sleep 0.1; printf 'GET / HTTP/1.0\r\n\r\n' | nc -U /run/snapd.socket` [13:45] for some systems we use -q 1 [13:46] and i can reproduce it locally too [13:47] cachio: yeah, that seems to work, can you try to push a patch? [13:47] works even locally [13:48] cachio: the failure with selinux denials, do you know which test was it? [13:48] I thinks yes [13:49] mborzecki, I mean, I'll create a patch [13:50] mborzecki, denials are for google:fedora-34-64 .../tests/regression/lp-1852361 [13:50] hm so layouts === alan_g_ is now known as alan_g [14:00] cachio: hm i think i'm confused, we do not fail a test when there's selinux denials (or just fail a few chosen tests) [14:13] mborzecki, don't know [14:14] cachio: do you have a full log of the failure? [14:14] cachio: we do list it as part of the debug section, but the failure was something else afaict [14:16] I have this log [14:16] https://paste.ubuntu.com/p/K6rYDrVDym/ [14:16] mborzecki, this is the only one [14:17] mborzecki, about nc, using the -w param it is working very well [14:17] cachio: this one failed on the nc problem too [14:17] cachio: i think we want -q rather than -w [14:18] mborzecki, -q is not available on fedora [14:21] mborzecki, I just pushed the change for nc [14:21] let's see the errors now [14:28] i tried to reproduce https://forum.snapcraft.io/t/snap-refresh-broken-when-output-is-piped/24385/2 but couldn't [14:30] pstolowski: fwiw, i can't reproduce it either [14:31] mborzecki: nice... maybe was a red herring, temporary store hiccup [14:31] ah right, we saw something like this didn't we? [14:31] sure === RzR is now known as rZr [15:52] * cachio_ lunch [16:23] PR snapcraft#3521 opened: build providers: set hostname for lxd [17:13] PR snapcraft#3522 opened: python v2 plugin: update pip properly === dariball_ is now known as dariball