Failed to connect to bus, failed to talk to init daemon

English Install/Boot/Login
1

Hello everyone!

This is a quite recent install of Leap 15.1 from the 4 openSUSE repos only (i.e. oss, oss updates, non-oss, non-oss updates).
All pending updates made today.
I use KDE.
The laptop is of generic brand, some years old with windoze 7, intel core i3, nvidia geforce 310M.

  1. I boot. KDE is running.
  2. I hit Ctrl-Alt-F1 to get a terminal.
  3. Using ‘su’ I log in as root.
  4. Using Ctrl-Alt-F7 I return to KDE desktop.
  5. I open a Dolphin window, and I close it again. At his point, that still works.
  6. I click on the Network Manager Applet in the task bar at the lower boundary of the screen.
  7. I disable WiFi / WLAN (the laptop is connected by cable).
  8. I close the Network Manager popup window that opened from there.
  9. I try to start Dolphin again. I get (translated):
The command can't be executed.
The file or directory
'/home/mydefaultuser/.local/share/plasma_icons/org.kde.dolphin.desktop'
doesn't exist.
  1. I hit Ctrl-Alt-F1, and I get to the terminal where I logged in as root before (root prompt).
  2. I enter
shutdown -h now
  1. I get (not translated, but typed by hand):
Failed to connect to bus: No such file or directory
Failed to talk to init daemon.

I shut down the hard way by pressing the power button for several seconds.

This is repeatable.

Any idea?

2

Yes, I’ve noticed this as well:

  • Active SDDM session – KDE Plasma – on VT7.
  • Active user session – could be “root” or, another user – on VT1 through VT6.

When jumping between CLI Virtual Terminals and the SDDM Virtual Terminal (VT1 … VT6 ←→ VT7), the system freezes …

  • I was pointing a finger at my AMD Chip-Set and Graphic card but, it seems that the Intel/NVIDIA world is also suffering from this issue …

I’m simply waiting for Wayland and some SDDM changes – in the mean time I only begin «and end» VT1 … VT6 sessions when only the SDDM Greeter is running on VT7 …

  • Or, I “isolate” to the systemd multi-user.target, do what ever and then, return the system to the default systemd target …
3

Using wayland???

Not seeing this using X

4

Interesting: already under Leap 15.0, on the very same laptop, I had even worse problems with KDE lock ups and freezes of the system. I then blamed that on NVIDIA, because I never have experienced problems of that kind on intel PCs using processor graphics only (i.e. PCs with no additional video/graphics card), of which I have two.

That may have been wrong, see
https://forums.opensuse.org/showthread.php/534614-Why-does-it-seem-to-be-so-difficult-to-install-Leap-15-on-a-PC-with-NVIDIA-hardware?p=2891926#post2891926
However, arvidjaar didn’t elaborate on that then, and I didn’t ask.

Anyway, after an update not much time after that, the behaviour of Leap 15.0 improved much on that same laptop. I was a bit sceptical and kept on using Leap 42.3 on that laptop.
Now after the end of support for Leap 42.3 I tried a clean install of 15.1, because it will be supported much longer than 15.0.

And the freeze: Yes, yesterday I finally got a freeze of 15.1 when trying to switch back to KDE (VT7) after the shutdown command in VT1 didn’t work anymore.

Usually I don’t jump between the virtual terminals using Ctrl-Alt-F1 / Ctrl-Alt-F7 etc - except that I have a reason.
The reason here was that KDE got locked after using the Network Manager Applet. That finally made it necessary to shut down the laptop the hard way, and that took place already the first time I tried to use the Network Manager Applet.

It was the second try when I first went to VT1 (Ctrl-Alt-F1) and logged in as root before anything else. The reason was that after the lock ups of KDE under Leap 15.0 I never had the chance anymore to log in as root, in order to shut down in a more usual way, because (i) KDE didn’t open Konsole anymore (just like any other application), and (ii) on VT1 trying to log in as root ended up in timeouts.
I didn’t want to end up like that again.
Actually I finally had tried the same under Leap 15.0 already, with similar results, see
https://forums.opensuse.org/showthread.php/533906-Leap-15-0-Console-login-problem?p=2891682#post2891682

