Description of problem: When upgrading F31 to F32 using system-upgrade I notice that user services are allowed to start and run. Version-Release number of selected component (if applicable): Fedora 32 How reproducible: I have not tried. Steps to Reproduce: 1. Configure a user service 2. Set the user to linger 3. system upgrade from F31 to F32 Actual results: User services are starting at the same time as DNF is doing the system upgrade. This is seen clearly in the journal logs. Expected results: Only services that must be run to support the system-upgrade are run. Additional info:
The system did not reboot after DNF completed installing all RPMs.
Here is a log extract showing the user sessions starting up while DNF is running: 2020-04-29T21:43:08+0100 dnf[1083]: Running scriptlet: filesystem-3.14-2.fc32.x86_64 1/1 2020-04-29T21:43:08+0100 dnf[1083]: Running scriptlet: copy-jdk-configs-3.7-5.fc32.noarch 1/1 2020-04-29T21:43:08+0100 audit[1112]: USER_ACCT pid=1112 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="alex" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 2020-04-29T21:43:08+0100 kernel: audit: type=1101 audit(1588192988.619:133): pid=1112 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="alex" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 2020-04-29T21:43:08+0100 audit[1113]: USER_ACCT pid=1113 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="barry-mail" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 2020-04-29T21:43:08+0100 audit[1110]: USER_ACCT pid=1110 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="barry" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 2020-04-29T21:43:08+0100 systemd[1110]: pam_unix(systemd-user:session): session opened for user barry by (uid=0) 2020-04-29T21:43:08+0100 audit[1110]: USER_START pid=1110 uid=0 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_selinux,pam_selinux,pam_loginuid,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="barry" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 2020-04-29T21:43:08+0100 audit: AUDIT1334 prog-id=32 op=LOAD 2020-04-29T21:43:08+0100 audit: AUDIT1334 prog-id=32 op=UNLOAD 2020-04-29T21:43:08+0100 audit: AUDIT1334 prog-id=33 op=LOAD 2020-04-29T21:43:08+0100 audit: AUDIT1334 prog-id=33 op=UNLOAD 2020-04-29T21:43:08+0100 audit: AUDIT1334 prog-id=34 op=LOAD 2020-04-29T21:43:08+0100 audit: AUDIT1334 prog-id=34 op=UNLOAD 2020-04-29T21:43:08+0100 systemd[1112]: /home/barry/.config/systemd/user/default.target:1: .include directives are deprecated, and support for them will be removed in a future version of systemd. Please use drop-in files instead.
I have seen this problem on a second system hich has user systemd services fail to reboot as well. Three systems I upgraded that do not have user services rebooted as expected.
DNF/RPM are just executing what's in the scriptlets. Assigning to systemd for investigation if this behavior is expected and to check the rpm macros eventually.
The logs do not support your claim. The logs show code that I wrote on my machine is running as a user service. That code is not in a RPM script.
Barry, I don't see anything in that log that would look particularly wrong. Please provide a reproduction procedure and describe clearly *which* services were started and when and why you didn't expect that. The fact that *some* user services are running (esp. with linger set) by itself is not a bug. Also please attach the full log, that snipped is nearly not enough to say anything useful.
Of cource its a bug that user services are running during a system upgrade. If you think it is fine to have user services running why not system services like samba, httpd etc? I'l email you about setting up a call to discuss this.
Let me try putting it a different way. The systemd target that does the upgrade only includes the services that are necessary to do the upgrade. The systemd user services cannot possible be necessary to do an upgrade in a controlled target. Barry
Oh, OK, you were using dnf system-upgrade and you mean that the user services are running in the offline upgrade mode. I missed that bit. This indeed doesn't sound right. Can you attach the full log from the upgrade? It seems something is pulling in systemd-logind.service during the upgrade...
Created attachment 1702993 [details] log of off line system upgrade showing logind and user services running Here is the full log of the system upgrade from the journal. It does not show a reboot as it hangs. But you can see the user services having problems with hosts.
Do you have an update on this bug?
Does Fedora have pam_nologin in the "systemd-user" PAM stack? (The upstream version doesn't, but not sure what the packaged version does. — Too lazy to check myself, I have the systemd upstream version self-compiled installed over the packaged version).
Nope: $ cat /etc/pam.d/systemd-user # This file is part of systemd. # # Used by systemd --user instances. account include system-auth session required pam_selinux.so close session required pam_selinux.so nottys open session required pam_loginuid.so session include system-auth
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I pushed to 34 as I am assuming this is not fixed.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
We discussed adding support for a more flexible pam_systemd module. Something like a switch in the pam_systemd config line that specifies if the user manager should be started it it wasn't running yet (yes, no, auto?). For things like cron sessions, it'd be "no". It might But for this particular issue, I think we want a more direct solution. logind should just not starting lingering users. (And in addition, maybe we could avoid starting logind altogether…).