| mup | PR snapd#8221 opened: ovelord/snapstate: update only system wide fonts cache <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8221> | 08:33 |
|---|---|---|
| mup | Bug #1866168 opened: Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor <Snappy:New> <https://launchpad.net/bugs/1866168> | 10:09 |
| mup | PR snapd#8222 opened: wrappers: import /etc/environment in all services <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8222> | 10:45 |
| mup | Bug #1866168 changed: Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor <snapd:New> <https://launchpad.net/bugs/1866168> | 12:10 |
| zyga | jdstrand: FYI, I noticed we have failures on opensuse that are not captured by spread (though IIRC the systems were disabled recently) | 12:56 |
| zyga | https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/x86_64 | 12:56 |
| zyga | all related to seccomp | 12:56 |
| jdstrand | zyga: did they update libseccomp or golang seccomp? if so, sounds like there might be a regression | 12:57 |
| zyga | jdstrand: they might have, I left all non-ubuntu systems back home | 12:58 |
| zyga | jdstrand: I'll file a bug to track this down next week | 12:58 |
| zyga | jdstrand: just FYI in case this shows up in ubuntu | 12:58 |
| jdstrand | cool, thanks | 12:58 |
| jdstrand | iirc, they did but a new release | 12:59 |
| jdstrand | (or are about to...) | 12:59 |
| * jdstrand -> meeting | 12:59 | |
| zyga | oh | 13:00 |
| zyga | oh boy | 13:00 |
| jdstrand | zyga: https://github.com/seccomp/libseccomp/commit/fcb1395979f784387984e34752c07a5e8530c023 | 13:02 |
| zyga | hmm | 13:02 |
| zyga | thanks | 13:02 |
| zyga | doesn't seem like what we're seeing | 13:03 |
| zyga | perhaps it's the kernel too? | 13:03 |
| zyga | jdstrand: we should eventually look at enabling the binary tree optimizer https://github.com/seccomp/libseccomp/commit/a3732b32b8e67a5c466a625f0e1e0d0bfde5ee0b | 13:19 |
| ackk | hi, isn't "snap stop --disable ${SNAP_INSTANCE_NAME" supposed to stop all services for the snap? | 13:37 |
| zyga | ackk: what are you seeing happen? | 13:39 |
| zyga | (if that's grammatically correct) | 13:40 |
| mborzecki | zyga: wonder how different that optimizer is from the patches we've tried in https://forum.snapcraft.io/t/concerns-about-performance/12194/8 is it the same patch? | 13:46 |
| ackk | zyga, I'm testing a change in the maas snap to split services. I have a "install" hook which ends with that stop command, but then I see: https://paste.ubuntu.com/p/H6V2vXKGCn/ | 13:51 |
| ackk | zyga, right after install | 13:51 |
| jdstrand | zyga: can you have someone add a meeting link for the compression meeting? | 14:00 |
| jdstrand | ijohnson: ^ | 14:00 |
| jdstrand | roadmr: ^ | 14:01 |
| ackk | zyga, side question, I assume there's no way (yet) to tell snapd not to autostart services on install? | 14:01 |
| ijohnson | jdstrand: ack | 14:02 |
| roadmr | jdstrand: yes, a sec | 14:03 |
| jdstrand | I'm in | 14:04 |
| jdstrand | thanks | 14:04 |
| roadmr | jdstrand: O_o | 14:05 |
| roadmr | jdstrand: still waiting for others to arrive (snapd folks) | 14:06 |
| roadmr | I am apparently an idiot :) | 14:11 |
| jdstrand | heh | 14:24 |
| mup | PR snapcraft#2961 opened: build providers: remove over use of -i in sudo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2961> | 14:31 |
| zyga | ackk: this is a question to ijohnson | 15:07 |
| ijohnson | ackk whats the problem | 15:07 |
| zyga | jdstrand: oh, sorry, I missed your ping | 15:07 |
| ijohnson | also I'm at a sprint so intermittently available | 15:07 |
| ackk | ijohnson, so my first question is whether this is the correct status (from snap info) when the install hooks runs "snap stop --disable $SNAP_INSTANCE_NAME" at the end: https://paste.ubuntu.com/p/H6V2vXKGCn/ | 15:12 |
| ackk | ijohnson, some services are actually running | 15:12 |
| ackk | ijohnson, side question was whether it's possible to prevent them from starting up at all at snap install (I know it wasn't, just wondering if there's any progress in that direction) | 15:12 |
| ijohnson | ackk: yes it is possible to stop services from starting at all | 15:13 |
| ijohnson | ackk: what you do is call `snapctl stop --disable` exactly like you're doing during the _install_ hook specifically | 15:13 |
| ijohnson | ackk: the install hook runs before any services are started | 15:13 |
| ijohnson | ackk: also note that the install hook does not run on refresh, for that you need to use the post-refresh hook | 15:14 |
| ackk | ijohnson, I'm doing that in the install hook | 15:14 |
| ijohnson | ackk: are you testing this with the snap already installed ? | 15:14 |
| ijohnson | the thing I am currently checking on for you is whether you can disable all services with just the snap name | 15:15 |
| ackk | ijohnson, no, first install | 15:15 |
| ijohnson | I don't remember if that works or is supposed to work | 15:15 |
| ackk | ijohnson, I'm pretty sure services used to be started by default before install hook runs. but running stop --disable used to work stopping there | 15:17 |
| ackk | not sure why it's not working in this case | 15:17 |
| ijohnson | ackk: I don't think it has ever been the case that services were started before the install hook | 15:17 |
| ijohnson | ackk: perhaps you're thinking of the configure hook? | 15:17 |
| zyga | ijohnson, ackk: just thinking about what you guys are discussing, I wonder if there's anything we could learn from systemd presets that could be, somehow, represented in snapd | 15:19 |
| ijohnson | ackk: AFAICT I don't think `snapctl stop --disable $SNAP_INSTANCE_NAME` should work, I think it always has to be `snapctl stop --disable $SNAP_INSTANCE_NAME.$SVC_NAME` | 15:19 |
| zyga | even if there's just one preset and that preset is "the service is disabled" | 15:20 |
| zyga | having a way to express that with a common language might be useful | 15:20 |
| ackk | ijohnson, it used to work, we are using it elsewhere | 15:21 |
| ijohnson | ackk: can you show me an example ? | 15:21 |
| ackk | ijohnson, and indeed if you look at the paste services are all disabled | 15:21 |
| ijohnson | of where it used to work ? | 15:21 |
| ackk | ijohnson, just some of them aren't stopped | 15:21 |
| ijohnson | I am confused how it could work | 15:21 |
| ackk | ijohnson, why wouldn't it? | 15:22 |
| ackk | snapctl runs those commands at the end of the hook | 15:22 |
| ijohnson | ackk: because the install task is and always has been ordered before the start-snap-services task | 15:22 |
| ijohnson | this is internal to snapd | 15:22 |
| ijohnson | ackk: so I have tested and actually what you have with `snapctl stop --disable $SNAP_NAME` should work fine, indeed it does in my very simple example snap | 15:25 |
| ijohnson | ackk: so since you say this isn't working, can you file a bug on bugs.launchpad.net/snapd ? I need to start another meeting shortly and will not be able to debug this much more with you unfortunately | 15:26 |
| ackk | ijohnson, sure, I'll try to get more info and then file it | 15:27 |
| ackk | ijohnson, thanks | 15:27 |
| ijohnson | zyga: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177 | 15:41 |
| mup | Bug #1861177: seccomp_rule_add is very slow <patch> <server-next> <snapd:Triaged by anonymouse67> <libseccomp (Ubuntu):Triaged> <https://launchpad.net/bugs/1861177> | 15:42 |
| jdstrand | ijohnson: hey, do you have different numbers tacked onto anonymouse dependent on the site login? :) | 15:44 |
| jdstrand | anonymouse64, anonymouse67... | 15:45 |
| * jdstrand is going to map these out | 15:45 | |
| ijohnson | jdstrand: yes, it's a long story | 15:47 |
| ijohnson | I am both of those | 15:48 |
| jdstrand | ijohnson: I've yet to meet anonymouse65. I've heard great things about that guy | 15:48 |
| jdstrand | :) | 15:48 |
| ijohnson | haha :-) | 15:49 |
| mup | PR snapcraft#2961 closed: build providers: remove over use of -i in sudo <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2961> | 16:14 |
| mup | PR snapd#8223 opened: interfaces/u2f: Add Titan USB-C key <Created by stgraber> <https://github.com/snapcore/snapd/pull/8223> | 16:19 |
| JuJUBee | I installed a snap application in an LTSP environment. My user home dir is /home/admin. My students are /homes/username I can run the snap app but they cannot. | 17:37 |
| zyga | JuJUBee: this is a known limitation | 17:38 |
| zyga | JuJUBee: such home directories are sadly not supported | 17:38 |
| JuJUBee | zyga, does https://forum.snapcraft.io/t/how-can-i-use-snap-when-i-dont-use-home-user/3352/2 suggest otherwise? | 17:44 |
| zyga | JuJUBee: no, it's not, it talks about certain things that we could eventually do; today if you want a user to use snaps their home directory must really be (as in directory inode) in /home | 17:45 |
| zyga | you can bind mount it or mount it there | 17:45 |
| zyga | but it cannot be a symlink | 17:45 |
| zyga | the rest about HOMEDIRS is irrelevant for /homes (note the plural) because /homes is invisible from the point of view of a snap application | 17:46 |
| zyga | it's a long thread but I generally know what happens at runtime and I can only summarize that /homes/$LOGNAME is not supported | 17:47 |
| JuJUBee | zyga, so should I just mount the disk that is /homes on /home instead? | 18:09 |
| zyga | JuJUBee: yes | 18:09 |
| zyga | JuJUBee: can you also leave me a message as to why you chose this layout | 18:09 |
| zyga | we will try to support arbitrary home directories better | 18:09 |
| zyga | but understanding the use cases helps | 18:09 |
| JuJUBee | zyga, where would you like me to leave it? pm? | 18:10 |
| zyga | JuJUBee: just here | 18:10 |
| zyga | I'm getting dinner in 5 minutes | 18:10 |
| zyga | so I won't respond | 18:10 |
| zyga | but I'm online 24/7 so I will read it and respond later, if you are available | 18:10 |
| * zyga is AFK | 18:12 | |
| JuJUBee | zyga, OK, so I usually keep my users on a separate volume so upgrades are easier. I used to use local_homes for the local admin account and /home for my users but it was easier to use /home during the install and mount the extra volume on /homes after the fact. | 18:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!