So if I hadn’t logged in on VT1 first, then I would not even have seen the error message

The error message of KDE that I obtained before that is striking as well, but it gives less details.

As long as I don’t use the Network Manager Applet on that laptop, things work quite well: usually I boot the system, start firefox, and access the internet. That works. And the shutdown after that works too.
So for me personally it isn’t that urgent to have this fixed - although it’s a bit nasty.
For others, this may look different.

5

Instead of using keyboard keystrokes, try using the “systemctl isolate” command as described in the following article…

https://www.tecmint.com/change-runlevels-targets-in-systemd/

Somewhere a long time ago I remember reading a Poettering blog article (I’m sure it can be found) that described how unlike in SysVinit, in some scenarios systemd runlevels don’t match up exactly with what you’d expect… in other words, there isn’t a fixed relationship. There is an attempt to preserve the associations because it’s what Users expect, but systemd removed the fixed relationship to make more options available and provide some extra flexibility in utilizing resources.

TSU

6

Hi
Reading through this I currently do not see how that could be used to turn off WiFi / WLAN while in KDE.
And when KDE is locked up after trying to turn off WiFi / WLAN using the Network Manager Applet there doesn’t seem to be any possibility to get a working command line where a command like

# systemctl isolate multi-user.target

could be entered.

7

OK,
I didn’t understand the point of your switching runlevels so got side-tracked. And, I still don’t know why you did what you did.
But, if you actually were trying to do something in a text terminal, and had problems connecting to a bus, my recommendation is still there.

Two things you should check…
Whenever you see an error about a missing file, the first thing you should check is if that file actually exists.

Also,
A common cause of “unable to connect to dbus” errors is trying to access something without proper permissions.
I’m not sure why you’re attempting to run NM with root permission, it’s set up to run as the logged in normal User… I haven’t tested running as root but the error is typical of that kind of incorrect use.

As far as turning off your Wifi…
I don’t know that NM can do that, it’s a configuration manager and AFAIK doesn’t manage device on/off(but can configure a start configuration).
For that, you might use a software solution like rfkill or a hardware switch on your laptop.

TSU

8

Hi again!
The problem was (and is) that KDE or the whole system got “locked up” after I disabled WiFi / WLAN using the Network Manager Applet.
I then could not shutdown anymore, because KDE wouldn’t launch anything anymore. I reported the (strange) error message that I get trying to launch Dolphin as a standard user (not root!). Shutdown didn’t work either - for the same (whichever) reasons, I assume.
So the last thing to try for me was to try to get to a working command line. That was the reason to try Ctrl-Alt-F1 in that situation.

Logging in as root at virtual console 1 BEFORE running Network Manager Applet was the only means to do so which I am aware of. Without success at the end of the day, because I got the error messages given in the title of this thread. So a conclusion would be, that not only KDE got bust by using the Network Manager Applet, but the whole system.

Yes, it does!
After a fresh boot, I can open a Dolphin window as default user without any problem, and the file ‘/home/mydefaultuser/.local/share/plasma_icons/org.kde.dolphin.desktop’ is there, I can navigate to it in that Dolphin window.
The error message that this file can’t be found is displayed only after the use of the Network Manager Applet.

I did NOT try to run the Network Manager Applet as root. After boot I’m logged in as standard user by default, without giving a password.
From there on I clicked on the icon of the Network Manager Applet in the task bar.
In older versions of openSUSE up to 42.3 this never caused problems.
However, changing network setup may usually require root privileges at some point that I don’t know, but if, this then is made transparent to the standard user, as a tribute to usability.
All I can say is that it worked for me for years, i.e. on from earlier versions of openSUSE (probably openSUSE 11 or 12) up to Leap 42.

