process org.freedesktop.systemd1 exited with status 1 #5247
Comments
soloturn
changed the title
|
this suggests you aren't actually running dbus from the systemd --user instance... |
poettering
added
the
needs-reporter-feedback ❓
|
I am having the exact same issue as above. Has anyone found a solution to this yet? |
|
lennart, what do you mean with your comment, resp what do you want me to do? i am following what florian müllner suggested here: https://bugzilla.gnome.org/show_bug.cgi?id=774774 |
|
@soloturn well, is "systemctl --user dbus.service" showing that the user dbus is running as user service off systemd --user? |
|
to add, i was starting gnome wayland for quite a while like this, and there was no systemd error. it showed up recently - i.e. in the last weeks. $ systemctl --user dbus.service $ systemctl --user | grep loaded $ cat /etc/pam.d/system-login | grep systemd i saw: |
Sorry, I meant "systemctl --user status dbus.service"... |
|
it says, entered into a gnome terminal: would you be able to describe how it is supposed to be, or where this can go wrong? i boot, i log in on text tty, then start gnome as my user with "XDG_SESSION_TYPE=wayland dbus-run-session gnome-session". |
|
I just had the same symptoms with Gnome not starting on Arch and the problem was resolved by installing 'nvidia' package instead of 'nvidia-340xx-utils'. |
|
nbdsp, do you start it on a command line or you have gdm running? |
|
I have exactly the same symptoms when starting GNOME with |
|
this one does not seem related but i am putting it here in case there is a relation i cannot see. when i do not log in on the command line but put the command into bash_profile, starting falls into an endless loop, "cannot initialise inotify" and then "dbus-run-session ignoring unknown child process ...". i opened a bug here: for the inotify i did something in the lines of: |
|
I met both issues as well. I suspect that the endless loop issue is caused by the if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && [[ -z $XDG_SESSION_TYPE ]]
then XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
fi |
|
I can reproduce this bug too with Arch using systemd 232 and dbus 1.10.18. After running XDG_SESSION_TYPE=wayland dbus-run-session gnome-session Dbus user service is running fine: Loaded: loaded (/usr/lib/systemd/user/dbus.service; static; vendor preset: enabled)
Active: active (running) since Tue 2017-04-25 17:10:50 MSK; 18h ago
Docs: man:dbus-daemon(1)
Main PID: 1029 (dbus-daemon)
CGroup: /user.slice/user-1000.slice/user@1000.service/dbus.service
└─1029 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation``` |
|
I am hit by this too since Arch updated to GNOME 3.24 a few days ago. GDM appears to be unable to start a Wayland-based GNOME session and falls back to Xorg, that's why I started investigating. I only got rid of the GNOME Xorg session a few weeks ago. Now my desktop is again insecure, and the activities overview lags again, it owns :-/ It was so smooth when running in Wayland mode |
|
@eomanis I believe that's a situation worse than some of us here. In my case, I saw those messages, but GNOME session works fine. Same for @raindev. In you case GNOME session can't even start under Wayland, right (neither from GDM nor from terminal)? And I'm wondering why this issue is still labeled with "needs-reporter-feedback" although @soloturn has already replied a month ago. Maybe there are way too many issues in the queue (over 600 now). |
|
@FranklinYu is there a temporary solution or workaround for this? I cannot now start my wayland Gnome DE and it's the only DE on my Arch installation. |
|
This seems to be an issue with the way the user session is started on arch, i.e. not something that we can solve here. Please move this discussion to the arch bugtracker. (Also, if somebody could later paste a link, for the sake of other people encountering this issue, that'd be appreciated.) |
keszybz
added
not-our-bug
and removed
needs-reporter-feedback ❓
|
@BinaryHexer It shouldn't stop GNOME from being started. Are you trying to start GNOME from GDM or from terminal? Or you tried both? |
|
@FranklinYu terminal. This is the script I am using |
|
@BinaryHexer I assume that the script is neither |
|
@FranklinYu yes, correct assumption. It has worked in the past without any problems, I don't know what happened. |
|
@BinaryHexer Then how about simply XDG_SESSION_TYPE=wayland dbus-run-session gnome-sessionin log-in shell session? (Note the absence of |
|
@FranklinYu, sorry I've missed your previous mention.
Actually, that's not the case: I still can successfully Stuart GNOME session both from tty and using GDM. |
|
@FranklinYu thanks for helping me, but has the same result as before. I can't figure out how to fix this. |
|
On Archlinux, I've enabled |
|
This is not just an arch problem. Im having the same issue on my raspberry pi too now. |
|
$ systemctl --user start vino System was taken to runlevel 3 and then to 5. |
|
@poettering the error message meanwhile slightly changed, this is the nohop file after starting gnome on the command line and then immeditaely press "logout". |
|
I'm also encountering this issue on Nixos... Anyone else? |
|
https://serverfault.com/a/887298/135542
|
|
Not here. some dbus process is not properly started in the init 3/init 5 circus. |
|
Also not working for me on Manjaro |
|
Not working on Arch today (Freshly installed |
|
Issue on Debian
(related: #16180) Resolved by installing package dbus-user-session. Didn't research security impact yet. |
|
I don't really know either where to report it, or if it is a bug or not. However, it seems the problem is with the DBus service file, located both in As a result, when DBus tries to activate it, Anyone can tell us more information on this? |
|
Found the file in the repository with a simple search: src/core/org.freedesktop.systemd1.service Maybe this issue should be reopened? |
I'm not sure if this should be an issue or not as well. However, I only have a problem when I go to boot older installed kernels even if it was just working and I install a new kernel. This error shows up and gnome fails to start. I feel like people may not be on the right track here. Despite this, I can get it to boot into gnome desktop if I use an empty xorg.conf but that breaks the latest kernel so I haven't been able to win but only just looking here and there into it. There's a rather big disconnect there as to the actual thing that's happening compared to this log entry we all see. Probably doesn't clear anything up for you but might as well with more questions possibly. Errors in logs aren't necessarily anything at all. I can put "errors" in logs all day long and they are just for development feedback or something is wrong and not necessarily what we think it might be. It could be best to look at it from another angle. Oh, also if I switch to open source driver from removing the block on kernel command line during boot, that's another "fix" for my situation. |
|
Thanks for your reply. Maybe I didn't get you well, however, personally I think errors and even warnings should not be ignored. Yes, the issue may gone away by some magic tricks, but that doesn't necessarily mean that is the reason. We may find correct issues from unrelated ones as well. The current issue might be an unrelated one, so I would open a new one on this after ensuring it doesn't already exist. |
|
Why on earth are we letting systemd run This has been a source of confusion for my particular issue for a while now, since it's one of only 2 errors that I see and it seemed to be the only one that could explain anything. Now that I see that it doesn't explain anything because it's supposedly some fake error for no reason, my particular issue is even more confusing. So since 2019, this .service file tries to launch and is |
|
Well, the problem is more complicated than that. What starts a service in a system at boot time? Obviously Systemd. What if the service itself is Systemd (i.e. As far as I know, the sole purpose of the |
|
Obviously interactions with systemd are not possible this way. Whatever's trying to interact with it and getting |
|
I read the introduction and did a page-search for |
@AlexFolland, this is what you said. |
|
I ran into this issue. I was trying to solve the following error which occurs when launching Flatpaks (My main goal has been getting Sway and Flatpak working smoothly together). Some flatpaks have this error after startup: $ flatpak run md.obsidian.Obsidian
[3 preload-host-spawn-strategy] Running: /app/bin/zypak-helper child - /app/obsidian --type=zygote
[3 preload-host-spawn-strategy] Failed to call Spawn: org.freedesktop.DBus.Error.InvalidArgs: Could not find requesting pidAfter logout, others have this error $ flatpak run com.visualstudio.code
[2 zypak-helper] Failed to connect to session bus: [org.freedesktop.DBus.Error.NotSupported] Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead
[2 zypak-helper] src/helper/main.cc:40(DetermineZygoteStrategy): Assertion failed: busFollowing the suggestions in another thread, I added this to my profile to try to give DBUS a if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
# Sets the session bus address and another thing:
export $(dbus-launch)
export NSS_USE_SHARED_DB=ENABLED
fiWhile that solved the issue of flatpaks not opening, it causes this error. $ systemctl --user status pipewire
Failed to get properties: Process org.freedesktop.systemd1 exited with status 1Which obviously impacts a lot of things :) It seems I can only have one of the two things working correctly, until I figure out a solution! Thought I'd post to get more mentions of the issue in the search index. Will update if I find anything. |
|
I am affected by this ubuntu problem: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491 where something is going wrong with systemd when starting a remote session via in my case nomachine, but other users report problems with vcn and x2go. All these start a session. Snaps don't start because they can't interact as expected with the user dbus, it seems. in particular:
|
|
I'm seeing something similar as @noahtallen when I open vscode. Not sure what the fix is. |
|
In my case, either I can fix this with I have no clue why this env var is needed, why it was not set, or why it doesn't use the "obvious" default of the current login. |
for me even this doesn't fix this anymore.... UPDATE: This was my issue: https://bugs.launchpad.net/ubuntu/+bug/2017496 |
and others
Submission type
systemd version the issue has been seen with
NOTE: Do not submit bug reports about anything but the two most recently released systemd versions upstream!
Used distribution
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: