[05:41] morning [07:01] morning [07:12] good morning :) [08:29] wow, copy paste to apps on xorg does not work again :/ [08:56] portal or xwayland? [09:20] mvo: hey, wdyt about https://github.com/snapcore/snapd/pull/10894 ? [09:20] PR #10894: o/configcore: allow hostnames up to 253 characters, with dot-delimited elements [10:58] pstolowski: uh, sorry, was too busy, let me look again [11:05] PR snapd#10894 closed: o/configcore: allow hostnames up to 253 characters, with dot-delimited elements [11:07] mvo: can you land https://github.com/snapcore/snapd/pull/10899 ? the failures are unrelated [11:07] PR #10899: packaging: fixes for building on openSUSE [11:10] PR snapd#10907 opened: interfaces: timezone-control, add permission for ListTimezones DBus call [11:15] mvo: thanks! [11:15] mvo: also, can you take a look at https://github.com/snapcore/snapd/pull/10901 ? it uses epochs now [11:15] PR #10901: overlord: add managers unit test demonstrating cyclic dependency between gadget and kernel updates [11:15] PR snapd#10899 closed: packaging: fixes for building on openSUSE [11:20] mardy: was it you who ad problems with some apparmor capability entry that was not understood by old apparmor_parser? [11:22] mborzecki: it was about seccomp, but it was happening because I was testing a newer version of snapd, while having the old snap-seccomp binary [11:22] mborzecki: so not something that would normally affect end users [11:22] ah ok, i recall someone mentioning a problem like this and i need to look into related issue with capability="bpf" [11:23] mvo: thanks! can you also merge https://github.com/snapcore/snapd/pull/10699 ? [11:23] PR #10699: daemon: allow enabling enforce mode

[11:28] * pstolowski going to the doctor. bbiab [11:50] Hi, I tried adding serial port interface in the gadget with path (without product and vendor id) and it does not add the interface to the udev rules. But i when add the product and vendor id to the serial port interface, it adds it. Is this a bug? [12:01] ares0128, is this a USB device ? else there would be no udev rules needed, you just add "path: /dev/XYZ1" and all consumers of that serial-port interface should get full access to that path, vendor anmd product should only be needed for USB->Serial devices [12:02] (and if it is a USB device, it will *need* both indeed) [12:03] its connected to uart ports so i cant get their ids [12:03] well, but you get a /dev/XXX node created from the kernel ? [12:04] yes i do [12:05] so a simple serial-port device with path: shoudl be sufficient ... your apps should just use the serial-port plug then and you need to properly connect the interfaces [12:05] ... that should give your app access to /dev/XXX [12:06] (there are no udev rules needed in that case ... ) [12:06] yeah that works, but i have to modify the udevrules to give a custom port name [12:06] why do you need to give a custom port name beyonf /dev/XXX ? [12:06] *beyond [12:06] for eg, SUBSYSTEM=="tty", KERNEL=="ttyAMA1", SYMLINK+="gnss", MODE="0666" [12:07] yes [12:07] why ? 🙂 [12:07] your app should simply access /dev/ttyAMA1 here ... [12:08] yeah, just for readaiblity [12:08] moreover i want to run a script on detecting the port [12:08] so , SUBSYSTEM=="tty", KERNEL=="ttyAMA1", SYMLINK+="gnss", MODE="0666", RUN+= "some script. sh" [12:10] '=D [12:11] you can do that from a scripted daemon instead: [12:11] https://github.com/ogra1/dashkiosk-client-image-config/blob/master/netplan-import#L16 [12:13] just create a snap with your "some script. sh" inside, wrap it in a udevadm monitor call like above (with the correct subsystem indeed) ... and you should be good ... [12:13] ... and make it a daemon indeed [12:15] ok i will give it a try [12:15] re [12:15] would this reload the udev rules? [12:16] i dont understand why we dont have to reload udev rules after modifying it using a install hook [12:21] the script solution does not need the udev rules ... it uses udevadm monitor to watch udev [12:21] you can use any property udev knows about to trigger it ... [14:05] mvo: ijohnson: fwiw i came up with some code that can block clone3 with enosys, https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/clone-3-enosys unit tests aren't passing yet, but i was able to verify on a box that clone3() indeed gets blocked with this specific errno and the program still works [14:05] mborzecki: nice! [14:42] mvo: hey! We might need some help on 21.10 from people that know the snap-workings! [14:44] We have this bug reported: LP: #1946656 [14:44] Bug #1946656: [daily impish-live-server] snap stuck in the installer system [14:48] So basically it's causing a hang of `snap list` etc. commands once networking is up on the installer, and as per Brian's screenshot it feels like some snapcraft API call failure? [14:50] Does anyone have a hunch as for what could be the case here? [15:03] sil2100: do we have any logs ? [15:04] i.e. not screenshots of logs but full logs 🙂 [15:05] bboozzoo: very cool, not sure I agree with the syntax in the file around specifying to return ENOSYS, but that's awesome that you got it to work [15:09] Okay, I think this might have been a snapstore temporary issue [15:30] that's odd though, i don't think any store issue should cause this [16:06] PR snapd#10903 closed: gadget/ondisk.go: include the filesystem UUID in the returned OnDiskVolume [16:46] Issue core20#117 opened: no license shown in snapstore [17:06] ijohnson[m]: what logs would you like? [17:11] dbungert: well if it's still an issue, logs from snapd mainly `journalctl --no-pager -u snapd` [17:11] bonus points if beforehand you can put snapd into debug mode with SNAPD_DEBUG=1, either putting that in a systemd drop in or with i.e. systemctl edit snapd or /etc/environment works too [17:12] I'll send you the non-debug log first since that's what I have [17:13] https://paste.ubuntu.com/p/C2sXjby3Sh/ [17:17] ack, sounds good [17:26] ijohnson[m]: yes, it is still an issue sadly. debug version https://paste.ubuntu.com/p/NZQKQSxgtR/ [18:02] dbungert: huh that's odd it looks like something is trying to tell snapd to stop while it is processing the results from the store, would you mind putting that into the bug and then also putting into the bug the output of `systemctl status snapd` and `snap changes` [18:03] * ijohnson[m] needs to go afk for 2ish hours, will be back in PM to look again [18:07] is there another way to get `snap changes` info if the socket is rejecting connections? [18:07] dbungert: `sudo snap debug state /var/lib/snapd/state.json` [19:43] PR snapcraft#3590 opened: snap: correct patch path quotes [20:18] PR snapcraft#3590 closed: snap: correct patch path quotes [20:42] ijohnson[m]: so i think the store stuff is a red herring, i can reproduce in a vm with no network [20:42] ijohnson[m]: the symptom is that SIGTERM is not making snapd exit [20:43] how do i make snapd vomit everything into the journal, SNAPD_DEBUG=3 still? [20:43] SNAPD_DEBUG=1 and if you want all the gory http details it's SNAPD_DEBUG_HTTP=7 [20:46] yeah i just get "Exiting on terminating signal" [20:46] and it doesn't exit [20:46] or hmm maybe it does but just takes a while [20:46] Maybe try snap debug traceback I think? [20:47] debug stacktraces i think [20:47] Ah yeah that's it [20:49] i should probably do this in a vm that has network if i want to get the files out :) [20:55] well now snap debug stacktraces is hanging too [20:56] You can make snapd do the stack trace thing by sending it a signal [20:56] Sorry I'm still afk technically just reading on my phone, I'll have a look for real when I'm back at home [20:56] do you remember what signal? [20:56] and no worries, we can do this better when you're back [20:57] One of the sigusrs I think? [20:57] I thought it was a go thing iirc not snapd specific [20:58] snapd took 221 seconds to die [20:58] this seems a little unreasonable :) [20:58] but it's behaving now [20:59] so something about a signal arriving while some kind of initial setup happening does sort of fit the behaviour [21:00] but i guess the initial setup taking 4 or 5 minutes is not expected [21:01] oh [21:01] Oct 11 20:57:55 ubuntu-server systemd[1]: snapd.service: Watchdog timeout (limit 5min)! [21:24] does SNAPD_DEBUG=1 (or snapd.debug=1 on cmdline) make logger.Noticef messages appear? [21:44] Noticef messages should always appear [21:56] ijohnson[m]: i commented on the bug [21:57] https://bugs.launchpad.net/ubuntu-cdimage/+bug/1946656 fwiw [21:57] Bug #1946656: [daily impish-live-server] snap stuck in the installer system === not_phunyguy is now known as phunyguy [23:51] Hi. It seems like every time my system's been up for a week or 2, when I run `snap changes` everthing has status "Error". Could someone point me to some help on how to debug things? [23:52] My most recent change line is: 800 Error today at 15:07 EDT today at 15:08 EDT Auto-refresh snap "chromium" [23:53] generally once one package has an error, they all will until the next time I reboot.