Failed to get D-Bus connection: Unknown error -1

PackRat

Anyone else seeing this error with vsido jedi when trying to manager services -

Failed to get D-Bus connection: Unknown error -1



everything works - cups, vsftpd, nfs, lightdm etc .... just can't manage any services; google search wasn't much help so if anyone knows what's up with this an answer will be appreciated.

I did a re-install of dbus and systemd from synaptic but no change (have not rebooted yet though).

only other reference to this I've seen - vsido dus error link
I am tired of talk that comes to nothing.
-- Chief Joseph

...the sun, the darkness, the winds are all listening to what we have to say.
-- Geronimo

VastOne

I have been seeing something akin to this for several months but have not pursued it because it has had no impact on what I have been doing lately, D-Feet no longer works at all and shows no errors.  It just does not see or connect to any bus at all

This has been going on before jedi and I believe it is a systemd issue.  I have not been able to find any references at all to bug reports or errors with D-Feet and I will remedy that today.  I think once we understand that it will at least assist in identifying what you and paxmark1 have seen
VSIDO      VSIDO Change Blog    

    I dev VSIDO

PackRat

OK

Did a search on the Arch forum and linuxquestions, nothing.

Get that error in fluxbox, xfce, i3, fvwm, and mwm - so it doesn't appear to be a window manager issue either.
I am tired of talk that comes to nothing.
-- Chief Joseph

...the sun, the darkness, the winds are all listening to what we have to say.
-- Geronimo

PackRat

Anyone know what cgroups is/does? - and how to work with it? - cgroups from Arch Linuix wiki

Came across a reference to cgroups while trying to track this dbus error. It's somehow involved with dbus and systemd but I'm not really seeing how. I did notice that I do not have the /etc/cgconfig.conf file referenced in the Arch wiki.

I bring this up because Cgroups appears to be a recent addition to Sid/VSIDO. I've been rolling VSIDO on  my laptop for a while now, and cgroups is not installed - and I've never gotten the dbus error; clean install of VSIDO on the desktop and I now have the dbus error.

Unistalling it through synaptic (trial run) takes some packages with it - like the systemd-schim, but doesn't remove systemd.

Need some more information/research on this one.
I am tired of talk that comes to nothing.
-- Chief Joseph

...the sun, the darkness, the winds are all listening to what we have to say.
-- Geronimo


PackRat

I am tired of talk that comes to nothing.
-- Chief Joseph

...the sun, the darkness, the winds are all listening to what we have to say.
-- Geronimo

jedi

OK, my 1 cent's worth...

CGroups is a part of systemd, where each 'group' controls a set of processes.  It is very confusing to me, and I'm starting to wonder how much of this stuff is being done on purpose.  (ok, no ranting)  However...
I have seen this error myself when trying to mount /var/run as tmpfs in fstab.  Supposedly this would prolong the life of my SSD as it wouldn't be writing to the drive so much, rather, running all that in RAM.  With newer SSD's, there is really no worries as to drive longevity, thus making this an unnecessary exercise.  Also, I believe that since 'Wheezy' /var/run is a symlink to /run.  So, by doing so I was 'overmounting' /run, and destroying all the states that were stored there.  By simply commenting it out as seen below, all was well again.

Not sure if this is the same issue as your having, but though I'd mention it.

/etc/fstab;

# /etc/fstab: static file system information.
# mounting /var into tmpfs to save the life of my SSD 02132013 and defaults,noatime for TRIM
# <file system> <mount point>   <type>  <options>       <dump>  <pass>

proc          /proc proc     defaults 0 0
/dev/sda1 / ext4        defaults,noatime 0 1
/dev/sda2 /home ext4 defaults,noatime 0 0
/dev/sdb1    /media/DATA ext4 defaults 0 0
/dev/cdrom /media/cdrom udf,iso9660 user,noauto,exec,utf8 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
tmpfs /var/log tmpfs defaults 0 0
#tmpfs /var/run tmpfs defaults 0 0
Forum Netiquette

"No matter how smart you are you can never convince someone stupid that they are stupid."  Anonymous

PackRat

^ I don't know if I was having that issue because I wasn't trying to do what you're attempting.

My issue was that I couldn't control processes using systemctl. I think I have fixed my issue by uninstalling cgmanager and reinstalling it. The uninstall removed some other apps and did some reconfiguring of systemd. reinstalling it just installed cgmanager and a couple (d-bus related) - not all - the dependencies removed earlier. Not sure if that is the proper fix, so I really can't recommend it. Not sure which app was the original culprit.

d-feet still doesn't work.

Right now, I'm just assigning this to debian not fully implementing/integrating systemd so there is some dependency mahem going on.
I am tired of talk that comes to nothing.
-- Chief Joseph

...the sun, the darkness, the winds are all listening to what we have to say.
-- Geronimo

jedi

Glad your way worked!  So far I've been lucky in that systemctl has always worked to start/stop, enable/disable processes/services.

As an aside, d-feet starts up for me, but it never see's or connects to anything in 'System Bus' or 'Session Bus'.  Wherther I start it from the menu or terminal...  (this has been an issue for quite a while with d-feet, and I think even prior to the 'jedi' release)
Forum Netiquette

"No matter how smart you are you can never convince someone stupid that they are stupid."  Anonymous

PackRat

d-feet is the same on my system; the app starts, no info.
I am tired of talk that comes to nothing.
-- Chief Joseph

...the sun, the darkness, the winds are all listening to what we have to say.
-- Geronimo