| === chihchun_afk is now known as chihchun | ||
| zyga | o/ | 04:40 |
|---|---|---|
| mborzecki | morning | 05:10 |
| zyga | mborzecki: hey | 05:13 |
| zyga | https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954 | 05:13 |
| mborzecki | yup reading | 05:13 |
| mborzecki | zyga: any clue if mvo got access to a vm where the refresh-mode issue was reproducible? | 05:16 |
| zyga | no | 05:16 |
| zyga | let's make a spread test that has similar characteristics | 05:16 |
| mborzecki | zyga: do we know what disto tha was? | 05:16 |
| zyga | and strace the hell out of it | 05:16 |
| zyga | not really | 05:17 |
| zyga | note that we have not reproduced it yet | 05:17 |
| zyga | but I will let mvo discuss tihs | 05:17 |
| zyga | he knows the most | 05:17 |
| mborzecki | hm that memory usage, we could play with GOGC, but there's another possibility that we're just keeping that much stuff in memory | 05:21 |
| mborzecki | (i'm taking about RES, VIRT is high but it should not be a problem) | 05:22 |
| zyga | mborzecki: yes, RES is key, though VIRT is weirdly huge | 05:47 |
| zyga | but maybe that's the nature of golang gc | 05:47 |
| zyga | ok, kids off to school | 05:47 |
| zyga | and I can have my coffee and focus | 05:47 |
| mborzecki | gdm is just so useless, it stats a whole gnome session, does nothing else than shows a login screen and has a 50% chance of locking up the system when switching back to it after logout | 06:32 |
| mborzecki | at least autostart works as expected with 2.32.4 | 06:33 |
| zyga | Heh, the modern desktop stack | 06:33 |
| mborzecki | btw. clicking on quit label in tray menu of discord: https://paste.ubuntu.com/p/CtG3Kx7Kxt/ | 06:34 |
| === katnip- is now known as Guest67740 | ||
| zyga | Well | 06:39 |
| zyga | On my system gnome shell logs errors every second | 06:39 |
| zyga | Finalization issue with some object | 06:40 |
| zyga | I frankly miss unity quality | 06:40 |
| zyga | Later on unity was way more solid | 06:40 |
| === Guest67740 is now known as katnip | ||
| mborzecki | ok, bumped arch package to 2.32.4 | 06:51 |
| mvo | good morning | 06:52 |
| mborzecki | mvo: morning! | 06:52 |
| zyga | hey mvo | 06:53 |
| mvo | hey mborzecki and zyga ! how is life this morning? | 06:55 |
| zyga | great, it's a bit chilly in the morning though | 06:55 |
| zyga | I'm looking into the memory leak | 06:55 |
| zyga | but if I get stuck or it goes nowhere I will look at the mount issue | 06:56 |
| pedronis | hello | 06:56 |
| zyga | hey good morning | 06:57 |
| pedronis | so I discovered that init is 2M and snapd nowadays 21M , just the executable (of course systemd has other daemons) | 06:58 |
| zyga | I really wonder what is inside golang executables | 06:58 |
| zyga | small instance of google Borg? | 06:58 |
| pedronis | well, as I said, systemd has many daemons | 06:58 |
| pedronis | so it's not a fair comparison | 06:58 |
| pedronis | but it doesn't put in a good spot | 06:59 |
| pedronis | we have not to run at all, not to use memory | 06:59 |
| mborzecki | that ~21M would mostly count to virt though | 07:00 |
| pedronis | mborzecki: looking at smaps it doesn't seem so | 07:00 |
| mborzecki | but it still needs to be loaded into memory and so on | 07:00 |
| pedronis | anyway on a constrained system probably even running and stopping is bad | 07:01 |
| pedronis | mvo: let me know if we should have a HO in 1h or so to talk about that issue at least and options | 07:03 |
| mvo | pedronis: yeah, sounds good a HO in the morning sounds good, I am currently baby-sitting autopkgtest but hopefully that does not take too long | 07:04 |
| pstolowski | morning | 07:06 |
| zyga | hey pawel | 07:06 |
| zyga | http://paste.ubuntu.com/p/GtVYbzfgC8/ | 07:06 |
| zyga | pstolowski: FIY https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954 | 07:06 |
| pstolowski | zyga: yes reading | 07:07 |
| zyga | with GOGC=10 http://paste.ubuntu.com/p/Gbnz675BT3/ | 07:13 |
| mborzecki | playing with GOGC, off -> 33MB, 5 -> 19MB, 50 -> 20MB, 100 (default) -> 22MB | 07:13 |
| mvo | zyga: what tool is that? | 07:17 |
| zyga | pmap | 07:17 |
| * mvo nods | 07:17 | |
| mborzecki | zyga: comparison of GOGC=1 and GOGC=100 https://paste.ubuntu.com/p/74zgkbZBWj/ | 07:19 |
| mborzecki | (disabled ASLR so that we get stable addresses) | 07:19 |
| zyga | nice | 07:19 |
| zyga | how did you disable ASLR? | 07:19 |
| mborzecki | /proc/sys/kernel/randomize_va_something | 07:20 |
| zyga | but the bottom line is that rss shrinks just a little and virt doesn't | 07:20 |
| mwhudson | you can also disble aslr for one invocation with setarch | 07:20 |
| mwhudson | setarch `uname -m` -R whatever | 07:21 |
| mborzecki | nice | 07:21 |
| mborzecki | wonder why there's 7 * 64MB and 6*8MB blocks, 64MB ones are ---p, 8MB are rw-p | 07:26 |
| mup | PR snapd#5035 closed: release: snapd 2.32.4 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5035> | 07:28 |
| mvo | good news, spread on xenial is happy again and we have some tests passing already, the other ones are retriggered | 07:29 |
| mvo | (missing build of test-snapd-account-services on s390x was one failure which is fixed now) | 07:29 |
| zyga | mborzecki: noite that the 64MB ones are empty | 07:31 |
| zyga | they take almost no memory | 07:31 |
| mborzecki | zyga: cow? | 07:32 |
| zyga | they feel like a/b gc | 07:34 |
| mborzecki | hm bottom line, we're not going to get lower than whatever is the size of snapd binary, i.e. ~16MB | 07:35 |
| mborzecki | zyga: installing core snap https://paste.ubuntu.com/p/dQDYNJz2Vf/ | 07:38 |
| mborzecki | also the binary in core built with go 1.7 right? | 07:41 |
| mborzecki | zyga: before and after installing core snap and reexec https://paste.ubuntu.com/p/xPpCQjV4j8/ | 07:41 |
| pstolowski | zyga, mvo, mborzecki would it make sense to add profiling code to snapd and land it in edge, eg something like https://flaviocopes.com/golang-profiling/ in the daemon? | 07:56 |
| mborzecki | pstolowski: there's pprof which is super simple | 07:58 |
| zyga | pstolowski: I don't have experience with that, no idea | 07:59 |
| mborzecki | i can try building it locally though | 08:00 |
| pstolowski | yeah i'm going to try local build too | 08:01 |
| zyga | man we are leaking that memory quickly | 08:11 |
| zyga | I'm in a loo where test-snapd-poicy-app-consumer:bluez is constantly discon reconnected | 08:13 |
| zyga | this also stresses udev | 08:14 |
| mvo | mborzecki: the binary in core is build with go1.6 (xenial) | 08:15 |
| pedronis | mvo: I'm around | 08:15 |
| mvo | zyga: kernel mem? | 08:15 |
| mvo | pedronis: ok, I join in 2min then | 08:15 |
| zyga | mvo: perhaps, I'm not sure yet | 08:15 |
| zyga | interestingly doing this puts lots of load on X as well | 08:17 |
| zyga | (perhaps due to udev) | 08:17 |
| zyga | to the point where session is unresponsive (not stuck but very slow) | 08:17 |
| zyga | I see constantly raising buffer_head allocations | 08:17 |
| zyga | I see several dozen udev processes at a time | 08:20 |
| zyga | the leak may be unrelated to apparmor if udevadm trigger / settle leaks something into the kernel / netlink area | 08:20 |
| mwhudson | BjornT_: hi, do you have a ppa with a snapcraft that has https://github.com/snapcore/snapcraft/pull/2058 applied by any chance? | 08:22 |
| mup | PR snapcraft#2058: python plugin: install python-distutils when run on bionic <bug> <Created by bjornt> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2058> | 08:22 |
| BjornT_ | mwhudson: no. but it's in the snap edge channel now | 08:24 |
| mwhudson | BjornT_: hm but you can't build a snap in launchpad from a snapcraft from a snap can you? | 08:25 |
| mwhudson | (that sentence is quite a tongue twister) | 08:26 |
| BjornT_ | mwhudson: right, you can't. but i'm guessing you will have problems building a bionic snap in launchpad anyway, won't you? | 08:29 |
| Chipaca | mvo: I saw you put #1616629 into 'in progress', does that mean you have a branch for it? | 08:32 |
| mup | Bug #1616629: could not unmarshal state entry "snap-type" <Snappy:In Progress> <https://launchpad.net/bugs/1616629> | 08:33 |
| mwhudson | BjornT_: nope, been doing that for months :) | 08:46 |
| mvo | Chipaca: it means "we are looking at it", pedronis is working on improving the error at least to fail way earlier | 08:58 |
| Chipaca | mvo: ah, ok | 08:58 |
| pedronis | Chipaca: one theory is that it relates to removing and reinstalling (maybe we the fs of the snap in use) and lazy unmounting | 08:59 |
| Chipaca | pedronis: was that what pindonga did yesterday? | 08:59 |
| pedronis | yes, he said he had removed the snap | 09:00 |
| pedronis | Chipaca: anyway current plan is 1) improve error, 2) possibly add belt and suspenders 3) somebody might want to play with loops of remove and install of the same thing | 09:00 |
| Chipaca | i can start on 3 right no | 09:01 |
| Chipaca | now* | 09:01 |
| pedronis | thx | 09:01 |
| pedronis | I will work now on 1) | 09:02 |
| mvo | zyga: here is something strange. this is the LowMem value after running each of the tests, the tests are in order http://paste.ubuntu.com/p/k8wvw689B9/ | 09:06 |
| mvo | zyga: the fluctuation is also strange | 09:07 |
| zyga | I suspect what is going on is that as memory pressure raises kernel is dropping more and more caches | 09:07 |
| zyga | releasing some memory in that zone | 09:08 |
| mvo | zyga: aha, yeah, that makes sense | 09:08 |
| mborzecki | pstolowski: hooked up pprof finally, https://paste.ubuntu.com/p/XXBv8qFFym/ :6060 is the regular http one, the one over /run/snapd.socket you need to wrap around with socat | 09:09 |
| mborzecki | pstolowski: something like `socat -v tcp-listen:6070,reuseaddr,fork "unix-connect:/run/snapd.socket"` should work | 09:11 |
| pedronis | mborzecki: pstolowski: we discussed with mvo some ideas about not starting at all , it seems hard to halve or /3 memory usage in one week | 09:12 |
| mborzecki | pedronis: especially as the binary is 16MB already ;) | 09:13 |
| mborzecki | pedronis: so what are the current ideas? | 09:13 |
| pedronis | mborzecki: mvo is working on that I think, but basically only play at the level of the systemd units | 09:14 |
| pstolowski | mborzecki: thanks, checking; i was pursuing something else in the meantime - run 2.32.4 snapd under gcvis but didn't find anything conclusive | 09:15 |
| Chipaca | is it still the case that a snap can't call a binary in another snap? | 09:15 |
| mvo | mborzecki: the idea is to use a generator that looks if there is a snap or a seed and if none of this is true generates a service file that is socket activated only | 09:16 |
| mvo | mborzecki: this way we do not run at all on cloud instances until first use | 09:16 |
| mvo | mborzecki: the downside is that we don't get the c-n-f data so we need to put that into an external timer | 09:16 |
| mvo | but I think its an acceptable trade-off given the time contrains | 09:17 |
| mborzecki | sounds fair | 09:18 |
| mborzecki | mvo: do you need help with that? | 09:18 |
| mvo | mborzecki: sure, I also have the sigterm issue that needs attention, if you want to add the generator that would be great. | 09:19 |
| mvo | mborzecki: we have two options: a) generator b) snapd is also socket activated and we add a "wakeup" service that has conditions on /snap/* and /var/lib/snapd/seed/* | 09:20 |
| mvo | mborzecki: and this wakeup would just run snap version to ensure the daemon runs | 09:20 |
| mvo | mborzecki: plus one idea from zyga was to use the "idle" option of systemd so that snapd starts a bit later (when it starts) when the system has settled | 09:21 |
| mvo | mborzecki: sounds sensible? happy to have a quick HO if you want | 09:21 |
| mvo | mborzecki: alternatively the SIGTERM issue is something I am willing to trade too, whatever you find more interessting :) | 09:21 |
| pedronis | to be clear: /snap/* OR /var/lib/snapd/seed/seed.yaml | 09:22 |
| pedronis | not AND | 09:22 |
| mborzecki | mvo: let's do HO | 09:22 |
| Chipaca | pedronis: /snap/*/current i guess | 09:23 |
| pedronis | something | 09:23 |
| pedronis | it's really /snap/* ignoring bin | 09:23 |
| pedronis | and also /snap is not always snap | 09:24 |
| Chipaca | the problem with doing install/remove in a loop is that i quickly remember how badly that grows :-( | 09:26 |
| Chipaca | loop #1: ~1s; loop #200: ~6s | 09:28 |
| mup | PR #200: Improve error handling in client package <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/200> | 09:28 |
| Chipaca | mup: er... thanks | 09:28 |
| mup | Chipaca: I apologize, but I'm pretty strict about only responding to known commands. | 09:28 |
| mvo | mup: #1 | 09:36 |
| mvo | *pfff* | 09:36 |
| Chipaca | mvo: istr #1 being an issue, which are now gone | 09:41 |
| * cjwatson is lost in a twisty maze | 09:44 | |
| cjwatson | Is there some way to force snapd to forget about its existing store device macaroon? | 09:44 |
| cjwatson | It must be serialised to disk somewhere to persist between snapd startups, but I can't find it | 09:44 |
| mvo | Chipaca: yes, gone, let me update the post | 09:45 |
| * zyga builds 4.17 | 09:46 | |
| zyga | well, master | 09:46 |
| pedronis | cjwatson: it's in state.json under data.auth.device | 09:46 |
| zyga | kissiel: /me hugs his computer :) | 09:46 |
| pedronis | cjwatson: session-macaroon | 09:46 |
| Chipaca | mvo: which post? | 09:47 |
| pedronis | cjwatson: /var/lib/snapd/state.json. stop and restart snapd for editing | 09:47 |
| cjwatson | Aha, thanks | 09:47 |
| mwhudson | mvo: np on go 1.6/stable, i'm just waiting for the coinstallable tracks feature :) | 09:50 |
| mwhudson | zyga: would you be interested in my "use x/net/context instead of context" sed of doom? :) | 10:00 |
| mwhudson | find -type f -name \*.go \! -path '*/.pc/*' -print0 | xargs -0 sed -i -e 's%^\(\s\+\)"context"$%\1"golang.org/x/net/context"%' | 10:00 |
| mwhudson | zyga: it works on docker.io :) | 10:00 |
| zyga | mwhudson: across the whole tree? | 10:01 |
| zyga | mwhudson: well, I don't mind that, though I don't see how that helps us this week (fire squad) | 10:01 |
| mwhudson | zyga: i saw something about spread not building with go 1.6? | 10:01 |
| zyga | ah | 10:01 |
| zyga | mvo fixed that earlier today | 10:02 |
| mwhudson | ok | 10:02 |
| mwhudson | never mind me then :) | 10:02 |
| zyga | mwhudson: but thank you for the offer | 10:02 |
| zyga | we are working through this list: https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954/1 | 10:02 |
| mup | PR snapd#5036 opened: overlord/snapstate: allow to get an error from readInfo instead of a broken stub, use it in doMountSnap <Created by pedronis> <https://github.com/snapcore/snapd/pull/5036> | 10:04 |
| pedronis | mvo: Chipaca: ^ | 10:04 |
| mvo | pedronis: thank you! | 10:06 |
| mborzecki | hmmm /snap/README, there goes ConditionExistsGlob | 10:07 |
| Chipaca | mborzecki: /snap/*/current | 10:07 |
| mborzecki | Chipaca: oh, that's good | 10:08 |
| mborzecki | pedronis: just to be sure, that's an /snap/.. OR /var/lib/../seed.yaml ? | 10:09 |
| mvo | mborzecki: yes, either of those should trigger a wakeup | 10:09 |
| Chipaca | Apr 12 11:09:21 fleet snapd[7512]: 2018/04/12 11:09:21.252174 services.go:226: DEBUG: StopServices called for [%!q(*snap.AppInfo=&{0xc820397600 webserver [] command-webserver.wrapper simple 0 map[network:0xc8203f9270 network-bind:0xc8203f92c0] map[] map[] {[] map[]} [] [] <nil>})], reason: remove | 10:09 |
| mup | PR #12: Bugfix/lp1480248 test reenable <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/12> | 10:09 |
| Chipaca | hmmm | 10:09 |
| mborzecki | mvo: ok | 10:09 |
| Chipaca | something awry in a printf :-) | 10:10 |
| mvo | Chipaca: woah, where did you get this? | 10:11 |
| Chipaca | mvo: snap remove a snap with a service with debug on | 10:13 |
| Chipaca | i looped installing/removing a snap without a service and it couldn't repro 1616629, so now trying with a service | 10:14 |
| pedronis | Chipaca: doInstall also has int flags, yes but things that are exported or go into state I agree we shouldn't use int flags | 10:16 |
| Chipaca | pedronis: we still have a lot of int flags, and i don't think it's a blocker | 10:16 |
| mborzecki | so the wakeup service works | 10:28 |
| mborzecki | spread test for this will be tricky | 10:28 |
| zyga | jdstrand: hey | 10:31 |
| zyga | jdstrand: is apparmor@lists.ubuntu.com still the place to send patches? | 10:31 |
| mwhudson | sergiusens: fwiw 'd bet patchelf is doing something differently horrible to java | 10:32 |
| mwhudson | +i | 10:33 |
| mup | Issue snapcraft#1676 closed: Support for set-version <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1676> | 10:34 |
| mup | PR snapcraft#2063 closed: many: add snapcraftctl set-version <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2063> | 10:34 |
| pedronis | Chipaca: btw seems we don't have undo on error code in doMountSnap, not sure it's good time to add that tough | 10:38 |
| mborzecki | pedronis: where? | 10:39 |
| mup | PR snapd#5037 opened: snap: snap.AppInfo is now a fmt.Stringer <Created by chipaca> <https://github.com/snapcore/snapd/pull/5037> | 10:39 |
| Chipaca | pedronis: undo as in in-task undo? | 10:39 |
| Chipaca | mvo ^ 5037 fixes that %!q thing | 10:40 |
| mvo | Chipaca: nice | 10:40 |
| pedronis | Chipaca: yes, in-task undo | 10:41 |
| mborzecki | pedronis: around readInfo? | 10:41 |
| Chipaca | pedronis: what are we missing? | 10:41 |
| Chipaca | pedronis: removing the mount unit? | 10:42 |
| * Chipaca looks | 10:42 | |
| pedronis | removing the mount unit | 10:42 |
| pedronis | I suppose | 10:42 |
| pedronis | in fairness SetupSnap is an opaque name | 10:42 |
| Chipaca | no, we remove the unit | 10:42 |
| Chipaca | one rror | 10:42 |
| Chipaca | RemoveSnapFiles removes the unit | 10:42 |
| Chipaca | stops and removes, even | 10:42 |
| pedronis | yes, but now ReadInfo itself can fail | 10:43 |
| pedronis | (well it always could but not materially) | 10:44 |
| Chipaca | pedronis: ah! now i gotcha | 10:44 |
| Chipaca | pedronis: sounds like you want a m.backend.RemoveSnapFiles there then | 10:45 |
| pedronis | yes, seems so | 10:45 |
| Chipaca | or maybe UndoSnapSetup? | 10:45 |
| Chipaca | UndoSetupSnap* | 10:45 |
| Chipaca | which, er, just calls RemoveSnapFIles :-) but might make the intent clearer from the calling side | 10:45 |
| pedronis | yes | 10:46 |
| zyga | woah? | 10:49 |
| zyga | WOAH | 10:50 |
| zyga | mvo: wanna hear a funny story? | 10:50 |
| zyga | my test | 10:50 |
| pedronis | Chipaca: sadly that thing needs a type | 10:50 |
| zyga | where I ate 8GB of ram pretty quickly | 10:50 |
| zyga | this was my command | 10:50 |
| zyga | sudo sh -c 'for i in $(seq 10000); do snap connect test-snapd-policy-app-consumer:bluez && snap disconnect test-snapd-policy-app-consumer:bluez; done' | 10:50 |
| zyga | I took a snapshot of all the profiles before/after this | 10:51 |
| zyga | before disconnect and after disconnect | 10:51 |
| zyga | it was connected initially | 10:51 |
| zyga | and the profiles are identical | 10:51 |
| zyga | all the apparmor profiles on my system | 10:51 |
| zyga | so we were leaking all that memory _despite_ not having _any_ changes | 10:51 |
| Chipaca | pedronis: which thing? | 10:52 |
| pedronis | UndoSnapSetup | 10:52 |
| pedronis | sorry, UndoSetupSnap | 10:52 |
| pedronis | now, that I look at the code, there's a lot of silliness going on | 10:52 |
| zyga | so, a bit of a WTF moment | 10:52 |
| Chipaca | pedronis: :-) | 10:52 |
| zyga | I will write a loop that recompiles that one profile in a loop and see if that is eating any memory | 10:52 |
| pedronis | Chipaca: SnapSetup read the type from the snap, and the its caller tries to read the type from the mount | 10:52 |
| Chipaca | zyga: wtf yes | 10:52 |
| zyga | iff it does that's also very interesting | 10:53 |
| zyga | because apparmor parser supposedly does nothing when you are not really changing the profile | 10:53 |
| Chipaca | zyga: the 8G is kernel, not snapd? | 10:53 |
| zyga | so perhaps simply reading one of the apparmorfs files leaks | 10:53 |
| zyga | Chipaca: yes | 10:53 |
| Chipaca | noice | 10:53 |
| zyga | almost all in kmalloc-1024 | 10:53 |
| zyga | I'm on mainline master | 10:53 |
| zyga | so that should give us all the fixes | 10:53 |
| zyga | I'll start by confirming the loop I used before still leaks | 10:54 |
| pedronis | Chipaca: so apart details of how is easy it is to untangle this, the readInfo is not stricly needed, it's a nice fence though | 10:54 |
| Chipaca | pedronis: only if we check the error | 10:54 |
| pedronis | but then we need the type to undo | 10:55 |
| pedronis | I wonder how painful it is to add returning the type to SetupSnap | 10:55 |
| pedronis | and how tisky | 10:55 |
| pedronis | risky even | 10:55 |
| popey | jdstrand: updating the machine (kernel) fixed that issue, thanks. | 10:56 |
| zyga | mvo: I have a feeling this issue, whatever it is, is fixed in mainline | 10:57 |
| zyga | so it _might_ be in ubuntu sauce | 10:57 |
| pedronis | Chipaca: I'll try to see what I can do | 10:57 |
| zyga | or just not present in mainline | 10:58 |
| zyga | I'm on a mainline kernel now | 10:58 |
| Chipaca | pedronis: you could even return the whole info | 10:58 |
| Chipaca | pedronis: and avoid that readinfo entirely | 10:58 |
| zyga | I'll leave it running for 15 minutes | 10:58 |
| Chipaca | ah, but we only use the type | 10:58 |
| mborzecki | what would be the idiomatic way to disable just one service in debian/rules? | 10:58 |
| Chipaca | pedronis: now i gotcha | 10:58 |
| zyga | but even if it is raising, it's doing so at a far slower pace | 10:58 |
| pedronis | the readInfo is realy a check, it this thing mounted at all | 10:59 |
| Chipaca | mborzecki: carg-cult copying of a 2MB bash file, probably | 10:59 |
| pedronis | but yes we need only the type | 10:59 |
| zyga | jdstrand: ^ FYI | 10:59 |
| Chipaca | zyga: the 8GB was also on mainline, and the difference now is just reloading in a loop? | 11:00 |
| zyga | Chipaca: AFAIK we never used mainline kernel before | 11:00 |
| zyga | on the ubuntu kernel we quickly eat memory | 11:00 |
| Chipaca | zyga: so the 8GB was on ubuntu kernel? | 11:00 |
| zyga | yes | 11:00 |
| sparkiegeek | *cough* is the forum inaccessible to everyone, or just me? | 11:03 |
| zyga | sparkiegeek: oh? | 11:03 |
| zyga | I _just now_ posted a message | 11:03 |
| zyga | https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/11?u=zyga | 11:03 |
| sparkiegeek | zyga: The certificate expired on 12 April 2018, 11:17. The current time is 12 April 2018, 12:01 | 11:03 |
| sparkiegeek | zyga: with HSTS enabled | 11:03 |
| zyga | oops :) | 11:03 |
| zyga | perhaps my browser is more lousy | 11:03 |
| Chipaca | i also don't see that fwiw | 11:03 |
| zyga | niemeyer: ^ FYI, it looks like forum cert is has expired | 11:04 |
| sparkiegeek | https://www.ssllabs.com/ssltest/analyze.html?d=forum.snapcraft.io&latest | 11:04 |
| sparkiegeek | confirms that it's expired | 11:04 |
| zyga | after running for ~10 minutes my memory usage is below 2GB | 11:04 |
| Chipaca | speaking of expiry, i need to go make lunch for the tribe | 11:07 |
| Chipaca | ttfn | 11:07 |
| sparkiegeek | Chipaca: bon appetit | 11:07 |
| niemeyer | zyga: Yeah, I was going to make sure it was renewed yesterday and missed it... | 11:08 |
| niemeyer | I'm on it | 11:08 |
| zyga | woot, thanks | 11:09 |
| vidal72[m] | are you aware of expired cert for https://forum.snapcraft.io ? | 11:11 |
| sparkiegeek | vidal72[m]: has just been fixed | 11:11 |
| vidal72[m] | sparkiegeek: I can confirm, thx | 11:12 |
| mup | PR snapd#5038 opened: data/systemd: helper service for waking up the main snapd service <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5038> | 11:19 |
| jdstrand | popey: nice! | 11:19 |
| jdstrand | zyga: yes, posting your findings to the mailing list would make sense, or adding to https://bugs.launchpad.net/apparmor/+bug/1750594 | 11:20 |
| mup | Bug #1750594: Eventual OOM with profile reloads <AppArmor:New> <https://launchpad.net/bugs/1750594> | 11:20 |
| zyga | jdstrand: nice, thanks | 11:20 |
| zyga | jdstrand: I found some interesting things already: https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/11?u=zyga | 11:22 |
| zyga | and sent some silly patches to apparmor tree | 11:22 |
| jdstrand | zyga: I see that. that should help jjohansen. I also summarized the email I sent yesterday in that topic | 11:28 |
| zyga | I see that, thanks | 11:28 |
| sergiusens | mwhudson: yeah, it seems to be the case as it is not an isolated incident | 11:29 |
| mwhudson | sergiusens: reading the patchelf code makes it seem a bit ... optimistic, maybe? | 11:30 |
| sergiusens | mwhudson: eventually I will have to do what I wanted to avoid doing when tasked to work on classic confinement and just master that code base and elf | 11:33 |
| mwhudson | sergiusens: i learnt waaaay too much about all that stuff doing go shared libraries | 11:34 |
| mwhudson | it's fun, mostly :) | 11:34 |
| mup | PR snapd#5039 opened: overlord/snapstate: use the readInfo in doMountSnap as a check only, undo if it errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5039> | 11:34 |
| pedronis | Chipaca: mvo: digging deeper ^ | 11:34 |
| mwhudson | sergiusens: have you read ian lance taylor's blog? https://www.airs.com/blog/archives/38 through https://www.airs.com/blog/archives/57 | 11:35 |
| sergiusens | I have not; adding to the reading list. Thanks! | 11:36 |
| didrocks | cjwatson: hey, sorry if the question was probably already asked (it was probably already done), but is there any way to get daily build of a snap (even if the branch didn't change, as a snapcraft.yaml can refer to multiple repos) on https://build.snapcraft.io/ or launchpad? | 11:42 |
| didrocks | I guess the workaround can be to use launchpad API to start a build, but I would prefer something more integrated | 11:43 |
| mup | PR snapcraft#2065 opened: many: update the yaml loading logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2065> | 11:43 |
| popey | didrocks: i personally use lp-build-snap (a snap) to poke the launchpad API daily via a cron job to do that | 11:44 |
| popey | build does do daily builds now AIUI. | 11:44 |
| didrocks | popey: oh? (well, I guess it's still building on xenial, which is an issue for me), but I didn't find any option | 11:45 |
| popey | it doesnt have to be building on xenial | 11:45 |
| popey | you can pick in your repo what it builds on | 11:45 |
| didrocks | on build.snapcraft.io? | 11:46 |
| popey | no, launchpad | 11:46 |
| popey | I dont use build, because i need the flexibility launchpad offers | 11:46 |
| didrocks | ah yeah, for this, sure :) | 11:46 |
| popey | build isn't supposed to cover every use case. | 11:46 |
| didrocks | "build does do daily builds now AIUI" -> you meant launchpad or build.snapcraft.io? | 11:46 |
| * cachio afk | 11:47 | |
| popey | build | 11:47 |
| didrocks | ok ;) so yeah, I have to use launchpad and having a ping script (like lp-build-snap) seems necessary | 11:48 |
| didrocks | thanks popey ;) | 11:48 |
| popey | np | 11:48 |
| mup | PR snapd#5037 closed: snap: snap.AppInfo is now a fmt.Stringer <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5037> | 11:50 |
| mborzecki | finishing up with spread test | 11:58 |
| cjwatson | didrocks: the above all seems correct. | 11:59 |
| didrocks | thx for confirming cjwatson | 12:00 |
| mborzecki | off to pick up the kids, coming back for standup | 12:04 |
| zyga | jdstrand: some more leak findings on the forum | 12:15 |
| mup | PR snapd#5040 opened: overlord/snapstate: poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap <Created by pedronis> <https://github.com/snapcore/snapd/pull/5040> | 12:15 |
| zyga | mvo: I have to break now and go to the vet but I can propose a simple tweak to apparmor backend to limit memory usage | 12:19 |
| === pstolowski is now known as pstolowski|lunch | ||
| mup | PR snapd#5041 opened: interfaces/apparmor: don't reload unchanged profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/5041> | 12:26 |
| zyga | mvo: hey | 12:26 |
| zyga | mvo: can you run adt tests against that PR somehow? | 12:26 |
| zyga | I need to break now and go to the vet or I will miss my time | 12:26 |
| zyga | I will resume my analysis later today, | 12:27 |
| mvo | zyga: yeah, I can | 12:30 |
| zyga | thanks | 12:30 |
| zyga | I'll go now, I'll be on telegram/irc on the phone though | 12:30 |
| * kalikiana lunch | 12:38 | |
| diddledan | popey: for atom, in snapcrafters, there's a new release upstream (a point release: x.y.1) do I just need to trigger a manual build in the build service to get it to update? | 12:42 |
| diddledan | alternatively, Wimpress ^^^^ | 12:42 |
| Wimpress | Yep | 12:42 |
| diddledan | aww, it says I don't have admin perms on the github repo so I can't trigger it :-( | 12:44 |
| zyga | mvo: standup postponed by one hour, right? | 12:51 |
| pedronis | mvo: I proposed a chain of PR, John reviewed them, we need to decide a bit what to do with them (whether we care more to understand the bug vs preventing it) | 12:52 |
| pedronis | it's also rare afawk | 12:52 |
| mvo | pedronis: I have a look, thank you and Chipaca | 12:54 |
| pedronis | mvo: I also tried to play with remove/install while keeping the old mount in use, but seems to just work | 12:55 |
| pedronis | at least here | 12:55 |
| mvo | zyga: standup is in 3min | 12:57 |
| mvo | mborzecki: I think I figured the refresh-mode issue out | 12:57 |
| mborzecki | mvo: what was it? | 12:57 |
| zyga | mvo: Gustavo asked to postpone | 12:57 |
| mvo | zyga: oh, ok, sorry, I miseed that | 12:58 |
| mvo | zyga: in this case, sure | 12:58 |
| pedronis | by 1h | 12:58 |
| mvo | mborzecki: we need KillMode=process in the service file for the non -all signal because it looks like system cleans up the whole cgroup if the main pid dies otherwise | 12:58 |
| mvo | mborzecki: which makes sense | 12:59 |
| mvo | mborzecki: I changed the test a bit and added some code to do this and *hopefully* this fixes this | 12:59 |
| mborzecki | mvo: a maze of manpages | 13:00 |
| mvo | mborzecki: I looked at the source :) | 13:00 |
| mvo | mborzecki: but yeah, its a bit difficult to get the picture | 13:00 |
| mvo | mborzecki: I may still miss pieces but it all makes some sense now | 13:00 |
| * mvo is a happy camper again | 13:00 | |
| pedronis | it's a maze of non-orthogonal settings | 13:00 |
| pedronis | btw it does make sense | 13:01 |
| pedronis | :/ | 13:01 |
| mborzecki | mvo: does ssytemctl stop work correctly still? | 13:01 |
| pedronis | probably not | 13:02 |
| pedronis | we need to specify --kill-who=all then? | 13:04 |
| pedronis | for when is not just a refresh | 13:04 |
| pedronis | but that's the default | 13:05 |
| pedronis | mborzecki: my reading is that stop will kill all processes one by one, instead of killing the cgroup | 13:06 |
| pedronis | (I haven't tried) | 13:06 |
| mvo | mborzecki: looking now, sorry for the delay | 13:09 |
| mvo | pedronis: yeah | 13:09 |
| * pedronis needs a break | 13:13 | |
| mborzecki | there's a problem with snapd.wakeup.service on fedora, it's disabled by systemd presets, explicitly enabling it will probably make Son_Goku unhappy | 13:15 |
| mborzecki | and fedora has presets | 13:15 |
| Son_Goku | it needs to be requested to be enabled via central presets | 13:15 |
| mborzecki | opensuse has none? | 13:15 |
| mborzecki | Son_Goku: bz ticket then? | 13:16 |
| Son_Goku | yep | 13:16 |
| Son_Goku | openSUSE has central presets too | 13:16 |
| popey | diddledan: thanks for the ping - I triggered a build | 13:25 |
| pedronis | mborzecki: can't we do it only on ubuntu, and keep the other distros as is for now | 13:25 |
| diddledan | thankyou popey | 13:25 |
| mborzecki | pedronis: yeah, i'm afraid that's what we'll have to do | 13:26 |
| mvo | mborzecki, pedronis you are right about the "stop", with KillMode=process the refresh mode works like we want it to work (yay) but the side-effect of course is that "systemctl stop service-that-uses-refresh-mode-sig{term,hup,..}" also only stops the main process | 13:28 |
| mborzecki | omg | 13:28 |
| mborzecki | mvo: mixed? | 13:28 |
| === pstolowski|lunch is now known as pstolowski | ||
| mvo | mborzecki: oh | 13:30 |
| mvo | mborzecki: let me try that | 13:30 |
| pedronis | mvo: btw, how did the autopkgtests in xenial go? | 13:36 |
| mvo | pedronis: it died in interfaces-many but I try again without this one, this test is especially problematic | 13:36 |
| pedronis | ok, but at least unblocked | 13:37 |
| pedronis | thx | 13:37 |
| mvo | pedronis: well, not sure yet if unblocked or not, I had to restart | 13:37 |
| pedronis | well, it's no worse than bionic | 13:37 |
| pedronis | something runs :) | 13:38 |
| * pedronis is about the small victories these days | 13:38 | |
| mvo | pedronis: heh, yeah | 13:38 |
| mvo | mborzecki: test with mixed running now :) | 13:39 |
| greyback | kalikiana: hey, snapcraft stuck at "Preparing to build desktop-gtk3" for me, using 100% of a cpu. How could I track down what's wrong? | 13:40 |
| mvo | mborzecki: the way I read it I don't have high hopes *but* I was wrong before! | 13:40 |
| mborzecki | mvo: aiui if the main process ignores sigterm kill is tried again, but this time everyone gets sigkill | 13:41 |
| mvo | cachio: how is the sru validation going? any fires there? | 13:42 |
| mvo | mborzecki: oh, that would be what we want I think. if the main process dies the rest is ignored if it does not die/restart the entire group is killed | 13:42 |
| cachio | mvo, hey | 13:43 |
| cachio | I finished it | 13:43 |
| mvo | cachio: yay, any issues? | 13:43 |
| mvo | mborzecki: the answer is just a spread run (and some patience) away :-D | 13:43 |
| cachio | mvo, but I saw the oom on autopackgtests for i386 | 13:43 |
| mborzecki | mvo: patience is key today | 13:44 |
| cachio | for artful and bionic | 13:44 |
| zyga | mvo: hey, just checking about that auto package test in my PR | 13:44 |
| zyga | Is it triggered, I cannot see that on the pull request page | 13:44 |
| cachio | mvo, that's the only relevant issue | 13:44 |
| cachio | mvo, I think it is because of the environment | 13:44 |
| jbicha | hi, somehow my gnome-characters snap got disconnected from the gnome-3-26-1604 snap. I'm on bionic and it used to work. I'm using stable channels for this stuff | 13:46 |
| jbicha | how can I figure out how this happened? | 13:46 |
| mvo | cachio: yeah, the oom is what we also see everywhere its a sad and known issue | 13:47 |
| cachio | the rest is | 13:47 |
| cachio | ok | 13:47 |
| cachio | mvo, well known issues on autopckgtests | 13:48 |
| mvo | cachio: great, I think we can document that in the bug and then move on and set it to validated | 13:48 |
| mvo | cachio: are there more known issue that need addressing? | 13:48 |
| cachio | yes | 13:48 |
| cachio | mvo, just that the tests on xenial are not being executed because spread cannot be built | 13:48 |
| mvo | mborzecki: mixed did not work the way we want it to work, it did kill the children | 13:48 |
| mvo | cachio: spread is fixed now | 13:49 |
| mvo | cachio: since last night :) | 13:49 |
| mvo | cachio: gustavo applied my fix (yay) | 13:49 |
| cachio | mvo, great | 13:49 |
| cachio | mvo, ok, but it failed for the sru :( | 13:49 |
| mvo | zyga: tests are running, I had to restart because it died in interfaces-many? | 13:49 |
| mvo | cachio: http://autopkgtest.ubuntu.com/browse.cgi/packages/s/snapd <- xenial is mostly green again | 13:50 |
| jbicha | hmm, gnome-characters worked after restarting my computer 😦 | 13:50 |
| mvo | cachio: I manually restarted some | 13:50 |
| cachio | mvo, nice | 13:50 |
| cachio | thankis | 13:50 |
| mvo | zyga: interfaces-many is a bit of a beast, I disabled that (and it is already disabled for autopkgtest) | 13:51 |
| mvo | zyga: so if the run survives the remaining tests, that would be huge | 13:51 |
| mvo | zyga: its at 17/224 right now | 13:51 |
| zyga | Thanks | 13:51 |
| greyback | kalikiana: ignore me, seems it was doing legitimate work | 13:52 |
| mup | PR snapd#5042 opened: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/5042> | 13:55 |
| cachio | mvo, sru in lp updated | 14:00 |
| * kalikiana totally ignores greyback and walks away again | 14:08 | |
| greyback | kalikiana: I'm trying to use cleanbuild, where my part has its source in a directory elsewhere in the system. It builds ok with dirty build, but with cleanbuild it complains it cannot determine the source type - and I see no source type specifier for a directory | 14:12 |
| greyback | any ideas? | 14:12 |
| kenvandine | jbicha, so it resolved itself on reboot? | 14:18 |
| jbicha | kenvandine: yes | 14:18 |
| kenvandine | :/ | 14:18 |
| kalikiana | greyback: elsewhere meaning outside of the source tree? is it a folder? | 14:21 |
| greyback | kalikiana: correct, and yes | 14:21 |
| kalikiana | greyback: so how do you get the folder into the container? | 14:21 |
| greyback | kalikiana: I'm not, hence the problem. | 14:22 |
| kalikiana | greyback: Can you manually copy it to the tree? Well, or if that's not an option, you could... use a persistent container that you've prepared beforehand. | 14:29 |
| greyback | kalikiana: I'm doing option 2. | 14:29 |
| greyback | kalikiana: I'll log a bug tho | 14:30 |
| kalikiana | greyback: Okay. | 14:34 |
| greyback | kalikiana: https://bugs.launchpad.net/snapcraft/+bug/1763394 | 14:34 |
| mup | Bug #1763394: cleanbuild gets confused with directory source type <Snapcraft:New> <https://launchpad.net/bugs/1763394> | 14:34 |
| kalikiana | Thanks! | 14:39 |
| Chipaca | hah, browser crashed | 14:54 |
| Chipaca | and now y'all're gone | 14:54 |
| pedronis | mvo: about my PRs, the easiest is probably to squash merge #5040 with everything (so it's easier to backport for the SRU) but I can wait for that, as you prefer | 14:54 |
| mup | PR #5040: overlord/snapstate: poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap <Created by pedronis> <https://github.com/snapcore/snapd/pull/5040> | 14:54 |
| mvo | pedronis: yeah, otoh, its just three commits so we can just backport those via three cherry-picks (hopefully not too many conflicts) | 14:55 |
| pedronis | mvo: as your prefer | 14:56 |
| pedronis | you I merge them today? or wait a bit? | 14:56 |
| pedronis | sorry | 14:56 |
| pedronis | mvo: should I merge them today or wait a bit? | 14:57 |
| mup | PR snapd#5042 closed: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5042> | 14:57 |
| pedronis | mvo: I marked them blocked for now, let me know | 14:59 |
| mvo | zyga: adt run died with oom in 153/224, sorry for that | 14:59 |
| mvo | pedronis: either is fine, its edge so feel free to merge and we can backport at our leisure | 15:00 |
| pedronis | mvo: I think I'll merge them tomorrow, I need to EOD in a bit to go to some event | 15:02 |
| pedronis | for some of my evening | 15:02 |
| pstolowski | zyga: one question to 5401 | 15:03 |
| mvo | pedronis: sure, enjoy | 15:05 |
| mvo | pedronis: its not urgent | 15:05 |
| pedronis | mvo: I don't think we have fires not under control at this point, I can be pinged on TG if needed | 15:05 |
| jdstrand | zyga: thanks for those patches! nothing silly about typo fixes :) | 15:08 |
| mvo | pedronis: yeah, thanks for all the fires you extinguished! have a great evening | 15:16 |
| zyga | pstolowski: ack, looking | 15:22 |
| zyga | pstolowski: replied | 15:26 |
| zyga | mvo: do you have an URL to the test results? | 15:26 |
| pstolowski | zyga: thanks! | 15:27 |
| mvo | zyga: I ran it locally | 15:27 |
| zyga | ah | 15:27 |
| zyga | and? :-) | 15:27 |
| mvo | zyga: its easy to reproduce, just use the ubuntu-18.04-32 image | 15:27 |
| mvo | zyga: it died at test 153 or so :( | 15:27 |
| zyga | :/ | 15:27 |
| mvo | zyga: what kind of data do you want? | 15:27 |
| zyga | crap, same way as before, right? | 15:28 |
| zyga | mvo: I wanted a pass/fail status, I got that | 15:28 |
| mvo | zyga: yeah, *maybe* it survived longer | 15:28 |
| mvo | zyga: but its hard to say as the pattern is not consistent, I would have to run with the same -seed= setting once with the branch and once without | 15:28 |
| zyga | I will do more checks at home, I need to write a small automatic program that triggers the bug and checks that memory is leaking | 15:28 |
| zyga | then try all the kernels gustavo suggested | 15:29 |
| mvo | zyga: cool, thanks | 15:29 |
| popey | diddledan: atom now in stable, thanks for the nudge | 15:32 |
| === dpb1_ is now known as dpb1 | ||
| * zyga is starving, having feed the dog I need to eat something myself | 15:46 | |
| === chihchun is now known as chihchun_afk | ||
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR snapd#5043 opened: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/5043> | 16:17 |
| mup | PR snapcraft#2061 closed: go: only use Go build package if not using the snap <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/2061> | 16:18 |
| mvo | Chipaca: 5043 might also be interessting for you, I think it is really as simple as this, when systemd sees the main-pid die it goes into stop-state which triggers the cleanups. but double checking is certainly appreciated | 16:23 |
| * kalikiana eod, o/ | 16:24 | |
| suebt | zyga: hey there :] | 16:50 |
| zyga | suebt: hi | 16:56 |
| Chipaca | mvo: what happens in 5043 if start-refresh-mode-sigterm tries a little harder? | 16:56 |
| zyga | I’m busy now, sorry, no change yet. I’ll tell you what I know back home | 16:56 |
| suebt | zyga: Okay, no problem, will hang around for a while, thank you | 16:57 |
| zyga | Sorry for keeping you waiting. It is a busy day | 16:59 |
| Chipaca | mvo: i mean, something like 'setsid nohup sleep' instead of just sleep :-) | 17:00 |
| mup | PR snapcraft#2066 opened: errors: feature flag error reports <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2066> | 17:24 |
| nacc | is there possibly a bug in snapd that let's older snaps get unmounted when they are in use? | 17:29 |
| nacc | :) | 17:29 |
| nacc | *older snap revisions | 17:29 |
| nacc | specifically, i've got a long-running app from a snap in the edge channel, which is building from master | 17:29 |
| nacc | it was at r409, now at r418 | 17:29 |
| nacc | the r409 run ended up dying suddenly because it could not find executables in it's squashfs | 17:30 |
| nacc | i'm guessing because it got unmounted on some update | 17:30 |
| Chipaca | nacc: we have a bug around long-running processes and refreshes | 17:42 |
| Chipaca | nacc: basically if an app is running, and the snap gets refreshed, the file descriptors it has are now useless | 17:42 |
| nacc | Chipaca: yeah | 17:43 |
| nacc | that's ... seriously bad for us | 17:43 |
| Chipaca | nacc: it's on the 'fix soon' list, i think it's one of the first things zyga will work on post 18.04 | 17:43 |
| Chipaca | nacc: how so? | 17:43 |
| nacc | Chipaca: because we are importing Ubuntu source packages using a snap and it crashes | 17:44 |
| nacc | for 'official' Ubuntu use :) | 17:44 |
| Chipaca | nacc: you are importing Ubuntu source packages using a snap, and the snap refreshes while the import is happening? Every time? | 17:44 |
| nacc | Chipaca: the snap *can* refresh while it is happening yes | 17:45 |
| nacc | not every time, but when it does, this clearly would break things | 17:45 |
| nacc | so we have an importer, which is short-lived (sort of) | 17:45 |
| nacc | and control scripts which are long-lived (watching the publisher itself) | 17:45 |
| nacc | the latter is quite long-lived (one never dies) | 17:45 |
| Chipaca | nacc: long lived but not a daemon? | 17:45 |
| nacc | Chipaca: right, not yet | 17:45 |
| nacc | would a daemon avoid this? | 17:46 |
| Chipaca | nacc: the daemon would be restarted on refresh (unless you ask not to be, but then presumably you're only using _COMMON | 17:46 |
| nacc | Chipaca: restarting the daemon is 'bad' for us, sort of too | 17:47 |
| nacc | Chipaca: hence why it's not a daemon yet :) | 17:47 |
| Chipaca | nacc: as a short term workaround you can ask snapd to hold off refreshes until you're done | 17:47 |
| nacc | Chipaca: yeah, i might need to do that, quick syntax/cli? | 17:47 |
| Chipaca | nacc: ach, i always get that one wrong | 17:48 |
| nacc | :) | 17:48 |
| Chipaca | it's 'snap set <something something>' | 17:48 |
| Chipaca | :-) | 17:48 |
| Chipaca | mvo knows -- and it should be documented | 17:48 |
| Chipaca | and I've got to go make dinner | 17:49 |
| nacc | Chipaca: np, i'll look it up | 17:49 |
| nacc | https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/6 i think | 17:50 |
| Chipaca | nacc: snap set core refresh.hold=<when> | 17:51 |
| Chipaca | nacc: some work to be done around the UX of it though | 17:51 |
| mup | Issue snapcraft#2033 closed: LP: #1752344 <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2033> | 17:52 |
| mup | PR snapcraft#2065 closed: many: update the yaml loading logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2065> | 17:52 |
| nacc | Chipaca: thanks | 17:52 |
| Chipaca | nacc: it requires a timestamp (the error will show you the format) | 17:52 |
| nacc | Chipaca: ok :) | 17:52 |
| Chipaca | nacc: but the expectation is that a script or something would say "give me 5 minutes" every 5 minutes until it was done | 17:52 |
| Chipaca | hence, ux needs more work (or maybe an interface that isn't 'snap set') | 17:53 |
| Chipaca | anyhoo. dinner. | 17:53 |
| zyga | nacc: refresh sanity is on my plate post 18.04 | 17:53 |
| zyga | Is the bug related to an apparmor denial? | 17:53 |
| nacc | zyga: Chipaca: thanks, i was able to set it to be at least a week away | 17:54 |
| nacc | zyga: is that to me? | 17:54 |
| zyga | Yes | 17:54 |
| nacc | zyga: no apparmor denials in dmesg | 17:54 |
| zyga | About refresh breaking some source import | 17:54 |
| nacc | zyga: it just failed to find the `git` binary that was in the snap | 17:54 |
| zyga | Can you let me know what is the problem? | 17:54 |
| nacc | because, i'm guessing, the fd was closed underneath it | 17:54 |
| zyga | Hmmm | 17:54 |
| Chipaca | o/ | 17:55 |
| zyga | It would not be closed | 17:55 |
| zyga | But can be revalidated | 17:55 |
| zyga | But that would log a denial | 17:55 |
| zyga | Can you give me a link to a case that reproduces the issue | 17:55 |
| nacc | zyga: i don't have the logs handy anymore, but i can try and scrape them (about to leave though) -- basically our snap was running (git-ubuntu.source-package-walker) ... and it ran for some time | 17:55 |
| nacc | at an older review | 17:55 |
| nacc | *revision | 17:55 |
| zyga | Including a refresh to another channel in a side terminal is ok if that helps | 17:56 |
| nacc | we then refreshed (auto) edge from which we're running | 17:56 |
| zyga | Is that snap classic or strict? | 17:56 |
| nacc | at some point, we must have gotten past the 'keep 2 versions' or whatever snapd does | 17:56 |
| nacc | classic | 17:56 |
| nacc | and our snap crashes becasue it's unable to find an executable that is in the snap | 17:56 |
| zyga | Hmmm | 17:56 |
| nacc | i believe with a 'no such file or directory' | 17:56 |
| zyga | Classic snaps have no constraints | 17:56 |
| zyga | So it is probably another part | 17:57 |
| zyga | Thanks | 17:57 |
| zyga | I know what I needed now | 17:57 |
| zyga | Right, I understand why this happens | 17:57 |
| nacc | confirmed i got a no such file or directory for 'git' in our case (which we build from source and is in our snap's path) | 17:57 |
| nacc | zyga: ok :) | 17:58 |
| zyga | Thank you | 17:58 |
| nacc | zyga: we admittedly are a weird classic snap -- we are basically confined (by munging the environment) but we need to be able to write anywhere on the fs | 17:58 |
| zyga | re | 18:06 |
| zyga | nacc: classic snaps are confined but have wide open permissions and are not sealed in a mount namespace | 18:06 |
| nacc | zyga: yeah i know | 18:07 |
| nacc | well the former part is why :) | 18:07 |
| nacc | *why we use a classic snap | 18:07 |
| zyga | to have access to /var/lib/snapd/hostfs easily? | 18:08 |
| zyga | (as in, at /) | 18:08 |
| nacc | zyga: yeah basically (and network) | 18:08 |
| nacc | but network obviously we could use an interface for | 18:08 |
| nacc | last i checked there was not a 'hostfs' interface | 18:08 |
| zyga | network? | 18:08 |
| zyga | network should not be a problem | 18:08 |
| zyga | we could add an interface for hostfs and hand it out just like classic | 18:09 |
| zyga | if that helps | 18:09 |
| nacc | zyga: that would probably help us, yes | 18:09 |
| nacc | not sure if we have other needs, but that woudl be my guess right now | 18:09 |
| nacc | zyga: gotta go afk for a bit | 18:09 |
| zyga | thanks, no worries :) | 18:10 |
| * zyga is still at school, waiting to talk to the teacher | 18:10 | |
| * zyga is very sleepy somehow | 18:20 | |
| mup | PR snapcraft#2067 opened: many: add snapcraftctl set-grade <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2067> | 18:46 |
| === Guest26743 is now known as ^arcade_droid | ||
| * zyga returns for evening hacking | 18:49 | |
| zyga | jdstrand: hey, can you please look at https://github.com/snapcore/snapd/pull/5041 and specifically at the question from pawel as well as my response there | 18:56 |
| mup | PR #5041: interfaces/apparmor: don't reload unchanged profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/5041> | 18:56 |
| zyga | jdstrand: I'm mainly trying to raise any red flags that you may notice | 18:59 |
| === zarcade_droid is now known as Guest76636 | ||
| * cachio afk | 19:02 | |
| === Guest76636 is now known as ^arcade_droid | ||
| mup | PR snapcraft#2068 opened: states: track override scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2068> | 19:40 |
| mup | PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 21:02 |
| mup | PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 21:03 |
| mup | PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 21:03 |
| jjohansen | zyga, mvo: with your testing you are only seeing this with the bionic kernel? | 21:05 |
| mup | Issue snapcraft#1681 closed: Design/document support for architecture selection during builds <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1681> | 21:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!