‘rfkill’ would be a good idea, but it can not be installed anymore from the repos for Leap 15!

And I don’t even expect that the Network Manager Applet would switch off the WiFi device.
It would be sufficient to me if the connection by WiFi is disabled in certain situations - which worked for versions of openSUSE older than 15.

Thanks for taking your time
Mike

9

Apparently,
rfkill is now packaged with a new management daemon…
And the package installing the whole thing is now

zypper in urfkill

I see by your explanation what you are trying to do,
Hopefully using rfkill will avoid your problems.

TSU

10

Good to know that!
I once stumbled over rfkill working with another laptop that has a physical switch to disable/enable WiFi/WLAN.
After switching off WiFi/WLAN, in openSUSE WLAN remained disabled even if that switch was used to turn WLAN on again.
rfkill then was the solution.

Installation of urfkill went smoothly.

The bad news is that rfkill doesn’t solve the issue.

I boot the same way as before: KDE, Network Manager.
Using ‘su’ I become root in a terminal.
I enter rfkill to output the current state, result:

# rfkill
ID TYPE DEVICE      SOFT      HARD
 0 wlan phy0   unblocked unblocked
#

Fine, now trying to disable WLAN:

# rfkill block wlan
#

… and check that state, ooooops:

# rfkill
rfkill: cannot open /dev/rfkill: No such file or directory
rfkill: cannot read /dev/rfkill: Bad file descriptor
#

I immediately try to shut down from the command line. Result:

# shutdown -h now
Failed to connect to bus: No such file or directory
Failed to talk to init daemon.
#
11

Another observation when I use Konsole of KDE as terminal - and thus can still see the Plasma DE:

Immediately after entering

# rfkill block wlan
#

in Konsole, a popup window or message appears near the lower right corner of the desktop telling that the WLAN connection had been deactivated.
So the rfkill command seems to take effect before the system locks up.
The piece of software that triggers this message on the desktop will be Network Manager, I guess.

WLAN hardware is a Realtek RTL8191SEvB, according to hwinfo.
That works without problem under Leap 42.3.

12

Not sure what to say,
I wouldn’t expect what you’re seeing and
Although for a bit I speculated that your system might have unmounted your drives thereby causing inability to find the file and any devices in your file tree, you say you are able to browse to the file so either you’re reading something cached in memory or the drive is still mounted (You might think about exactly your environment when you browsed to see the file).

As for the “shutdown -h now” command, it’s pretty sudden and violent. Although it probably won’t make any diff, I recommend you use the systemd command instead which does nearly the same thing but of course is more consistent with the running subsystem

systemctl poweroff

The

13

Hi again!

Your thought that my system might have unmounted my drives could possibly explain the error messages that I get - at least I didn’t get an error message that would contradict that.

I tried the following to perhaps get a clue:
I opened a Konsole window (i.e. a terminal), and became root using ‘su’ (which in this case wouldn’t have even been necessary).
I disabled WLAN again using the Network Manager Applet.
I try to open a Dolphin window clicking on the icon in the task bar that was placed there when I navigated to
Application Launcher (leftmost KDE icon in the task bar) > Applications > System
right-clicking on ‘File Manager Dolphin’, and selecting ‘Add to Panel (Widget)’.

Error message (this time the original english text):

Unable to run the command specified. The file or folder
/home/mydefaultuser/.local/share/plasma_icons/org.kde.dolphin.desktop
does not exist.

I click on the Konsole window, that is still present, to activate it.
I enter the mount command:

# mount
mount: failed to read mtab: No such file or directory
#

I try to shut down using the command you suggested

# systemctl poweroff
Failed to connect to bus: No such file or directory
Failed to connect to bus: No such file or directory
It is possible to perform action directly, see discussion of --force--force in man systemctl(1).
#

That ‘Failed to connect to bus: No such file or directory’ was printed twice here, is no typo.

One thing you seem to have misunderstood, and I may not have written that absolutely clearly:
The file
/home/mydefaultuser/.local/share/plasma_icons/org.kde.dolphin.desktop
does exist, it represents the file manager icon in the task bar mentioned above, and it was never deleted.
As long as the system isn’t locked up (e.g. after every boot, and before using Network Manager Applet) I can navigate to/browse it.
After the system locked up (i.e. after using Network Manager Applet), I can not do almost anything anymore: no opening of apps (like Dolphin), no shutdown, nothing. So in that state I can not browse that file anymore.

Ah, wait: I finally tried the following:
I open a Dolphin window for /home/mydefaultuser.
After using Network Manager Applet to disconnect WLAN, I get back to that window and try to open the subfolder ‘.local’.
Error message:

The file or folder /home/mydefaultuser/.local does not exist.
14

I forgot to say: before both attempts described above (i.e. opening Konsole, or Dolphin, before using Network Manager Applet), each time I made a fresh boot.

15

Show zypper lr -d You may have mixed repos. since nothing you describe is normal

16

Hi
In my first short posting I wrote that I use the 4 standard repos only.
It was a fresh install from an USB stick with the online repos included, and I didn’t change anything about the repos.
But you probably want to see it anyway, so here is the output of ‘zypper lr -d’:


#  | Alias                     | Name                                                    | Enabled | GPG Check | Refresh | Priority | Type   | URI                                                                      | Service
---+---------------------------+---------------------------------------------------------+---------+-----------+---------+----------+--------+--------------------------------------------------------------------------+--------
 1 | openSUSE-Leap-15.1-1      | openSUSE-Leap-15.1-1                                    | No      | ----      | ----    |   99     | rpm-md | hd:/?device=/dev/disk/by-id/usb-Intenso_Rainbow_09112700349194-0:0-part2 |        
 2 | repo-debug                | Debug Repository                                        | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/debug/distribution/leap/15.1/repo/oss/      |        
 3 | repo-debug-non-oss        | Debug Repository (Non-OSS)                              | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/debug/distribution/leap/15.1/repo/non-oss/  |        
 4 | repo-debug-update         | Update Repository (Debug)                               | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/debug/update/leap/15.1/oss/                 |        
 5 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS)                      | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/debug/update/leap/15.1/non-oss/             |        
 6 | repo-non-oss              | Non-OSS Repository                                      | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/        |        
 7 | repo-oss                  | Haupt-Repository                                        | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/distribution/leap/15.1/repo/oss/            |        
 8 | repo-source               | Source Repository                                       | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/source/distribution/leap/15.1/repo/oss/     |        
 9 | repo-source-non-oss       | Source Repository (Non-OSS)                             | No      | ----      | ----    |   99     | NONE   | http://download.opensuse.org/source/distribution/leap/15.1/repo/non-oss/ |        
10 | repo-update               | Hauptaktualisierungs-Repository                         | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/update/leap/15.1/oss                        |        
11 | repo-update-non-oss       | Aktualisierungs-Repository (Nicht-Open-Source-Software) | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/update/leap/15.1/non-oss/                   |

By your remark that nothing I describe would be normal, you had me thinking about what - except for the different versions of the software - could be different between my installation of Leap 15.1 and that of Leap 42.3 for the same laptop (Leap 42.3 runs quite normal).
One difference I found was in the software for graphics / video.

For Leap 15.1 I have


# Status             Package                        | Summary                                  | Installed (Available)     |       Size

