"pam_systemd(login:session): Failed to create session: Connection timed out" on boot (pam_systemd should use a much longer timeout for the OpenSession bus call, since it starts the --user systemd instance which might block for a long time) #2863
Comments
|
this suggests there's a problem with dbus/logind, so that pam_systemd can't properly communicate with logind. Do you see anything relevant in the logs regarding this? |
poettering
added
login
needs-reporter-feedback ❓
|
I'm having a similar problem, I also use systemd version 229, login takes a long time and sometimes user@ service fails |
|
There is a simple way to reproduce the problem or a similar one. I am running an up to date Arch Linux for x86_64 with systemd 230. I ran into the problem with profile-sync-daemon (psd), which currently takes slightly more than 25 seconds to start on my computer. Without psd the problem can be reproduced as follows:
Then the journal contains something like: The I see nothing about
|
Yes, this is default timeout for D-Bus calls in sd-bus library. pam_systemd calls into logind via D-Bus and hits timeout. It is not clear whether logind session must wait for user instance to complete launch. After all, user instance is entirely optional and may not even exist. |
|
I could reproduce the delay in this way on Arch Linux (systemd 231-4) in a QEMU VM: (ttyS0 has journalctl running, just logged in to ttyS0). In tty1, invoke: (observe a long delay here) Somehow |
Is there a way to configure it in runtime?
Currently it looks like single "bad" (takes more than 25s to start) unit kills entire user session which is definitely wrong. Even if unit is somewhat misbehaving (which is not the case - even 1min startup should not be an issue) it should have no affect on anything except the unit and its dependencies. |
|
This is still present on systemd 232-6 on Arch x86_64 and thoroughly breaks desktop user sessions that rely on DBus. |
|
So why does this still need reporter feedback? I can reproduce the problem with the provided |
|
Took me hours to figure out what was causing my pam_systemd to time out and consequently any Is there a way to make it not wait for instances to start up? |
Do you still need any info from me? I think the issue has pretty much been identified. |
poettering
removed
the
needs-reporter-feedback ❓
poettering
changed the title
|
systemctl list-unit-files --user :( ye.. I can't precisely for the above reasons ,p but ok, if one has identified an update breaks one of the user files, at least I can figure this out. I got fed up with a lot of these systemd things (mainly arch , not systemd per se), so haven't bothered digging too much. Just moved on. addendum. what seems like a total meltdown of the old system , was down to a simple user service.. wow. In my case it was a gpg and/or ssh agent user service. |
|
I have here a similar issue with postgresql systemd 233 |
|
I had a similar issue involving a user service running upon login which requires 45 sec or so to complete. In my case (where nothing else depends on my user service) I was able to resolve the issue by changing the service type from "oneshot" to "simple." I suspect this is related to the documented difference that for a oneshot service "it is expected that the process has to exit before systemd starts follow-up units" whereas for a simple service "systemd will immediately proceed starting follow-up units" but this is only a guess. |
|
Same here on debian testing with systemd 234. I can't login into gnome after my laptop has been in suspend to RAM (happens randomly). Does anybody know what's going on here? |
Saw this issue while trying to install
Okay, but in a world where people are increasingly relying on the user instance... |
|
@sphaugh I've found that dunst works better when called from the WM's init/rc file, at least for me where I use it in Window Maker or Fluxbox. |
|
I'm getting this problem, but apparently not on a user session, but on It delays my first SSH session after boot for 25 seconds. See NixOS/nixpkgs#30348 for details. Is there a way to at least reduce this timeout as a temporary workaround? |
|
Possibly related?
Edit: Using dbus |
To answer some of this myself:
Now, the above is probably obvious for somebody familiar with systemd code, but a more interesting question is: Should this path even be taken when there's no |
|
Another suspicion: It might be an entropy issue (tip from @cleverca22):
And a corresponding issue in systemd:
|
Hmm, I suspect it had crashed? I do have a dbus service set up and on another reboot it's also back in |
|
Here's a journalctl output for sshd and dbus with debugging enabled, with dbus https://gist.github.com/nh2/80a57f08b6ee61754bfb52c1d0cee82e |
|
Am I supposed to see a It is absent. |
When a user logs in, systemd-pam will wait for the user manager instance to report readiness. We don't need to wait for all the jobs to finish, it is enough if the basic startup is done and the user manager is responsive. systemd --user will now send out two READY=1 notifications: - once with status "Reached basic.target" - and later the normal one with "Startup finished in ..." I think this is OK. Also fixes systemd#2863.
|
OK, I've investigated a bit more now. I found that the problem would only appear when I had an When I turned that entry to an equivalent Do you have any idea why this could be? Also, @keszybz do the investigations for your patch linked above explain this, or would they potentially hide this error source if it's a different one? Also, I have a NixOS+nixops based deployment here that can reliably reproduce this bug. If a systemd developer would find that useful, I can show how to rund it, or set up a deployment and provide login to it. |
|
@nh2 your |
When a user logs in, systemd-pam will wait for the user manager instance to report readiness. We don't need to wait for all the jobs to finish, it is enough if the basic startup is done and the user manager is responsive. systemd --user will now send out a READY=1 notification when either of two conditions becomes true: - basic.target/start job is gone, - the initial transaction is done. Also fixes systemd#2863.
When a user logs in, systemd-pam will wait for the user manager instance to report readiness. We don't need to wait for all the jobs to finish, it is enough if the basic startup is done and the user manager is responsive. systemd --user will now send out a READY=1 notification when either of two conditions becomes true: - basic.target/start job is gone, - the initial transaction is done. Also fixes systemd#2863.
|
@fsateler You're right about the typo (result of improper cleanup before pushing), but it doesn't make a difference (in fact nixops wouldn't let me deploy this with the typo, it points it out with I've fixed the typo now (updated commit), the problem (commit before) and fix (the commit) remain (I have retested it right now, with this setup it takes me only 5 minutes to reproduce). |
…ed (#7102) When a user logs in, systemd-pam will wait for the user manager instance to report readiness. We don't need to wait for all the jobs to finish, it is enough if the basic startup is done and the user manager is responsive. systemd --user will now send out a READY=1 notification when either of two conditions becomes true: - basic.target/start job is gone, - the initial transaction is done. Also fixes #2863.
…ed (systemd#7102) When a user logs in, systemd-pam will wait for the user manager instance to report readiness. We don't need to wait for all the jobs to finish, it is enough if the basic startup is done and the user manager is responsive. systemd --user will now send out a READY=1 notification when either of two conditions becomes true: - basic.target/start job is gone, - the initial transaction is done. Also fixes systemd#2863. (cherry picked from commit 0c2826c) [fbui: adjust context]
…ed (systemd#7102) When a user logs in, systemd-pam will wait for the user manager instance to report readiness. We don't need to wait for all the jobs to finish, it is enough if the basic startup is done and the user manager is responsive. systemd --user will now send out a READY=1 notification when either of two conditions becomes true: - basic.target/start job is gone, - the initial transaction is done. Also fixes systemd#2863. (cherry picked from commit 0c2826c) [fbui: adjust context]
Submission type
systemd version the issue has been seen with
Used distribution
In case of bug report: Expected behaviour you didn't see
In case of bug report: Unexpected behaviour you saw
In case of bug report: Steps to reproduce the problem
The text was updated successfully, but these errors were encountered: