Re: [systemd-devel] How should Wayland compositors handle logind restarts?
On 2/8/21 12:55 PM, Zbigniew Jędrzejewski-Szmek wrote: The culprit seems to be that atomic commits fail with the "Permission denied" error. That's because of a bug in logind. I started working on a fix last year [1], but doing this properly requires restructuring how the code handles cleanup. It's on the TODO list. [1] https://github.com/systemd/systemd/pull/17558 Oh, nice. Thank you for clarifying things. :-) Cheers, Vlad Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How should Wayland compositors handle logind restarts?
Hi, Currently, a lot of Wayland compositors can't recover from logind restarts. For example, that's the case with weston, sway, kwin, and perhaps other compositors. The culprit seems to be that atomic commits fail with the "Permission denied" error. My question is - should Wayland compositors handle logind restarts in any way? At the moment, many Wayland compositors don't take any precautions against the case where logind is restarted. They assume that the DRM file descriptors will remain valid and the session will be restored auto-magically. Cheers, Vlad ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved and nss_ldap
Mantas, I'm aware of all the software you mentioned, but there's a few things to consider: - nslcd is quite old and personally I don't think it's the way to go - the glibc's nscd wouldn't help in this case and will bring just troubles (based as well on my experiences). More and more admins (since at least a few years ago) are avoiding using nscd in complex network environments, particularly because of problems with DNS caching in case of failover, etc.. I thought about sssd as a replacement, but haven't had time to test this combination yet (although I have quite a lot experiences with sssd). If somebody has any experiences in this area, please share ;-) Regards, Vlad. On 04/07/18 13:50, Mantas Mikulėnas wrote: > On Wed, Jul 4, 2018 at 2:03 PM Lennart Poettering > mailto:lenn...@poettering.net>> wrote: > > I am pretty sure it's not the best design today that nss-ldap inserts > a complex, network facing piece of code into all kinds of system > processes the way it does, even the most benign ones such as > "ls". This is security sensitive stuff after all... > > > There actually exist two modules both named 'libnss_ldap': the > original one from PADL loads a LDAP client directly in-process, while > the one from 'nslcd' (aka nss-pam-ldapd) uses a Unix socket connection > to its own daemon (so it works the same way as nss-resolve). And yes, > the one in nslcd should be used whenever possible. > > (I think glibc's nscd should also not be forgotten, since it offloads > *all* modules into a single caching daemon. Would have protected > against last year's glibc libnss_dns CVE, I'm sure.) > > -- > Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved and nss_ldap
Lennart, Thanks for all the information amd explanation! Below is all the details: - systemd-239 - systemd-resolve as well ass all systemd related users are defined in /etc/passwd - nss_ldap is configured via nss_initgroups_ignoreusers to not lookup groups fro all system related users include all systemd users Do you think changing "DynamicUser" to "no" should solve the issue? I see that quite a few services (systemd-resolve, systemd-networkd, firewalld, etc.) have "DynamicUser=yes". Regards, Vlad. On 04/07/18 13:03, Lennart Poettering wrote: > On Di, 03.07.18 22:16, Vlad (vo...@vovan.nl) wrote: > >> Hello, >> >> It looks like the combination of systemd-resolved service for DNS name >> resolution with nss_ldap hangs the system during boot. Particularly the >> following configuration in nsswitch.conf leads to boot problem: > Which systemd version is this? > > Since 239 systemd-resolved will use DynamicUser=1 to allocate its user > ID dynamically. Previously that user was statically defined in > /etc/passwd. Allocating a user dynamically means it needs to be tested > against /etc/passwd, where it won't exist generally. I figure you are > getting a dead lock due to that, as nss-ldap will probably get into > effect if a user is looked for that doesn't exist in > /etc/passwd. nss-ldap then probably freezes on trying to connect to > some network server through DNS which in turn causes resolved to be > triggered but it can't, after all that's what we are currently in the > process of doing... > > I am pretty sure it's not the best design today that nss-ldap inserts > a complex, network facing piece of code into all kinds of system > processes the way it does, even the most benign ones such as > "ls". This is security sensitive stuff after all... > > One simple work-around is to pre-allocate the "systemd-resolve" user > statically in /etc/passwd (i.e. create it with normal > useradd/adduser). That way nss-ldap won't get triggered. > > I'll add a brief note about this to the NEWS file, since this might be > something other folks using network-facing NSS modules might run into. > > It might be worth finding a way to turn off nss-resolve automatically > when we are preparing start-up for systemd-resolved. I'll look into > that. > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-resolved and nss_ldap
Hello, It looks like the combination of systemd-resolved service for DNS name resolution with nss_ldap hangs the system during boot. Particularly the following configuration in nsswitch.conf leads to boot problem: === passwd: files ldap group: files ldap hosts: files mymachines resolve [!UNAVAIL=return] dns === Both configurations below work just fine. === passwd: files group: files hosts: files mymachines resolve [!UNAVAIL=return] dns === OR === passwd: files ldap group: files ldap hosts: files mymachines dns === I'd appreciate any thoughts about this issue. Regards, Vlad. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-234 automount fails
Without the x-systemd.automount option just "mount /mnt/data" works fine after reboot. Regards, Vlad. On 31/07/17 16:36, Lennart Poettering wrote: > On Do, 27.07.17 12:27, Vlad (vo...@vovan.nl) wrote: > >> Hello, >> >> Autogenerated from fstab mount unit fails, the relevant fstab entry: >> UUID=xx /mnt/data btrfs >> noatime,autodefrag,discard,subvol=data,nofail,noauto,x-systemd.automount >> >> 0 0 >> >> >From log >> Jul 27 12:09:15 xxx systemd[1]: mnt-data.automount: Got automount >> request for /mnt/data, triggered by 2045 (ls) >> Jul 27 12:09:15 xxx systemd[1]: Mounting /mnt/data... >> Jul 27 12:09:15 xxx systemd[1]: mnt-data.mount: Mount process exited, >> code=exited status=32 >> Jul 27 12:09:15 xxx systemd[1]: Failed to mount /mnt/data. >> Jul 27 12:09:15 xxx systemd[1]: mnt-data.mount: Unit entered failed state. >> >> >> Works fine with systemd versions < 234. > > Hmm, /bin/mount returns 32, which means "mount failure" according to > its documentation... > > If you issue "mount UUID= /mnt/data > btrfsnoatime,autodefrag,discard,subvol=data,nofail,noauto," on the > shell, does it work then? > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-234 automount fails
Hello, Autogenerated from fstab mount unit fails, the relevant fstab entry: UUID=xx /mnt/data btrfs noatime,autodefrag,discard,subvol=data,nofail,noauto,x-systemd.automount 0 0 >From log Jul 27 12:09:15 xxx systemd[1]: mnt-data.automount: Got automount request for /mnt/data, triggered by 2045 (ls) Jul 27 12:09:15 xxx systemd[1]: Mounting /mnt/data... Jul 27 12:09:15 xxx systemd[1]: mnt-data.mount: Mount process exited, code=exited status=32 Jul 27 12:09:15 xxx systemd[1]: Failed to mount /mnt/data. Jul 27 12:09:15 xxx systemd[1]: mnt-data.mount: Unit entered failed state. Works fine with systemd versions < 234. Regards, Vlad. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Upgrade 232 -> 233: user@XXX.service: Failed at step PAM spawning...
I'd like to summarize all the thought about this issue. The systemd behavior regarding PAM stack has been changed: 1. systemd-232: if PAM stack fails service unit is still started, so PAM errors are ignored. 2. systemd-233: if PAM stack fails service unit fails as well. The second is IMO the right logic, please correct me it's not the case. However the first one is just wrong, isn't it? Regards, Vlad. On 29/04/17 18:19, Lennart Poettering wrote: > On Sat, 29.04.17 16:59, Vlad (vo...@vovan.nl) wrote: > >> Thanks for the answer. I'd then rephrase my original question: I'd like >> to know what has been changed in the systemd (pam_systemd?) version 233, >> that now it fails to start user@xxx.service? If I downgrade to the >> version 232, then systemd gives the same error, but still starts >> user@xxx.service successfully (pam configuration is exactly the same for >> both systemd versions). > Here's an educated guess: maybe it's not pam_systemd that fails but > pam_keyring, due to the recent keyring changes? (every service know > gets its own fresh keyring set up, maybe the way you invoke > pam_keyring clashes with that?) > > Anyway, please figure out which PAM module precisely fails, using PAM > debugging. For that stuff please consult the PAM community or > documentation. > > Thanks, > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Upgrade 232 -> 233: user@XXX.service: Failed at step PAM spawning...
I suppose you meant pam_keyinit, not pam_keyring, right? Although I saw that the new version of default "systemd-user" pam configuration file added pam_keyinit, I tested migration of systemd from 232 to 233 with exactly the same pam.d configuration (as I mentioned below). The _only_ thing that has been changed in the system is the version of installed systemd and this leads to failed user@xxx.service. Vlad. On 29/04/17 18:19, Lennart Poettering wrote: > On Sat, 29.04.17 16:59, Vlad (vo...@vovan.nl) wrote: > >> Thanks for the answer. I'd then rephrase my original question: I'd like >> to know what has been changed in the systemd (pam_systemd?) version 233, >> that now it fails to start user@xxx.service? If I downgrade to the >> version 232, then systemd gives the same error, but still starts >> user@xxx.service successfully (pam configuration is exactly the same for >> both systemd versions). > Here's an educated guess: maybe it's not pam_systemd that fails but > pam_keyring, due to the recent keyring changes? (every service know > gets its own fresh keyring set up, maybe the way you invoke > pam_keyring clashes with that?) > > Anyway, please figure out which PAM module precisely fails, using PAM > debugging. For that stuff please consult the PAM community or > documentation. > > Thanks, > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Upgrade 232 -> 233: user@XXX.service: Failed at step PAM spawning...
Thanks for the answer. I'd then rephrase my original question: I'd like to know what has been changed in the systemd (pam_systemd?) version 233, that now it fails to start user@xxx.service? If I downgrade to the version 232, then systemd gives the same error, but still starts user@xxx.service successfully (pam configuration is exactly the same for both systemd versions). Regards, Vlad. On 29/04/17 13:29, Lennart Poettering wrote: > On Sat, 29.04.17 13:25, Vlad (vo...@vovan.nl) wrote: > >> Lennart, >> >> I've just tried your suggestion as well, but it doesn't change behavior. >> I'm just wondering how it would be possible to investigate the error. >> The message "user@xxx.service: Failed at step PAM spawning >> /usr/lib/systemd/systemd: Operation not permitted" isn't very >> descriptive. I enabled debug for pam_systemd, but it doesn't give useful >> information in my case. > Well, I figure you should look for PAM level debugging, not > systemd level debugging for this. Contact the PAM community for help > on that. > > But do note again that distros vary greatly on PAM, and while "-" is > typically used on Fedora-based distros, IIRC other distros don't know > or use that concept. Please ask your distro for help. > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Upgrade 232 -> 233: user@XXX.service: Failed at step PAM spawning...
Lennart, I've just tried your suggestion as well, but it doesn't change behavior. I'm just wondering how it would be possible to investigate the error. The message "user@xxx.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted" isn't very descriptive. I enabled debug for pam_systemd, but it doesn't give useful information in my case. Regards, Vlad. On 29/04/17 12:21, Lennart Poettering wrote: > On Sat, 29.04.17 11:13, Vlad (vo...@vovan.nl) wrote: > >> Hello, >> >> I've recently updated systemd and now user session is failing to start: >> Apr 29 11:04:02 xxx systemd[550]: user@xxx.service: Failed at step PAM >> spawning /usr/lib/systemd/systemd: Operation not permitted >> Apr 29 11:04:02 xxx systemd[1]: Failed to start User Manager for UID xxx. >> Apr 29 11:04:02 xxx lightdm[535]: pam_systemd(lightdm:session): Failed >> to create session: Start job for unit user@xxx.service failed with 'failed' >> >> Apparently the previous version gives similar error as well, but doesn't >> fail to start user session: >> Apr 29 11:09:37 xxx systemd[565]: user@xxx.service: Failed at step PAM >> spawning /usr/lib/systemd/systemd: Operation not permitted >> Apr 29 11:09:37 xxx systemd[1]: Started User Manager for UID xxx. >> >> I'd appreciate any thoughts about this issue. > Maybe your PAM snippet for your app changed the pam_systemd invocation > from "ignore all errors" to "do not ignore errors"? > > PAM varies between distros, on Fedora-based distros lines that ignore > failures in PAM configuration are usually prefixed with a single dash > character. Maybe this was altered for you? > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Upgrade 232 -> 233: user@XXX.service: Failed at step PAM spawning...
Lennart, As I can see pam_systemd is "optional" everywhere in pam.d configuration. Is that what you meant? grep pam_systemd * system-auth:session optionalpam_systemd.so debug systemd-user:session optional pam_systemd.so Regards, Vlad. On 29/04/17 12:21, Lennart Poettering wrote: > On Sat, 29.04.17 11:13, Vlad (vo...@vovan.nl) wrote: > >> Hello, >> >> I've recently updated systemd and now user session is failing to start: >> Apr 29 11:04:02 xxx systemd[550]: user@xxx.service: Failed at step PAM >> spawning /usr/lib/systemd/systemd: Operation not permitted >> Apr 29 11:04:02 xxx systemd[1]: Failed to start User Manager for UID xxx. >> Apr 29 11:04:02 xxx lightdm[535]: pam_systemd(lightdm:session): Failed >> to create session: Start job for unit user@xxx.service failed with 'failed' >> >> Apparently the previous version gives similar error as well, but doesn't >> fail to start user session: >> Apr 29 11:09:37 xxx systemd[565]: user@xxx.service: Failed at step PAM >> spawning /usr/lib/systemd/systemd: Operation not permitted >> Apr 29 11:09:37 xxx systemd[1]: Started User Manager for UID xxx. >> >> I'd appreciate any thoughts about this issue. > Maybe your PAM snippet for your app changed the pam_systemd invocation > from "ignore all errors" to "do not ignore errors"? > > PAM varies between distros, on Fedora-based distros lines that ignore > failures in PAM configuration are usually prefixed with a single dash > character. Maybe this was altered for you? > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Upgrade 232 -> 233: user@XXX.service: Failed at step PAM spawning...
Hello, I've recently updated systemd and now user session is failing to start: Apr 29 11:04:02 xxx systemd[550]: user@xxx.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted Apr 29 11:04:02 xxx systemd[1]: Failed to start User Manager for UID xxx. Apr 29 11:04:02 xxx lightdm[535]: pam_systemd(lightdm:session): Failed to create session: Start job for unit user@xxx.service failed with 'failed' Apparently the previous version gives similar error as well, but doesn't fail to start user session: Apr 29 11:09:37 xxx systemd[565]: user@xxx.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted Apr 29 11:09:37 xxx systemd[1]: Started User Manager for UID xxx. I'd appreciate any thoughts about this issue. Regards, Vlad. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] backlight service stopped at boot
Unfortunately with systemd-227 the behaviour hasn't been changed. Vladimir. On 21/10/15 13:26, Vlad wrote: > Thanks for the explanation. I'll try 227 asap. > > Vladimir. > > On 20/10/15 12:19, Lennart Poettering wrote: >> On Tue, 20.10.15 08:21, Vlad (vo...@vovan.nl) wrote: >> >>> Hello, >>> >>> On my laptop the backlight service is stopped at boot instead of starting: >>> >>> # journalctl -a -b | grep backl >>> Oct 20 08:13:09 *** systemd[1]: Stopped Load/Save Screen Backlight >>> Brightness of backlight:intel_backlight. >>> Oct 20 08:13:09 *** systemd[1]: Removed slice >>> system-systemd\x2dbacklight.slice. >>> >>> However I can start/stop service manually and the backlight is properly >>> restored/saved in /var/lib/systemd/backlight/pci... >>> >>> I'd appreciate any ideas (running systemd-226). >> Most likely you have an rfkill device that appears and the disappears, >> possibly because a firmware rfkill device is replaced by a >> driver-level one. >> >> Either way, in 227 the code around this has changed quite a bit, the >> service is now a singleton and works quite differently. It's now >> started each time an rfkill event happens, and then exits after a few >> seconds. We precisely made this change to deal better with rfkill >> devices that appear only temporarily. >> >> Lennart >> > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-227: ForwardDelaySec
Hello, It looks like the ForwardDelaySec sets the bridge parameter in milliseconds instead of seconds: - in de *.netdev [Bridge] ForwardDelaySec=1 - brctl showstp br0 ... forward delay 0.01 bridge forward delay 0.01 ... I might be wrong, but anyway it would be nice to double check... Regards, Vlad. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] backlight service stopped at boot
Thanks for the explanation. I'll try 227 asap. Vladimir. On 20/10/15 12:19, Lennart Poettering wrote: > On Tue, 20.10.15 08:21, Vlad (vo...@vovan.nl) wrote: > >> Hello, >> >> On my laptop the backlight service is stopped at boot instead of starting: >> >> # journalctl -a -b | grep backl >> Oct 20 08:13:09 *** systemd[1]: Stopped Load/Save Screen Backlight >> Brightness of backlight:intel_backlight. >> Oct 20 08:13:09 *** systemd[1]: Removed slice >> system-systemd\x2dbacklight.slice. >> >> However I can start/stop service manually and the backlight is properly >> restored/saved in /var/lib/systemd/backlight/pci... >> >> I'd appreciate any ideas (running systemd-226). > Most likely you have an rfkill device that appears and the disappears, > possibly because a firmware rfkill device is replaced by a > driver-level one. > > Either way, in 227 the code around this has changed quite a bit, the > service is now a singleton and works quite differently. It's now > started each time an rfkill event happens, and then exits after a few > seconds. We precisely made this change to deal better with rfkill > devices that appear only temporarily. > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] backlight service stopped at boot
Hello, On my laptop the backlight service is stopped at boot instead of starting: # journalctl -a -b | grep backl Oct 20 08:13:09 *** systemd[1]: Stopped Load/Save Screen Backlight Brightness of backlight:intel_backlight. Oct 20 08:13:09 *** systemd[1]: Removed slice system-systemd\x2dbacklight.slice. However I can start/stop service manually and the backlight is properly restored/saved in /var/lib/systemd/backlight/pci... I'd appreciate any ideas (running systemd-226). Regards, Vlad. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to get rid of this ordering cycle?
Hi again, Thank you all, removing dbus from the prerequisites did the trick. No more ordering cycles and mintsystem still runs fine. It turned out that mintsystem didn't even require dbus to work. Must be a copy-paste mistake (from some other init script) by the author... As for the adjustments themselves, I personally don't like these modifications too, but I'm really not in the position to decide whether to keep them in Mint or not. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to get rid of this ordering cycle?
Hi, I have Debian Testing running with some additional packages from Linux Mint which are installed for testing purposes. One of them is mintsystem, which causes an ordering cycle during the boot: авг 14 13:51:06 jessica systemd[1]: Found ordering cycle on basic.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on sysinit.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on dbus.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on basic.target/start авг 14 13:51:06 jessica systemd[1]: Breaking ordering cycle by deleting job mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Job mintsystem.service/start deleted to break ordering cycle starting with basic.target/start The init script in mintsystem package is /etc/init.d/mintsystem. Here's its contents: #! /bin/sh ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO /usr/lib/linuxmint/mintSystem/mint-adjust.py I'd like to know: what can I change in this script to get rid of the ordering cycle? Thanks in advance. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