[Taboo -- Never Install] Mesa-dri-nouveau               | Mesa DRI plug-in for 3D acceleration ... | (18.3.2-lp151.22.4)       |   21,5 MiB
[Taboo -- Never Install] Mesa-dri-nouveau-32bit         | Mesa DRI plug-in for 3D acceleration ... | (18.3.2-lp151.22.4)       |   23,6 MiB
[Keep]               libdrm_nouveau2                | Userspace interface for Kernel DRM se... | 2.4.97-lp151.1.1          |   30,4 KiB
[Keep]               libvdpau_nouveau               | XVMC state tracker for Nouveau           | 18.3.2-lp151.22.4         |    6,2 MiB
[Keep]               xf86-video-nouveau             | Beschleunigter Open-Source-Treiber fü... | 1.0.15-lp151.4.1          |  214,8 KiB
[Do Not Install]     libXvMC_nouveau                | XVMC state tracker for Nouveau           | (18.3.2-lp151.22.4)       |    3,9 MiB
[Do Not Install]     libXvMC_nouveau-32bit          | XVMC state tracker for Nouveau           | (18.3.2-lp151.22.4)       |    4,3 MiB
[Do Not Install]     libdrm_nouveau2-32bit          | Userspace interface for Kernel DRM se... | (2.4.97-lp151.1.1)        |   33,5 KiB
[Do Not Install]     libvdpau_nouveau-32bit         | XVMC state tracker for Nouveau           | (18.3.2-lp151.22.4)       |    6,7 MiB

For Leap 42.3 I have


# Status             Package                        | Summary                                  | Installed (Available)     |       Size

[Keep]               libdrm_nouveau2                | Userspace interface for Kernel DRM se... | 2.4.76-1.2                |   30,4 KiB
[Do Not Install]     Mesa-dri-nouveau               | Mesa DRI plug-in for 3D acceleration ... | (17.0.5-176.1)            |   16,5 MiB
[Do Not Install]     Mesa-dri-nouveau-32bit         | Mesa DRI plug-in for 3D acceleration ... | (17.0.5-176.1)            |   17,4 MiB
[Do Not Install]     libXvMC_nouveau                | XVMC state tracker for Nouveau           | (17.0.5-176.1)            |    3,7 MiB
[Do Not Install]     libXvMC_nouveau-32bit          | XVMC state tracker for Nouveau           | (17.0.5-176.1)            |    3,8 MiB
[Do Not Install]     libdrm_nouveau2-32bit          | Userspace interface for Kernel DRM se... | (2.4.76-1.2)              |   29,6 KiB
[Do Not Install]     libvdpau_nouveau               | XVMC state tracker for Nouveau           | (17.0.5-176.1)            |    4,6 MiB
[Do Not Install]     libvdpau_nouveau-32bit         | XVMC state tracker for Nouveau           | (17.0.5-176.1)            |    4,9 MiB
[Do Not Install]     xf86-video-nouveau             | Beschleunigter Open-Source-Treiber fü... | (1.0.15-1.3)              |  223,4 KiB

These lists were produced by going to YaST > Software Management, searching for ‘nouveau’, right-clicking on the first entry of the search results, and selecting ‘Export this list to text file’.

I will try to adapt the driver software for Leap 15.1 accordingly and see what that does.

17

No improvement.

After looking around a bit on both installations, in Leap 15.1 I deleted
libvdpau1, xf86-video-nouveau, xdpyinfo, xf86dga, libXxf86dga1 .

The system boots a bit slower and reacts a bit slower, otherwise runs.

But using the Network Manager Applet to disconnect WLAN the system locks up again.

18

Using YaST > Network Settings to change from ‘Network Manager Service’ to ‘Wicked Service’, the system locks up as well.
Switch off the hard way again …

19

Next fresh boot.
The icon of the Network Manager Applet in the task bar is gone.
So the above changes using YaST > Network Settings took effect.
Let’s see what rfkill does now.


# rfkill
ID TYPE DEVICE      SOFT      HARD
 0 wlan phy0   unblocked unblocked
# 
# rfkill block wlan
# 
# rfkill
ID TYPE DEVICE    SOFT      HARD
 0 wlan phy0   blocked unblocked
# 
# rfkill unblock wlan
# 
# rfkill
ID TYPE DEVICE      SOFT      HARD
 0 wlan phy0   unblocked unblocked
#

Et voilà …

And the system isn’t locked up.

Should I say solved?
At least an improvement.

I think I’ve seen it for today …

20

Since NM is normally user specific and have user specific settings have you tried a different user?