Bug#922647: Info received (Bug#922647: systemd --user no longer running)
I tried the fix_db.pl script, there was no output. Here is the only relevant difference: --- debconf.old/config.dat▸-2019-03-10 18:43:37.265483165 +0100 +++ debconf/config.dat▸-2019-03-10 18:43:41.261085496 +0100 @@ -1151,7 +1151,7 @@ Name: libpam-modules/disable-screensaver Template: libpam-modules/disable-screensaver -Owners: libpam-modules +Owners: libpam-modules, libpam-modules:amd64 Name: libpam-runtime/conflicts Template: libpam-runtime/conflicts Other differences are only label translations for libraries/restart-without-asking in templates. -- Julien Leproust
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
On Sat, Mar 09, 2019 at 08:25:50PM +0100, Michael Biebl wrote: > [bringing Steve, our pam maintainer, into the loop] > Hi Steve, > the following looks like an issue in pam-auth-update and similar to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923362 > Any idea what might be going wrong there? If it's the same as bug #923362, note that this bug was closed as invalid as the user had a corrupt debconf database that was somehow causing the wrong information to be returned to pam-auth-update. So it's quite possible this is a latent debconf database corruption problem on end users' systems, which is only tickled now as a result of there being a new upstream version of pam causing pam debconf prompts for the first time in a few years. I would suggest taking a snapshot of /var/cache/debconf, then running /usr/share/debconf/fix_db.pl as the submitter of the other bug did, then diffing to see what has changed if anything. > Am 09.03.19 um 19:55 schrieb Julien Leproust: > > Hi, > > > > Well we're in luck, I have etckeeper installed since 2012. > > > > On both machines, I never edited /etc/pam.d/common-* manually. > > > > * fc3256a - Sat, 9 Mar 2019 12:59:20 +0100 (7 hours ago) (HEAD -> master) > > | daily autocommit - root > > * efc0d23 - Thu, 7 Feb 2019 23:16:46 +0100 (4 weeks ago) > > | committing changes in /etc made by "aptitude" - root > > * 6d1fbcf - Tue, 20 Feb 2018 22:51:34 +0100 (1 year, 1 month ago) > > | committing changes in /etc after apt run - root > > * 72d4029 - Tue, 19 Apr 2016 22:00:51 +0200 (2 years, 11 months ago) > > | committing changes in /etc after apt run - root > > * 50f69ee - Sat, 1 Mar 2014 15:33:33 +0100 (5 years ago) > > | committing changes in /etc after apt run - root > > * dee824f - Sat, 4 Aug 2012 10:55:33 +0200 (7 years ago) > > Initial commit - root > > > > The modification today is the fix using pam-auth-update. > > > > The last modification, which broke pam_systemd.so, was triggered by > > libpam-cap:amd64 (1:2.25-2). The update triggered pam-auth-update, and > > /var/log/apt/term.log shows the choices I made: > > > > ┤ PAM configuration ├─── > > Pluggable Authentication Modules (PAM) determine how authentication, > > authorization, and password changing are handled on the system, as > > well as allowing configuration of additional actions to take when > > starting user sessions. > > > > Some PAM module packages provide profiles that can be used to > > automatically adjust the behavior of all PAM-using applications on > > the system. Please indicate which of these behaviors you wish to > > enable. > > > > PAM profiles to enable: > > > > [*] Unix authentication > > [*] Register user sessions in the systemd control group ... > > [ ] Create home directory on login > > [*] GNOME Keyring Daemon - Login keyring management > > [*] Inheritable Capabilities Management > > > > > > > > > > > > > > And then, pam_systemd.so was incorrectly removed? I'm sure you're going > > to assume I disabled the second option, but I really doubt this. > > > > Previous modifications: > > - 20 Feb 2018: removal of libpam-ck-connector > > - 19 Apr 2016: installation of libpam-cgfs > > - 1 Mar 2014: installation of libpam-systemd > > > > Initial state for reference in August 2012: > > === > > # > > # /etc/pam.d/common-session - session-related modules common to all > > services > > # > > # This file is included from other service-specific PAM config files, > > # and should contain a list of modules that define tasks to be performed > > # at the start and end of sessions of *any* kind (both interactive and > > # non-interactive). > > # > > # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. > > # To take advantage of this, it is recommended that you configure any > > # local modules either before or after the default block, and use > > # pam-auth-update to manage selection of other modules. See > > # pam-auth-update(8) for details. > > > > # here are the per-package modules (the "Primary" block) > > session [default=1] pam_permit.so > > # here's the fallback if no module succeeds > > session requisite pam_deny.so > > # prime the stack with a positive return value if there isn't one already; > > # this avoids us returning an error just because nothing sets a success > > code > > # since the modules above will each just jump around > > session required pam_permit.so > > # and here are more per-package modules (the "Additional" block) > > session required pam_unix.so > > session optional pam_systemd.so > > session optional pam_ck_connector.so nox11 > > # end of pam-auth-update config > >
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Am 09.03.19 um 22:03 schrieb Julien Leproust: > Indeed, it looks a lot like #923362, though I can't reproduce now by > manually running dpkg-reconfigure libpam-runtime. > > Tell me if I can help debug this, I still have the full apt logs and > etckeeper on two machines. > Sorry, can't really help you with pam-auth-update/libpam-runtime. Hopefully Steve can help here. We should probably reassign this issue. But before doing that, I wanted confirmation from Eduard that his original issue is the same as yours. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Indeed, it looks a lot like #923362, though I can't reproduce now by manually running dpkg-reconfigure libpam-runtime. Tell me if I can help debug this, I still have the full apt logs and etckeeper on two machines. Anyway I learnt a lot about pam and systemd :-) Best regards, -- Julien Leproust
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
[bringing Steve, our pam maintainer, into the loop] Hi Steve, the following looks like an issue in pam-auth-update and similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923362 Any idea what might be going wrong there? Am 09.03.19 um 19:55 schrieb Julien Leproust: > Hi, > > Well we're in luck, I have etckeeper installed since 2012. > > On both machines, I never edited /etc/pam.d/common-* manually. > > * fc3256a - Sat, 9 Mar 2019 12:59:20 +0100 (7 hours ago) (HEAD -> master) > | daily autocommit - root > * efc0d23 - Thu, 7 Feb 2019 23:16:46 +0100 (4 weeks ago) > | committing changes in /etc made by "aptitude" - root > * 6d1fbcf - Tue, 20 Feb 2018 22:51:34 +0100 (1 year, 1 month ago) > | committing changes in /etc after apt run - root > * 72d4029 - Tue, 19 Apr 2016 22:00:51 +0200 (2 years, 11 months ago) > | committing changes in /etc after apt run - root > * 50f69ee - Sat, 1 Mar 2014 15:33:33 +0100 (5 years ago) > | committing changes in /etc after apt run - root > * dee824f - Sat, 4 Aug 2012 10:55:33 +0200 (7 years ago) > Initial commit - root > > The modification today is the fix using pam-auth-update. > > The last modification, which broke pam_systemd.so, was triggered by > libpam-cap:amd64 (1:2.25-2). The update triggered pam-auth-update, and > /var/log/apt/term.log shows the choices I made: > > ┤ PAM configuration ├─── > Pluggable Authentication Modules (PAM) determine how authentication, > authorization, and password changing are handled on the system, as > well as allowing configuration of additional actions to take when > starting user sessions. > > Some PAM module packages provide profiles that can be used to > automatically adjust the behavior of all PAM-using applications on > the system. Please indicate which of these behaviors you wish to > enable. > > PAM profiles to enable: > > [*] Unix authentication > [*] Register user sessions in the systemd control group ... > [ ] Create home directory on login > [*] GNOME Keyring Daemon - Login keyring management > [*] Inheritable Capabilities Management > > > > > > > And then, pam_systemd.so was incorrectly removed? I'm sure you're going > to assume I disabled the second option, but I really doubt this. > > Previous modifications: > - 20 Feb 2018: removal of libpam-ck-connector > - 19 Apr 2016: installation of libpam-cgfs > - 1 Mar 2014: installation of libpam-systemd > > Initial state for reference in August 2012: > === > # > # /etc/pam.d/common-session - session-related modules common to all > services > # > # This file is included from other service-specific PAM config files, > # and should contain a list of modules that define tasks to be performed > # at the start and end of sessions of *any* kind (both interactive and > # non-interactive). > # > # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. > # To take advantage of this, it is recommended that you configure any > # local modules either before or after the default block, and use > # pam-auth-update to manage selection of other modules. See > # pam-auth-update(8) for details. > > # here are the per-package modules (the "Primary" block) > session [default=1] pam_permit.so > # here's the fallback if no module succeeds > session requisite pam_deny.so > # prime the stack with a positive return value if there isn't one already; > # this avoids us returning an error just because nothing sets a success > code > # since the modules above will each just jump around > session required pam_permit.so > # and here are more per-package modules (the "Additional" block) > session required pam_unix.so > session optional pam_systemd.so > session optional pam_ck_connector.so nox11 > # end of pam-auth-update config > === > > And today: > === > # > # /etc/pam.d/common-session - session-related modules common to all > services > # > # This file is included from other service-specific PAM config files, > # and should contain a list of modules that define tasks to be performed > # at the start and end of sessions of *any* kind (both interactive and > # non-interactive). > # > # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. > # To take advantage of this, it is recommended that you configure any > # local modules either before or after the default block, and use > # pam-auth-update to manage selection of other modules. See > # pam-auth-update(8) for details. > > # here are the per-package modules (the "Primary" block) > session [default=1]
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Am 09.03.19 um 20:17 schrieb Michael Biebl: > Thanks for the follow-up information. > That was really helpful. > > Am 09.03.19 um 19:55 schrieb Julien Leproust: >> And then, pam_systemd.so was incorrectly removed? I'm sure you're going >> to assume I disabled the second option, but I really doubt this. > > I said, a manual modification is more likely then a bug in > pam-auth-update. I didn't say pam-auth-update is bug free :-) > > This does indeed look like a bug in pam-auth-update. > So I want trawling the pam bug tracker a bit. > Looks like you might have been bitten by > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923362 > It looks suspiciously close to your issue. Eduard, can you confirm that pam_systemd.so is missing from your /etc/pam.d/common-session? Otherwise, the problem seen by Julien is different from yours, and we should handle those cases separately in their own bug reports. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Thanks for the follow-up information. That was really helpful. Am 09.03.19 um 19:55 schrieb Julien Leproust: > And then, pam_systemd.so was incorrectly removed? I'm sure you're going > to assume I disabled the second option, but I really doubt this. I said, a manual modification is more likely then a bug in pam-auth-update. I didn't say pam-auth-update is bug free :-) This does indeed look like a bug in pam-auth-update. So I want trawling the pam bug tracker a bit. Looks like you might have been bitten by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923362 It looks suspiciously close to your issue. Unfortunately this bug report was closed without a solution. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Hi, Well we're in luck, I have etckeeper installed since 2012. On both machines, I never edited /etc/pam.d/common-* manually. * fc3256a - Sat, 9 Mar 2019 12:59:20 +0100 (7 hours ago) (HEAD -> master) | daily autocommit - root * efc0d23 - Thu, 7 Feb 2019 23:16:46 +0100 (4 weeks ago) | committing changes in /etc made by "aptitude" - root * 6d1fbcf - Tue, 20 Feb 2018 22:51:34 +0100 (1 year, 1 month ago) | committing changes in /etc after apt run - root * 72d4029 - Tue, 19 Apr 2016 22:00:51 +0200 (2 years, 11 months ago) | committing changes in /etc after apt run - root * 50f69ee - Sat, 1 Mar 2014 15:33:33 +0100 (5 years ago) | committing changes in /etc after apt run - root * dee824f - Sat, 4 Aug 2012 10:55:33 +0200 (7 years ago) Initial commit - root The modification today is the fix using pam-auth-update. The last modification, which broke pam_systemd.so, was triggered by libpam-cap:amd64 (1:2.25-2). The update triggered pam-auth-update, and /var/log/apt/term.log shows the choices I made: ┤ PAM configuration ├─── Pluggable Authentication Modules (PAM) determine how authentication, authorization, and password changing are handled on the system, as well as allowing configuration of additional actions to take when starting user sessions. Some PAM module packages provide profiles that can be used to automatically adjust the behavior of all PAM-using applications on the system. Please indicate which of these behaviors you wish to enable. PAM profiles to enable: [*] Unix authentication [*] Register user sessions in the systemd control group ... [ ] Create home directory on login [*] GNOME Keyring Daemon - Login keyring management [*] Inheritable Capabilities Management And then, pam_systemd.so was incorrectly removed? I'm sure you're going to assume I disabled the second option, but I really doubt this. Previous modifications: - 20 Feb 2018: removal of libpam-ck-connector - 19 Apr 2016: installation of libpam-cgfs - 1 Mar 2014: installation of libpam-systemd Initial state for reference in August 2012: === # # /etc/pam.d/common-session - session-related modules common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of modules that define tasks to be performed # at the start and end of sessions of *any* kind (both interactive and # non-interactive). # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) session [default=1] pam_permit.so # here's the fallback if no module succeeds session requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around session requiredpam_permit.so # and here are more per-package modules (the "Additional" block) session requiredpam_unix.so session optionalpam_systemd.so session optionalpam_ck_connector.so nox11 # end of pam-auth-update config === And today: === # # /etc/pam.d/common-session - session-related modules common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of modules that define tasks to be performed # at the start and end of sessions of *any* kind (both interactive and # non-interactive). # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) session [default=1] pam_permit.so # here's the fallback if no module succeeds session requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around session requiredpam_permit.so # and here are more per-package modules (the "Additional" block) session
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Am 09.03.19 um 15:00 schrieb Michael Biebl: > Am 09.03.19 um 14:10 schrieb Julien Leproust: >> Hi, >> >> I found the issue. >> >> When looking for /etc files not belonging to any package, I discovered >> that /etc/pam.d/common-* files are managed by pam-auth-update. >> >> Most pam profiles were enabled, except "Register user sessions in the >> systemd control group hierarchy", and just enabling it fixed the >> problem. The systemd user service and logind session are now correctly >> started and everything works fine (device permissions, pulseaudio, etc). >> >> The real issue becomes why this pam profile got disabled in the first >> place. > > libpam-systemd uses pam-auth-update as documented. > There is no code in the libpam-systemd package which disables/removes > pam_systemd.so. > > So either you have at some point modified /etc/pam.d/common-* yourself > or there is a bug in pam-auth-update. > > If I had to guess, the former is more likely. Afaik, if at some point in the past you have modified /etc/pam.d/common-* manually and you then install libpam-systemd, pam-auth-update will preserve your local changes and not add pam_systemd.so. Are you absolutely sure, pam_systemd.so was enabled in the past and at some point suddenly removed from /etc/pam.d/common-session? Or is it more likely that pam_systemd.so was never enabled? If pam_systemd.so was suddenly disabled, can you pin this to a certain event, like files being restored from a backup? In case, there is not really something we can do about this in the libpam-systemd package. As said, it does not actively remove pam_systemd.so. What we might do is to include the contents of /etc/pam.d/common-session in the bug report (via a libpam-systemd bugscript) to make issues like this easier to spot in the future. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Am 09.03.19 um 14:10 schrieb Julien Leproust: > Hi, > > I found the issue. > > When looking for /etc files not belonging to any package, I discovered > that /etc/pam.d/common-* files are managed by pam-auth-update. > > Most pam profiles were enabled, except "Register user sessions in the > systemd control group hierarchy", and just enabling it fixed the > problem. The systemd user service and logind session are now correctly > started and everything works fine (device permissions, pulseaudio, etc). > > The real issue becomes why this pam profile got disabled in the first > place. libpam-systemd uses pam-auth-update as documented. There is no code in the libpam-systemd package which disables/removes pam_systemd.so. So either you have at some point modified /etc/pam.d/common-* yourself or there is a bug in pam-auth-update. If I had to guess, the former is more likely. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#922647: Info received (Bug#922647: systemd --user no longer running)
Hi, I found the issue. When looking for /etc files not belonging to any package, I discovered that /etc/pam.d/common-* files are managed by pam-auth-update. Most pam profiles were enabled, except "Register user sessions in the systemd control group hierarchy", and just enabling it fixed the problem. The systemd user service and logind session are now correctly started and everything works fine (device permissions, pulseaudio, etc). The real issue becomes why this pam profile got disabled in the first place. Thanks everyone for your help. Best regards, -- Julien Leproust
Bug#922647: systemd --user no longer running
On 3/7/19 1:21 AM, Felipe Sateler wrot It is libpam-ck-connector I have no such package, neither installed nor available. -- Julien Leproust
Bug#922647: systemd --user no longer running
On Wed, Mar 6, 2019, 21:19 Julien Leproust wrote: > On 3/7/19 1:14 AM, Felipe Sateler wrote: > > It seems yo still have pam ck connector installed. Can you confirm? > > I don't know, how do I check this? The only package I find referring > consolekit is lightdm, in its description. > It is libpam-ck-connector Saludos
Bug#922647: systemd --user no longer running
On Wed, Mar 6, 2019, 21:03 Julien Leproust wrote: > Yes, I do have dbus-user-session and dbus-x11 installed: > > $ apt-cache policy dbus-user-session dbus-x11 > dbus-user-session: >Installed: 1.12.12-1 >Candidate: 1.12.12-1 >Version table: > 1.13.8-1 1 >1 http://ftp.fr.debian.org/debian experimental/main amd64 > Packages > *** 1.12.12-1 500 > 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages > 100 /var/lib/dpkg/status > dbus-x11: >Installed: 1.12.12-1 >Candidate: 1.12.12-1 >Version table: > 1.13.8-1 1 >1 http://ftp.fr.debian.org/debian experimental/main amd64 > Packages > *** 1.12.12-1 500 > 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages > 100 /var/lib/dpkg/status > > > On the other affected machine, dbus-user-session is installed but > dbus-x11 isn't. > > I have experimental repositories configured but I don't use them currently. > > > On Wed, 6 Mar 2019 19:35:42 -0300 Felipe Sateler > wrote:> So, #923881 gives one reason why systemd --user might fail. Is your > > home directory set to a non-absolute path? > > No, my home is the standard /home/julien. > > > What could be helpful, is to provide the full journal from around the > > time you login. There should be something there signalling why your > > user instance is not starting. > > > > ANother thing, easier to test, is to try to launch the user manager: > > `systemctl start user@$UID` . Does that work? > > Indeed, this works. I hadn't thought to try this. > > -- Logs begin at Fri 2019-03-01 10:13:47 CET, end at Thu 2019-03-07 > 00:44:16 CET. -- > Mar 07 00:40:20 treize systemd[1]: Starting User Manager for UID 1000... > Mar 07 00:40:20 treize systemd[30137]: pam_unix(systemd-user:session): > session opened for user julien by (uid=0) > Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic > agent and passphrase cache. > Mar 07 00:40:20 treize systemd[30137]: Reached target Paths. > Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic > agent and passphrase cache (access for web browsers). > Mar 07 00:40:20 treize systemd[30137]: Listening on Sound System. > Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG network > certificate management daemon. > Mar 07 00:40:20 treize systemd[30137]: Starting D-Bus User Message Bus > Socket. > Mar 07 00:40:20 treize systemd[30137]: Reached target Timers. > Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic > agent (ssh-agent emulation). > Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic > agent and passphrase cache (restricted). > Mar 07 00:40:20 treize systemd[30137]: Listening on D-Bus User Message > Bus Socket. > Mar 07 00:40:20 treize systemd[30137]: Reached target Sockets. > Mar 07 00:40:20 treize systemd[30137]: Reached target Basic System. > Mar 07 00:40:20 treize systemd[30137]: Reached target Default. > Mar 07 00:40:20 treize systemd[30137]: Startup finished in 65ms. > Mar 07 00:40:20 treize systemd[1]: Started User Manager for UID 1000. > > This creates /run/user/1000: > $ ls -al /run/user/1000 > total 0 > drwx-- 5 julien julien 120 Mar 7 00:40 ./ > drwxr-xr-x 4 root root80 Mar 7 00:40 ../ > srw-rw-rw- 1 julien julien 0 Mar 7 00:40 bus= > drwx-- 2 julien julien 140 Mar 7 00:40 gnupg/ > drwxr-xr-x 2 julien julien 60 Mar 7 00:40 pulse/ > drwxr-xr-x 2 julien julien 80 Mar 7 00:40 systemd/ > > Here is the lightdm journal on one of the machines where it is > configured with autologin and kodi-standalone session: > -- Subject: A start job for unit lightdm.service has begun execution > -- A start job for unit lightdm.service has begun execution. > -- Subject: A start job for unit lightdm.service has finished successfully > -- A start job for unit lightdm.service has finished successfully. > Mar 07 00:50:32 totoro lightdm[1008]: > pam_unix(lightdm-autologin:session): session opened for user julien by > (uid=0) > Mar 07 00:50:32 totoro lightdm[1008]: Failed to open CK session: > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.freedesktop.ConsoleKit was not provided by any .service files > It seems yo still have pam ck connector installed. Can you confirm? Saludos
Bug#922647: systemd --user no longer running
Yes, I do have dbus-user-session and dbus-x11 installed: $ apt-cache policy dbus-user-session dbus-x11 dbus-user-session: Installed: 1.12.12-1 Candidate: 1.12.12-1 Version table: 1.13.8-1 1 1 http://ftp.fr.debian.org/debian experimental/main amd64 Packages *** 1.12.12-1 500 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status dbus-x11: Installed: 1.12.12-1 Candidate: 1.12.12-1 Version table: 1.13.8-1 1 1 http://ftp.fr.debian.org/debian experimental/main amd64 Packages *** 1.12.12-1 500 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status On the other affected machine, dbus-user-session is installed but dbus-x11 isn't. I have experimental repositories configured but I don't use them currently. On Wed, 6 Mar 2019 19:35:42 -0300 Felipe Sateler wrote:> So, #923881 gives one reason why systemd --user might fail. Is your home directory set to a non-absolute path? No, my home is the standard /home/julien. What could be helpful, is to provide the full journal from around the time you login. There should be something there signalling why your user instance is not starting. ANother thing, easier to test, is to try to launch the user manager: `systemctl start user@$UID` . Does that work? Indeed, this works. I hadn't thought to try this. -- Logs begin at Fri 2019-03-01 10:13:47 CET, end at Thu 2019-03-07 00:44:16 CET. -- Mar 07 00:40:20 treize systemd[1]: Starting User Manager for UID 1000... Mar 07 00:40:20 treize systemd[30137]: pam_unix(systemd-user:session): session opened for user julien by (uid=0) Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic agent and passphrase cache. Mar 07 00:40:20 treize systemd[30137]: Reached target Paths. Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers). Mar 07 00:40:20 treize systemd[30137]: Listening on Sound System. Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG network certificate management daemon. Mar 07 00:40:20 treize systemd[30137]: Starting D-Bus User Message Bus Socket. Mar 07 00:40:20 treize systemd[30137]: Reached target Timers. Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic agent (ssh-agent emulation). Mar 07 00:40:20 treize systemd[30137]: Listening on GnuPG cryptographic agent and passphrase cache (restricted). Mar 07 00:40:20 treize systemd[30137]: Listening on D-Bus User Message Bus Socket. Mar 07 00:40:20 treize systemd[30137]: Reached target Sockets. Mar 07 00:40:20 treize systemd[30137]: Reached target Basic System. Mar 07 00:40:20 treize systemd[30137]: Reached target Default. Mar 07 00:40:20 treize systemd[30137]: Startup finished in 65ms. Mar 07 00:40:20 treize systemd[1]: Started User Manager for UID 1000. This creates /run/user/1000: $ ls -al /run/user/1000 total 0 drwx-- 5 julien julien 120 Mar 7 00:40 ./ drwxr-xr-x 4 root root80 Mar 7 00:40 ../ srw-rw-rw- 1 julien julien 0 Mar 7 00:40 bus= drwx-- 2 julien julien 140 Mar 7 00:40 gnupg/ drwxr-xr-x 2 julien julien 60 Mar 7 00:40 pulse/ drwxr-xr-x 2 julien julien 80 Mar 7 00:40 systemd/ Here is the lightdm journal on one of the machines where it is configured with autologin and kodi-standalone session: -- Subject: A start job for unit lightdm.service has begun execution -- A start job for unit lightdm.service has begun execution. -- Subject: A start job for unit lightdm.service has finished successfully -- A start job for unit lightdm.service has finished successfully. Mar 07 00:50:32 totoro lightdm[1008]: pam_unix(lightdm-autologin:session): session opened for user julien by (uid=0) Mar 07 00:50:32 totoro lightdm[1008]: Failed to open CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files I can paste you the whole boot journal but I don't see anything interesting. dbus-daemon and systemd-user-sessions start successfully. I see no error at all except the lightdm one above. Thanks a lot. -- Julien Leproust
Bug#922647: systemd --user no longer running
To rule out the obvious, can you paste the output of apt-cache policy dbus-user-session dbus-x11 (you want dbus-user-session if you are using systemd --user) -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#922647: systemd --user no longer running
On Wed, Mar 6, 2019 at 6:09 PM Julien Leproust wrote: > > Hi, > > I've been hit by seemingly the same bug on two of my machines. > > Since about mid-February, I noticed that my two Debian sid desktops no > longer produced any sound. On one of them, I use lightdm+mate, on the > other I use lightdm+kodi. Both were updated roughly weekly, with only > official sid repositories. > > I quickly found out that the sound was broken because pulseaudio was not > starting, having no permission to access the sound devices. In turn, I > found that this permission should have been granted through dbus and > systemd --user, which were both absent from the process list. > > Same symptoms for both machine: > $ systemctl --user status > Failed to read server status: Process org.freedesktop.systemd1 exited > with status 1 > > Last systemd user logs were from a boot mid-january when sound still > worked. Absolutely no logs since then, just like for Eduard (I tried all > the suggestions above). So, #923881 gives one reason why systemd --user might fail. Is your home directory set to a non-absolute path? What could be helpful, is to provide the full journal from around the time you login. There should be something there signalling why your user instance is not starting. ANother thing, easier to test, is to try to launch the user manager: `systemctl start user@$UID` . Does that work? -- Saludos, Felipe Sateler
Bug#922647: systemd --user no longer running
Hi, I've been hit by seemingly the same bug on two of my machines. Since about mid-February, I noticed that my two Debian sid desktops no longer produced any sound. On one of them, I use lightdm+mate, on the other I use lightdm+kodi. Both were updated roughly weekly, with only official sid repositories. I quickly found out that the sound was broken because pulseaudio was not starting, having no permission to access the sound devices. In turn, I found that this permission should have been granted through dbus and systemd --user, which were both absent from the process list. Same symptoms for both machine: $ systemctl --user status Failed to read server status: Process org.freedesktop.systemd1 exited with status 1 Last systemd user logs were from a boot mid-january when sound still worked. Absolutely no logs since then, just like for Eduard (I tried all the suggestions above). systemd --user does not start at all from the user session. loginctl shows only the lightdm session, not the real user one: $ loginctl SESSION UID USERSEAT TTY c3 135 lightdm seat0 I have the same systemd error as Eduard when starting it manually: $ systemd --user Trying to run as user instance, but $XDG_RUNTIME_DIR is not set. XDG_RUNTIME_DIR and XDG_SESSION_ID are both unset in my environment. $ env|grep XDG XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_VTNR=7 XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/julien XDG_SESSION_DESKTOP=mate XDG_DATA_DIRS=/usr/share/mate:/usr/local/share/:/usr/share/ XDG_SESSION_TYPE=x11 XDG_CURRENT_DESKTOP=MATE XDG_SEAT=seat0 XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 I tried logging in as a brand new user with an empty home directory, the problem is reproduced. I tried replacing lightdm with sddm, and mate-session with cinnamon or gnome, all fail the same way. I tried installing a brand new VM with lightdm and mate-session, everything works fine. I can notice a difference with dbus though. On my broken machine: $ env|grep DBUS DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-UqLtmoksoq,guid=ffcd65719a7135c063ccc9a15c6f26c9 On my working VM: env|grep DBUS DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus I can see a related change in systemd 241: * $DBUS_SESSION_BUS_ADDRESS environment variable is set by pam_systemd again. /run/user/1000 does not exist on my broken machine. On the working machine, XDG_RUNTIME_DIR is /run/user/1000 and exists and is populated. On one of my broken machines, /run/user is empty, and on the other it only contains an entry for the lightdm user: $ ls -al /run/user/135 ls: cannot access '/run/user/135/gvfs': Permission denied total 0 drwx-- 8 lightdm lightdm 180 Feb 26 19:52 ./ drwxr-xr-x 3 rootroot 60 Feb 26 19:52 ../ srw-rw-rw- 1 lightdm lightdm 0 Feb 26 19:52 bus= drwx-- 3 lightdm lightdm 60 Feb 26 19:52 dbus-1/ drwx-- 2 lightdm lightdm 60 Feb 26 19:52 dconf/ drwx-- 2 lightdm lightdm 140 Feb 26 19:52 gnupg/ d? ? ? ? ?? gvfs/ drwxr-xr-x 2 lightdm lightdm 60 Feb 26 19:52 pulse/ drwxr-xr-x 2 lightdm lightdm 80 Feb 26 19:52 systemd/ Is there anything else I can check in this direction? I guess the problem must come from some system configuration on both of my machines, maybe some old file in /etc. debsums -ce shows only modifications to files from completely unrelated packages (libvirt, grub). My next idea would be to try to purge and reinstall most systemd packages, but it will be tricky on a live system. Does anyone have any other idea to test short of reinstalling? Thanks in advance for your help. Best regards -- Julien Leproust
Bug#922647: systemd --user no longer running
On Mon, Feb 25, 2019 at 3:12 PM Eduard Bloch wrote: > Control: reassign -1 systemd > > Hallo, > * Felipe Sateler [Thu, Feb 21 2019, 10:32:29AM]: > >On Wed, Feb 20, 2019 at 3:59 PM Eduard Bloch <[1]e...@gmx.de> wrote: > > Feb 08 20:38:51 zombie at-spi-bus-launcher[2625]: XIO: fatal IO > error > > 11 (Resource temporarily unavailable) on X server ":0" > > Feb 08 20:38:51 zombie at-spi-bus-launcher[2625]: after 3713 > > requests (3713 known processed) with 0 events remaining. > > Feb 08 20:38:51 zombie systemd[2391]: run-rpc_pipefs.mount: > Succeeded. > > Feb 08 20:38:51 zombie systemd[1]: Stopping User Manager for UID > 500... > > > >This is suspiciously close to the previous messages, which suggest the > >ones left out are still relevant (ie, why did systemd decide to stop > your > >user manager). > > That were all recent log messages it did create in the last days before > the problem has started. The system is rebooted regularly... so I guess > there is a natural reason for stopping it? > Please post full logs. If you don't know what you are looking for, then your editing might remove important information. Please do the following: start from a fresh boot, wait until the user manager has exited, and then get the full boot log with `sudo journalctl -b`, and attach that fully. > Anyhow, in the meantime I made some more experiments, forcing "systemd > --user" with XDG_RUNTIME_DIR set and observing what has happened or is > happening. This is strange. You don't have XDG_RUNTIME_DIR set automatically? > Really weird things. I upgraded systemd to the latest sid > version and it's still adding up. Immediately after login in lightdm, I > can check the pstree and I see an active "systemd --user" process there and > a few services started from there, like gpg agent but that's only about > a half of what I would expect, especially "pulseaudio" is not started. > When I run journalctl --unit user@500.service -b0 at that moment, it > displays "No entries". > > When I check the same a couple of minutes later, the "systemd --user" > process and the whole process subtree are gone. Vanished without any > trace (when checking with journalctl --unit, as above) and still getting > "no entries". > > Now I check the main log at the time where the weird process mass > extinction happened, and see something like the following. > > Feb 25 18:48:06 zombie NetworkManager[958]: [1551116886.6200] > agent-manager: req[0x563871361240, :1.76/org.freedesktop.nm-applet/500]: > agent registered > Feb 25 18:48:15 zombie systemd[1]: NetworkManager-dispatcher.service: > Succeeded. > Feb 25 18:48:15 zombie systemd[1]: Stopping User Manager for UID 160... > This is not your uid, so this is not relevant to us. > > Anyhow, I have enough of this. > I get that you are frustrated, but please vent elsewhere. Reading this doesn't precisely make me want to spend mi little debian time debugging this issue. -- Saludos, Felipe Sateler
Bug#922647: systemd --user no longer running
Control: reassign -1 systemd Hallo, * Felipe Sateler [Thu, Feb 21 2019, 10:32:29AM]: >On Wed, Feb 20, 2019 at 3:59 PM Eduard Bloch <[1]e...@gmx.de> wrote: > Feb 08 20:38:51 zombie at-spi-bus-launcher[2625]: XIO: fatal IO error > 11 (Resource temporarily unavailable) on X server ":0" > Feb 08 20:38:51 zombie at-spi-bus-launcher[2625]: after 3713 > requests (3713 known processed) with 0 events remaining. > Feb 08 20:38:51 zombie systemd[2391]: run-rpc_pipefs.mount: Succeeded. > Feb 08 20:38:51 zombie systemd[1]: Stopping User Manager for UID 500... > >This is suspiciously close to the previous messages, which suggest the >ones left out are still relevant (ie, why did systemd decide to stop your >user manager). That were all recent log messages it did create in the last days before the problem has started. The system is rebooted regularly... so I guess there is a natural reason for stopping it? Anyhow, in the meantime I made some more experiments, forcing "systemd --user" with XDG_RUNTIME_DIR set and observing what has happened or is happening. Really weird things. I upgraded systemd to the latest sid version and it's still adding up. Immediately after login in lightdm, I can check the pstree and I see an active "systemd --user" process there and a few services started from there, like gpg agent but that's only about a half of what I would expect, especially "pulseaudio" is not started. When I run journalctl --unit user@500.service -b0 at that moment, it displays "No entries". When I check the same a couple of minutes later, the "systemd --user" process and the whole process subtree are gone. Vanished without any trace (when checking with journalctl --unit, as above) and still getting "no entries". Now I check the main log at the time where the weird process mass extinction happened, and see something like the following. Feb 25 18:48:06 zombie NetworkManager[958]: [1551116886.6200] agent-manager: req[0x563871361240, :1.76/org.freedesktop.nm-applet/500]: agent registered Feb 25 18:48:15 zombie systemd[1]: NetworkManager-dispatcher.service: Succeeded. Feb 25 18:48:15 zombie systemd[1]: Stopping User Manager for UID 160... Feb 25 18:48:15 zombie systemd[1567]: Stopping Virtual filesystem service... Feb 25 18:48:15 zombie systemd[1567]: Stopped target Default. Feb 25 18:48:15 zombie systemd[1567]: Stopping Accessibility services bus... Feb 25 18:48:15 zombie systemd[1567]: Stopping D-Bus User Message Bus... Feb 25 18:48:15 zombie systemd[1567]: gvfs-daemon.service: Main process exited, code=killed, status=15/TERM Feb 25 18:48:15 zombie systemd[1567]: dbus.service: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Stopped D-Bus User Message Bus. Feb 25 18:48:15 zombie systemd[1567]: at-spi-dbus-bus.service: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Stopped Accessibility services bus. Feb 25 18:48:15 zombie systemd[1]: run-user-160-gvfs.mount: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: run-user-160-gvfs.mount: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: gvfs-daemon.service: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Stopped Virtual filesystem service. Feb 25 18:48:15 zombie systemd[1567]: Stopped target Basic System. Feb 25 18:48:15 zombie systemd[1567]: Stopped target Sockets. Feb 25 18:48:15 zombie systemd[1567]: pulseaudio.socket: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Closed Sound System. Feb 25 18:48:15 zombie systemd[1567]: gpg-agent-ssh.socket: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Closed GnuPG cryptographic agent (ssh-agent emulation). Feb 25 18:48:15 zombie systemd[1567]: gpg-agent-browser.socket: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers). Feb 25 18:48:15 zombie systemd[1567]: gpg-agent.socket: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Closed GnuPG cryptographic agent and passphrase cache. Feb 25 18:48:15 zombie systemd[1567]: dirmngr.socket: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Closed GnuPG network certificate management daemon. Feb 25 18:48:15 zombie systemd[1567]: gpg-agent-extra.socket: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Closed GnuPG cryptographic agent and passphrase cache (restricted). Feb 25 18:48:15 zombie systemd[1567]: dbus.socket: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Closed D-Bus User Message Bus Socket. Feb 25 18:48:15 zombie systemd[1567]: Stopped target Paths. Feb 25 18:48:15 zombie systemd[1567]: Reached target Shutdown. Feb 25 18:48:15 zombie systemd[1567]: systemd-exit.service: Succeeded. Feb 25 18:48:15 zombie systemd[1567]: Started Exit the Session. Feb 25 18:48:15 zombie systemd[1567]: Reached target Exit the Session. Feb 25 18:48:15 zombie systemd[1567]: Stopped target Timers. Feb 25 18:48:15 zombie systemd[1568]: pam_unix(systemd-user:session): session closed for user lightdm Feb 25 18:48:15 zombie systemd[1]: user@160.service: Succeeded.
Bug#922647: systemd --user no longer running
On Wed, Feb 20, 2019 at 3:59 PM Eduard Bloch wrote: > Hallo, > * Felipe Sateler [Wed, Feb 20 2019, 02:46:32PM]: > > > Yeah, so I tried also real username instead of "user" here, etc. > still > > getting "invalid argument" message. Which IMHO makes sense since, as > > said, the systemd user instance was not started. > > > >Use journalctl --unit user@500.service. you may need root. > >Also, journalctl -b -p0..3 might give relevant error messages > > Thanks, see below. -p0..3 show "No entries" or nothing particularly > interesting (some wrong .service file syntax from Christmas time). > > It seems to be not user specific, another user has the same problem - no > running "systemd --user" after login. > > Most recent: > > Feb 08 20:38:51 zombie at-spi-bus-launcher[2625]: XIO: fatal IO error 11 > (Resource temporarily unavailable) on X server ":0" > Feb 08 20:38:51 zombie at-spi-bus-launcher[2625]: after 3713 > requests (3713 known processed) with 0 events remaining. > Feb 08 20:38:51 zombie systemd[2391]: run-rpc_pipefs.mount: Succeeded. > Feb 08 20:38:51 zombie systemd[1]: Stopping User Manager for UID 500... > This is suspiciously close to the previous messages, which suggest the ones left out are still relevant (ie, why did systemd decide to stop your user manager). -- Saludos, Felipe Sateler
Bug#922647: systemd --user no longer running
Hallo, * Felipe Sateler [Wed, Feb 20 2019, 02:46:32PM]: > Yeah, so I tried also real username instead of "user" here, etc. still > getting "invalid argument" message. Which IMHO makes sense since, as > said, the systemd user instance was not started. > >Use journalctl --unit user@500.service. you may need root. >Also, journalctl -b -p0..3 might give relevant error messages Thanks, see below. -p0..3 show "No entries" or nothing particularly interesting (some wrong .service file syntax from Christmas time). It seems to be not user specific, another user has the same problem - no running "systemd --user" after login. Most recent: Feb 08 20:38:51 zombie at-spi-bus-launcher[2625]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" Feb 08 20:38:51 zombie at-spi-bus-launcher[2625]: after 3713 requests (3713 known processed) with 0 events remaining. Feb 08 20:38:51 zombie systemd[2391]: run-rpc_pipefs.mount: Succeeded. Feb 08 20:38:51 zombie systemd[1]: Stopping User Manager for UID 500... Feb 08 20:38:51 zombie systemd[2391]: Stopping Virtual filesystem service... Feb 08 20:38:51 zombie systemd[2391]: Stopping Accessibility services bus... Feb 08 20:38:51 zombie systemd[2391]: Stopping D-Bus User Message Bus... Feb 08 20:38:51 zombie systemd[2391]: Stopping Sound Service... Feb 08 20:38:51 zombie systemd[2391]: Stopped target Default. Feb 08 20:38:51 zombie systemd[2391]: gvfs-daemon.service: Main process exited, code=killed, status=15/TERM Feb 08 20:38:51 zombie systemd[2391]: run-user-500-gvfs.mount: Succeeded. Feb 08 20:38:51 zombie systemd[2391]: dbus.service: Succeeded. Feb 08 20:38:51 zombie systemd[2391]: Stopped D-Bus User Message Bus. Feb 08 20:38:51 zombie systemd[2391]: at-spi-dbus-bus.service: Succeeded. Feb 08 20:38:51 zombie systemd[2391]: Stopped Accessibility services bus. Feb 08 20:38:51 zombie systemd[2391]: gvfs-daemon.service: Succeeded. Feb 08 20:38:51 zombie systemd[2391]: Stopped Virtual filesystem service. Feb 08 20:38:52 zombie systemd[2391]: pulseaudio.service: Succeeded. Feb 08 20:38:52 zombie systemd[2391]: Stopped Sound Service. Feb 08 20:38:52 zombie systemd[2391]: Stopped target Basic System. Feb 08 20:38:52 zombie systemd[2391]: Stopped target Paths. Feb 08 20:38:52 zombie systemd[2391]: Stopped target Timers. Feb 08 20:38:52 zombie systemd[2391]: Stopped target Sockets. Feb 08 20:38:52 zombie systemd[2391]: gpg-agent.socket: Succeeded. Feb 08 20:38:52 zombie systemd[2391]: Closed GnuPG cryptographic agent and passphrase cache. Feb 08 20:38:52 zombie systemd[2391]: dirmngr.socket: Succeeded. Feb 08 20:38:52 zombie systemd[2391]: Closed GnuPG network certificate management daemon. Feb 08 20:38:52 zombie systemd[2391]: gpg-agent-ssh.socket: Succeeded. Feb 08 20:38:52 zombie systemd[2391]: Closed GnuPG cryptographic agent (ssh-agent emulation). Feb 08 20:38:52 zombie systemd[2391]: gpg-agent-extra.socket: Succeeded. Feb 08 20:38:52 zombie systemd[2391]: Closed GnuPG cryptographic agent and passphrase cache (restricted). Feb 08 20:38:52 zombie systemd[2391]: dbus.socket: Succeeded. Feb 08 20:38:52 zombie systemd[2391]: Closed D-Bus User Message Bus Socket. Feb 08 20:38:52 zombie systemd[2391]: gpg-agent-browser.socket: Succeeded. Feb 08 20:38:52 zombie systemd[2391]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers). Feb 08 20:38:52 zombie systemd[2391]: pulseaudio.socket: Succeeded. Feb 08 20:38:52 zombie systemd[2391]: Closed Sound System. Feb 08 20:38:52 zombie systemd[2391]: Reached target Shutdown. Feb 08 20:38:52 zombie systemd[2391]: systemd-exit.service: Succeeded. Feb 08 20:38:52 zombie systemd[2391]: Started Exit the Session. Feb 08 20:38:52 zombie systemd[2391]: Reached target Exit the Session. Feb 08 20:38:52 zombie systemd[2398]: pam_unix(systemd-user:session): session closed for user ... (anonymized) Feb 08 20:38:52 zombie systemd[1]: user@500.service: Succeeded. Feb 08 20:38:52 zombie systemd[1]: Stopped User Manager for UID 500. -p3: -- Reboot -- Dez 25 14:12:36 zombie systemd[7020]: /usr/lib/systemd/user/systemd-exit.service:16: Failed to parse failure action specifier, ignoring: exit-force Dez 25 14:12:36 zombie systemd[7020]: systemd-exit.service: Service lacks both ExecStart= and ExecStop= setting. Refusing. Dez 25 14:12:36 zombie systemd[7020]: Failed to enqueue exit.target job: Unit systemd-exit.service has a bad unit file setting. Best regards, Eduard.
Bug#922647: systemd --user no longer running
On Wed, Feb 20, 2019, 14:25 Eduard Bloch Hallo, > * Felipe Sateler [Mon, Feb 18 2019, 06:34:37PM]: > >Control: tags -1 moreinfo > >On Mon, Feb 18, 2019 at 5:36 PM Eduard Bloch <[1]e...@gmx.de> wrote: > > > > Package: libpam-systemd > > Version: 240-5 > > Severity: normal > > > > Hi, > > > > a few days ago some user services started failed - I mainly noticed > that > > pulseaudio was no longer available. > > This looked very strange, and while checking other systems, I saw > that > > "systemd --user" is not launched, which would have started pa and > some > > other user-session daemons. > > > >Please get the logs of user@$youruid.service. It is possible a user > unit > >is timing out, and thus failing the user manager. > > Please imagine that I, as plain user here, have no idea how to map your > suggestion to something I shall actually run, and the documentation > is partly crappy from usability POV. So trying around... > > $ systemctl --user status > Failed to read server status: Process org.freedesktop.systemd1 exited with > status 1 > $ journalctl --user > No journal files were found. > -- No entries -- > $ sudo journalctl user@$UID.service > ... > Failed to add match 'user@500.service': Das Argument ist ungültig > > Yeah, so I tried also real username instead of "user" here, etc. still > getting "invalid argument" message. Which IMHO makes sense since, as > said, the systemd user instance was not started. > Use journalctl --unit user@500.service. you may need root. Also, journalctl -b -p0..3 might give relevant error messages Saludos, Felipe Sateler
Bug#922647: systemd --user no longer running
Hallo, * Felipe Sateler [Mon, Feb 18 2019, 06:34:37PM]: >Control: tags -1 moreinfo >On Mon, Feb 18, 2019 at 5:36 PM Eduard Bloch <[1]e...@gmx.de> wrote: > > Package: libpam-systemd > Version: 240-5 > Severity: normal > > Hi, > > a few days ago some user services started failed - I mainly noticed that > pulseaudio was no longer available. > This looked very strange, and while checking other systems, I saw that > "systemd --user" is not launched, which would have started pa and some > other user-session daemons. > >Please get the logs of user@$youruid.service. It is possible a user unit >is timing out, and thus failing the user manager. Please imagine that I, as plain user here, have no idea how to map your suggestion to something I shall actually run, and the documentation is partly crappy from usability POV. So trying around... $ systemctl --user status Failed to read server status: Process org.freedesktop.systemd1 exited with status 1 $ journalctl --user No journal files were found. -- No entries -- $ sudo journalctl user@$UID.service ... Failed to add match 'user@500.service': Das Argument ist ungültig Yeah, so I tried also real username instead of "user" here, etc. still getting "invalid argument" message. Which IMHO makes sense since, as said, the systemd user instance was not started. Regards, Eduard.
Bug#922647: systemd --user no longer running
Control: tags -1 moreinfo On Mon, Feb 18, 2019 at 5:36 PM Eduard Bloch wrote: > Package: libpam-systemd > Version: 240-5 > Severity: normal > > Hi, > > a few days ago some user services started failed - I mainly noticed that > pulseaudio was no longer available. > This looked very strange, and while checking other systems, I saw that > "systemd --user" is not launched, which would have started pa and some > other user-session daemons. > Please get the logs of user@$youruid.service. It is possible a user unit is timing out, and thus failing the user manager. -- Saludos, Felipe Sateler
Bug#922647: systemd --user no longer running
Package: libpam-systemd Version: 240-5 Severity: normal Hi, a few days ago some user services started failed - I mainly noticed that pulseaudio was no longer available. This looked very strange, and while checking other systems, I saw that "systemd --user" is not launched, which would have started pa and some other user-session daemons. So I started looking around, what "systemd --user" doing and how it is started? Here, the first issue emerges. The manual explains --user but a) does not tell you who/what is supposed to run this b) in case you run systemd --user manually, it aborts with "Trying to run as user instance, but $XDG_RUNTIME_DIR is not set." This does not help me at all - how shall a user guess where it's coming from and how this is required for --user? There is NO explanation or hint in the manpage. Ok, so I guess that it must be some special thing triggered by login. Which probably means pam. So I found libpam-systemd by looking through the package list. And the manpage is interesting. But nothing tells me what might be going wrong when the thing is NOT spawning systemd--user. So I checked a few hints in the "SEE ALSO" section, like logind.conf(5), and still nothing tells me how to debug a problem where systemd --user is not run. I checked the journal, and still cannot find much about/from PAM there. And the only matches for /login/ are: | Feb 18 19:54:58 zombie systemd[1]: Condition check resulted in getty on tty2-tty6 if dbus and logind are not available being skipped. This phrase I not understand. Missing a comma somewhere? Missing some background explanation for regular users? Is this my problem and if yes, what to do about it? The rest looks harmless: | Feb 18 19:54:58 zombie systemd-logind[996]: New seat seat0. | Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on /dev/input/event9 (Power Button) | Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on /dev/input/event8 (Power Button) | Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on /dev/input/event0 (Microsoft Natural® Ergonomic Keyboard 4000) | Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on /dev/input/event1 (Microsoft Natural® Ergonomic Keyboard 4000) | Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on /dev/input/event2 (A4TECH USB Device Keyboard) | Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on /dev/input/event3 (A4TECH USB Device System Control) | Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on /dev/input/event4 (A4TECH USB Device Consumer Control) | Feb 18 19:55:00 zombie systemd-logind[996]: New session c1 of user lightdm. | Feb 18 19:55:09 zombie systemd-logind[996]: Removed session c1. Still does not tell me much if I don't know what to look for. There are no exceptions/error/hints which would look somehow linked to login sequence problems. Any ideas? NOTE: this issue might be related to #921687 because it started at approximately the same time. Best regards, Eduard. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.7 (SMP w/12 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-systemd depends on: ii dbus1.12.12-1 ii libc6 2.28-7 ii libpam-runtime 1.3.1-5 ii libpam0g1.3.1-5 ii systemd 240-5 ii systemd-sysv240-5 libpam-systemd recommends no packages. libpam-systemd suggests no packages. -- no debconf information
