I get this error:
Failure (org.freedesktop.DBus.Error.TimedOut)
when I try to run any snapper commands, such as
snapper list
snapper list-configs
snapper cleanup
Can anyone shed any light on this? Or where to start troubleshooting.
Running SLES 11 SP3.
Thanks,
Gordon
Hi
Thats an error seen if some changes have been made with polkit (policy
kit), have there been some tweaks with this on the system?
Try running the daily cronjob /etc/cron.daily/suse.de-snapper does this
complete?
The snapper config is /etc/snapper/configs/root which can be tweaked,
then run the cronjob manually…
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 SP1|GNOME 3.10.4|3.12.53-60.30-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Hi Malcolm,
We’ve never used polkit.
In fact I’ve just found out that man does not run either!
For example:
man polkit
man mount
give no output, and have to be stopped with ctrl-c. I am not sure if this is related.
I tried this and received the same error three times for each of the clean up routines (number, timeline, pre-post):
Failure (org.freedesktop.DBus.Error.TimedOut)
Failure (org.freedesktop.DBus.Error.TimedOut)
Failure (org.freedesktop.DBus.Error.TimedOut)
It looks like there is some other underlying issue, because a number of things are showing issues after further checks:
ssh
Tested with a normal user using ssh -v, and the client hangs after displaying: “debug1: Entering interactive session.”
I have even left this for probably 30 min and it is still hung.
tested ssh with root and it appeared to hang, but after pressing ctrl-c, it proceeded to complete the connection to the remote host
man
provides no output
su
As root, su to a userlogon hangs also. Waited for over 5 min, then used ctrl-c to exit.
The server experienced disk space issues yesterday on it’s btrfs / partition, and I booted with the SLES ISO to clean up some /tmp and other backup files, before rebooting the server again. While it is operational, as an SMTP gateway and web server, there is obviously something amiss under the hood.
We also did install some security updates on the server a few weeks ago, which may have brought us closer to our disk space filling up. The patches installed were ones related to remote access and apache:
slessp3-libopenssl-devel - Security update for OpenSSL
slessp3-openssl-12059 - Recommended update for openssl
slessp3-openssl-12193 - Recommended update for openssl
slessp3-openssl-12264 - Security update for openssl
slessp3-perl-Net-SSLeay - Recommended update for perl-Net-SSLeay
slessp3-openssh-12096 - Security update for openssh
oes11sp2-edirectory-888-patch5-hot-patch - July 2015 OES11 SP2 eDirectory 8.8 SP8 Patch 5 Hot Patch
oes11sp2-edirectory-888-patch5-hot-patch2 - July 2015 OES11 SP2 eDirectory 8.8 SP8 Patch 5 Hot Patch 2
WEB SERVER BASED PATCHES - Apache
slessp3-apache2-12181 | Security update for apache2
slessp3-apache2-mod_jk | Recommended update for apache2-mod_jk
slessp3-apache2-mod_nss | Recommended update for apache2-mod_nss
slessp3-apache2-mod_nss-12143 | Recommended update for apache2-mod_nss
slessp3-apache2-mod_perl | Recommended update for apache2-mod_perl
slessp3-apache2-mod_php53 | Security update for PHP
slessp3-apache2-mod_python | Recommended update for apache2-mod_python
slessp3-apache2-mod_security2 | Security update for apache2-mod_security2
Just now I checked with zypper lu, and there is a huge list of updates, 305 in total. I was thinking of applying all these patches, in case applying just some of the security patches in isolation have left the system in some incompatible state. Before proceeding with this, I’ll look to add some extra disk space and move say /tmp and /var to it.
Some info about disk space and mounts
:
[FONT=Courier New]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 18G 14G 1.4G 92% /
udev 1.9G 88K 1.9G 1% /dev
tmpfs 1.9G 336K 1.9G 1% /dev/shm
/dev/sda1 152M 48M 96M 34% /boot
192.168.0.5:/home/software/gw2014r2 22G 16G 5.2G 76% /home/software/gw2014r2-on-fs2_nfs
/dev/sda3 on / type btrfs (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,mode=1777)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /boot type ext3 (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
none on /var/lib/ntp/proc type proc (ro,nosuid,nodev)
novfs on /var/opt/novell/nclmnt type novfs (rw)
192.168.0.5:/home/software/gw2014r2 on /home/software/gw2014r2-on-fs2_nfs type nfs (ro,sync,noatime,addr=192.168.0.5)
Label: none uuid: 1ffe998f-dccb-4eef-becb-c5bdc120d033
Total devices 1 FS bytes used 12.62GiB
devid 1 size 17.84GiB used 17.84GiB path /dev/sda3
Btrfs v0.20+
Data: total=12.81GiB, used=11.51GiB
System, DUP: total=8.00MiB, used=4.00KiB
System: total=4.00MiB, used=0.00
Metadata, DUP: total=2.50GiB, used=1.11GiB
Metadata: total=8.00MiB, used=0.00
[/FONT]
Any ideas or recommendations on the above are much appreciated.
–
Gordon
After restarting the server to boot into runlevel 1 to recover some disk space, I now get this:
btrfs is not looking so good now… 
Hi
So is this an OES system…
Have a read here may offer some tips;
https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#
I would also suggest you pop over to the Microfocus forum and the OES subforums at https://forums.microfocus.com which may have some pointers to your dbus issue…
Yes, it is OES, but only to hold an eDir replica, there are no other OES services in use.
I’ve got things booting in runlevel 1, and managed to delete all snapshots with Yast. 
Disk space is looking good now as I’ve also moved /tmp and /var to another partition.
But snapper list now gives:
Failure (dbus fatal exception)
Time to investigate the link between snapper and dbus…
Never had to ever look at dbus before but it wasn’t running.
After starting it up:
rcdbus startsnapper works fine!!!
It should be starting on boot as per
# chkconfig dbus
dbus on
Time to test runlevel 3 now…