=== Lord-Kam_ is now known as Lord-Kamina [09:06] sil2100 seb128: hi, can I draw your attention to this: [09:07] [09:51] btw maybe someone can find someone to poke about https://bugs.launchpad.net/ubuntu/+source/libpwquality/+bug/1834480 it's gonna be impacting plasma 5.17 when I land https://phabricator.kde.org/D22122 [09:07] Launchpad bug 1834480 in langpack-o-matic "translations in not so ideal language-pack" [Undecided,New] === alan_g is now known as alan_g_ [13:07] tjaalton: hi, around? Could you please take a quick look at this paste: https://pastebin.ubuntu.com/p/ZzW8BG2fpm/ line 16 [13:07] it seems to imply there is an invisible default /etc/sssd/sssd.conf file [13:07] I'm checking in the debian build now to compare [13:10] same in debian [13:18] ahasenack: and this is with the latest 2.2.0? [13:18] yes [13:18] the install doesn't fail [13:18] tests pass [13:19] but the socket services try to start, and fail like that [13:19] I'm wondering if they could use a ConditionFileNotEmpty [13:19] I guess fedora/rh don't see this because they don't start services by default? [13:19] I'm ready to send an email to sssd-users@ [13:20] well no-one has complained about it on debian [13:20] I don't know why it thinks sssd.conf is there [13:20] it also happens there, this is the postinst output: [13:21] tjaalton: https://pastebin.ubuntu.com/p/5cSFT4hmnJ/ [13:22] so it needs sssd.conf? [13:23] I haven't used it in a while.. [13:23] a few other services start [13:23] these 3 [13:23] 1871 ? Ss 0:00 /usr/sbin/sssd -i --logger=files [13:23] 1872 ? S 0:00 \_ /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files [13:23] 1873 ? S 0:00 \_ /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files [13:23] probably noops [13:24] there's your nss [13:25] but sssd-nss.service stays it's disabled, is this the same? [13:25] execstart for sssd-nss.service has "ExecStart=/usr/libexec/sssd/sssd_nss ${DEBUG_LOGGER} --socket-activated" [13:26] did you have sssd running before the upgrade? [13:26] nope, fresh install in debian-sid [13:27] (same case in ubuntu) [13:27] sssd spawned sssd_nss, but there is also a systemd service file for sssd-nss [13:28] is this a case where one would choose one or the other? Either start it from the get-go, or use socket activations? [13:29] I'm thinking the default implicit config (without sssd.conf) assumes it should start, and we are at the same time trying to use socket activation, but the socket activation is a bit incompatible with this implicit ssd.conf [13:31] I need to test on a vm [13:34] sounds like it should use different defaults when starting without a conffile [13:37] or not start at all [13:37] we could add a ConditionFileNotEmpty, or whatever it's called [13:37] to the socket systemd services [13:38] but it sounds like two categories of services: the normal ones, where you just start it even if it's not used,and the socket activated ones [13:38] starting both seems wrong [13:39] socket activated ones shouldn't be "started" [13:39] so the postinst output looks weird to me [13:42] if we do nothing against it, dh_installsystemd will enable it on first install [13:43] meh, when is samba-common-bin postinst going to be fixed to not fail when smb.conf isn't around [13:51] hm, "The services' list is optional on platforms where systemd is supported, as they will either be socket or D-Bus activated when needed." [13:53] I was wrong, the socket listener is actually started and is shown by systemctl [13:53] anyway, with the conffile from examples it'll work properly, so the daemon defaults are just wrong [13:55] you mean defaults without a conffile [13:56] yep [13:58] upstream says it shouldn't start with sssd_nss [13:58] it's the same about all others [13:59] Aug 01 12:49:07 eoan-sssd2 sssd_check_socket_activated_responders[3014]: The sudo responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sssd/sssd.conf. [13:59] sudo, for example [13:59] yes, but for the same reason [13:59] with a dummy conffile it's fine [14:00] so "services" suddenly grew a long list of defaults if there is no sssd.conf [14:00] something like that [14:00] I emailed sssd-users@ [14:00] I'm talking with lslebodn [14:00] who is that? [14:01] and which channel, assuming it's irc? [14:01] #sssd [14:01] lukas slebodnik [14:01] from redhat [14:11] is 18.04.3 likely to happen today, i.e. are there known reasons making it unlikely right now (i'm aware such can come up later)? [14:12] tomreyn: no, delayed for one week [14:12] thanks tjaalton , did i miss an e-mail on this? or will there likely be one? [14:13] uh, there isn't one? [14:13] not on -announce or -release [14:14] ok then [14:14] well that's what I heard somewhere [14:14] maybe I'm wrong [14:14] i'm looking at https://lists.ubuntu.com/archives/ubuntu-announce/ [14:14] is this the right place? [14:14] tjaalton, how do you know that 18.04.3 is delayed for a week?? [14:15] I don't [14:15] it was a rumor it seems [14:16] sorry to hear this ;) [14:27] ahasenack: so, the verdict is that socket activation just doesn't work without a conffile right now. but it doesn't actually break anything, once sssd has been configured and restarted it's all fine [14:28] trying to find where the defaults are set [14:28] should be a simple patch [14:28] should we add a ConditionFileNotEmpty? [14:28] for sssd.conf [14:29] service you mean? [14:30] sssd.service [14:30] I mean to the systemd socket files [14:30] so they won't start without a config file [14:31] sssd starts fine, albeit useless [14:31] I won't do that in debian ;) [14:31] no prior art? [14:31] looks like src/confdb/confdb_setup.c needs fixing [14:31] it's a non-issue mostly [14:32] install is noisy, that's all [14:32] and if someone checks the status output, as suggested in that output [14:32] but nothing broke, as evidenced by the tests even [14:34] I'll patch the fallback setup instead [14:35] char fallback_cfg[] = ... <-- that bit [14:35] Apologies all, the point release is delayed. [14:35] although it's not listing sudo and the others [14:35] it will not happen today, there were issues found in kernel testing. [14:35] to match the patched examples/sssd.conf [14:35] ahasenack: I think socket activation breaks if services lists any of them [14:36] yes, it's one or the other [14:36] but this implicit config, when there is no config file, isn't listing sudo or the others, and they are still complaining that they were listed [14:36] the output just assumes there's a conffile with services= [14:38] tomreyn: ^ the release is in fact delayed [14:40] tjaalton, gaughen: thanks for the notice - can you say until when it'll be postponed, yet, should users check ubuntu-announce for a notice on this? [14:41] tomreyn, tjaalton last I knew the plan was for next Thursday, but infinity would have the latest info has he's running the release [14:41] tomreyn, I do not think that's an unreasonable expectation, apologies for dropping this on y'all at the last minute [14:43] personally i'm always happy with delays if it helps stabilizing a release. [15:28] ahasenack: patching it didn't help for some reason [15:33] tjaalton: you just dropped the services line? [15:33] in that fallback config [15:33] yes [15:34] then I created a conffile which matches the fallback, and then it works.. so looks like the checker is broken [16:02] so, since it's EOB in UK, should we expect an e-mail or other announcement about the 18.04.3 delay? [16:03] there will be an email announcement; the release manager is not on UK time [16:04] great :) [16:07] ahasenack: check_socket_activated_responder() checks for the conffile, and if it doesn't exist, bails out [16:08] ahasenack: I'm currently bisecting a kernel for a regression found in 5.0, so if you have time to poke sssd further then feel free to ;) [16:38] hello, broadcast question: (I'm talking about flang): how can a package that *never* installs libomp5 in the build process runtime depend on it? [16:38] Depends: libc6 (>= 2.29), libgcc1 (>= 1:3.0), libomp5 (>= 0.20130412) [16:47] tjaalton: thanks for the troubleshooting done so far === karimsye_ is now known as karimsye === JamieBennett_ is now known as JamieBennett === tedg_ is now known as tedg === jamespage_ is now known as jamespage === kenvandine_ is now known as kenvandine === zyga_ is now known as zyga === odc_ is now known as odc === joedborg_ is now known as joedborg