[opensuse] oss 13.1 dbus errors
I have an openSuse 13.1 system that uses systemd. The system has been running fine but after doing a zypper ref/up yesterday (against standard update repos), I have been seeing problems. After bootup, the machine runs fine for about 2 to 2.5 hours. After that, anytime I do a systemctl status <service>, I get following errors logged: Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused I get same errors if I try to start or stop a service. I have tried various things, such as attempting to restart the dbus service, to no avail. This machine has cron jobs that check service status every so often, and the checks all start failing once this condition is encountered. Is anyone else seeing the same thing? Thanks in advance for any help. --Moby -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello Moby, There is a bug open that is the explanation for this behaviour. You can read the details here: https://bugzilla.opensuse.org/show_bug.cgi?id=918226 For the moment you can go back to the previous version of systemd (and add a lock so it doesn't upgrade until the fix is out) with this command: zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper al systemd-32bit systemd systemd-sysvinit Or you can apply a proposed patch: zypper ar -G bsc918226/standard">http://download.opensuse.org/repositories/home:/tsaupe:/branches:/openSUSE:/... systemd-patch zypper dup --repo systemd-patch Note: beware that this will yank out rsyslog if you happen to use it. -Michael On 02/18, Moby wrote:
Date: Wed, 18 Feb 2015 14:16:13 -0600 From: Moby <moby@mobsternet.com> To: opensuse@opensuse.org Subject: [opensuse] oss 13.1 dbus errors
I have an openSuse 13.1 system that uses systemd. The system has been running fine but after doing a zypper ref/up yesterday (against standard update repos), I have been seeing problems. After bootup, the machine runs fine for about 2 to 2.5 hours. After that, anytime I do a systemctl status <service>, I get following errors logged:
Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused
I get same errors if I try to start or stop a service. I have tried various things, such as attempting to restart the dbus service, to no avail. This machine has cron jobs that check service status every so often, and the checks all start failing once this condition is encountered. Is anyone else seeing the same thing?
Thanks in advance for any help.
--Moby
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 18 February 2015, Michael J Dur wrote:
Hello Moby,
There is a bug open that is the explanation for this behaviour. You can read the details here:
https://bugzilla.opensuse.org/show_bug.cgi?id=918226
For the moment you can go back to the previous version of systemd (and add a lock so it doesn't upgrade until the fix is out) with this command:
zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper al systemd-32bit systemd systemd-sysvinit
Regarding this workaround. How could I safely reboot such affected system? Or at least stop services to remount ro etc. $ shutdown -r now Failed to open /dev/initctl: No such device or address Failed to talk to init daemon. $ systemctl stop named Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused Even killing a deamon does not work anymore: $ killall named $ ps aux | grep named named 2027 0.0 0.0 0 0 ? Zs Feb18 0:20 [named] <defunct> cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I'm able to reboot with 'reboot -f', or 'reboot -f & exit' via ssh. There is ongoing discussion and the current patch offered for testing has not fixed the problem, I downgraded all our systems. So far it seems only those that have had systemd segfault require a reboot after the downgrade. On 2015-02-19 05:20, Ruediger Meier wrote:
On Wednesday 18 February 2015, Michael J Dur wrote:
Hello Moby,
There is a bug open that is the explanation for this behaviour. You can read the details here:
https://bugzilla.opensuse.org/show_bug.cgi?id=918226
For the moment you can go back to the previous version of systemd (and add a lock so it doesn't upgrade until the fix is out) with this command:
zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper al systemd-32bit systemd systemd-sysvinit
Regarding this workaround. How could I safely reboot such affected system? Or at least stop services to remount ro etc.
$ shutdown -r now Failed to open /dev/initctl: No such device or address Failed to talk to init daemon.
$ systemctl stop named Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused
Even killing a deamon does not work anymore: $ killall named $ ps aux | grep named named 2027 0.0 0.0 0 0 ? Zs Feb18 0:20 [named] <defunct>
cu, Rudi
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 19 February 2015, Michael J Dur wrote:
I'm able to reboot with 'reboot -f', or 'reboot -f & exit'
Hm, this is what I did with about 15 machines yesterday. But this is really bad way.
via ssh.
If login still worked it was luck because it seems that any login produces zombie processes. Some of our machines had already "two many open files" "to many processes" ... couldn't do nothing anymore.
There is ongoing discussion and the current patch offered for testing has not fixed the problem,
I downgraded all our systems. So far it seems only those that have had systemd segfault require a reboot after the downgrade.
On 2015-02-19 05:20, Ruediger Meier wrote:
On Wednesday 18 February 2015, Michael J Dur wrote:
Hello Moby,
There is a bug open that is the explanation for this behaviour. You can read the details here:
https://bugzilla.opensuse.org/show_bug.cgi?id=918226
For the moment you can go back to the previous version of systemd (and add a lock so it doesn't upgrade until the fix is out) with this command:
zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper al systemd-32bit systemd systemd-sysvinit
Regarding this workaround. How could I safely reboot such affected system? Or at least stop services to remount ro etc.
$ shutdown -r now Failed to open /dev/initctl: No such device or address Failed to talk to init daemon.
$ systemctl stop named Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused
Even killing a deamon does not work anymore: $ killall named $ ps aux | grep named named 2027 0.0 0.0 0 0 ? Zs Feb18 0:20 [named] <defunct>
cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/19/2015 06:03 AM, Ruediger Meier wrote:
On Thursday 19 February 2015, Michael J Dur wrote:
I'm able to reboot with 'reboot -f', or 'reboot -f & exit' Hm, this is what I did with about 15 machines yesterday. But this is really bad way.
via ssh. If login still worked it was luck because it seems that any login produces zombie processes. Some of our machines had already "two many open files" "to many processes" ... couldn't do nothing anymore.
There is ongoing discussion and the current patch offered for testing has not fixed the problem,
I downgraded all our systems. So far it seems only those that have had systemd segfault require a reboot after the downgrade.
On 2015-02-19 05:20, Ruediger Meier wrote:
On Wednesday 18 February 2015, Michael J Dur wrote:
Hello Moby,
There is a bug open that is the explanation for this behaviour. You can read the details here:
https://bugzilla.opensuse.org/show_bug.cgi?id=918226
For the moment you can go back to the previous version of systemd (and add a lock so it doesn't upgrade until the fix is out) with this command:
zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper al systemd-32bit systemd systemd-sysvinit Regarding this workaround. How could I safely reboot such affected system? Or at least stop services to remount ro etc.
$ shutdown -r now Failed to open /dev/initctl: No such device or address Failed to talk to init daemon.
$ systemctl stop named Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused
Even killing a deamon does not work anymore: $ killall named $ ps aux | grep named named 2027 0.0 0.0 0 0 ? Zs Feb18 0:20 [named] <defunct>
cu, Rudi Downgrading systemd, as suggested by Michael, fixed the issue. Now I have systemd downgraded and locked in zypper do it does not get messed with. A very serious issue, IMHO, since pid 1 process is jacked up, and in a stable release as opposed to tumbleweed/factory. I also saw growing numbers of zombies with the broken version, but the machine did not complain about running out of resources.
Regards, -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin First they came for the Jews and I did not speak out because I was not a Jew. Then they came for the Communists and I did not speak out because I was not a Communist. Then they came for the trade unionists and I did not speak out because I was not a trade unionist. Then they came for me and there was no one left to speak out for me. -- Pastor Martin Niemöller -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Il 19/02/2015 15:16, Moby ha scritto:
On 02/19/2015 06:03 AM, Ruediger Meier wrote:
On Thursday 19 February 2015, Michael J Dur wrote:
I'm able to reboot with 'reboot -f', or 'reboot -f & exit' Hm, this is what I did with about 15 machines yesterday. But this is really bad way.
via ssh. If login still worked it was luck because it seems that any login produces zombie processes. Some of our machines had already "two many open files" "to many processes" ... couldn't do nothing anymore.
There is ongoing discussion and the current patch offered for testing has not fixed the problem,
I downgraded all our systems. So far it seems only those that have had systemd segfault require a reboot after the downgrade.
On 2015-02-19 05:20, Ruediger Meier wrote:
On Wednesday 18 February 2015, Michael J Dur wrote:
Hello Moby,
There is a bug open that is the explanation for this behaviour. You can read the details here:
https://bugzilla.opensuse.org/show_bug.cgi?id=918226
For the moment you can go back to the previous version of systemd (and add a lock so it doesn't upgrade until the fix is out) with this command:
zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper al systemd-32bit systemd systemd-sysvinit Regarding this workaround. How could I safely reboot such affected system? Or at least stop services to remount ro etc.
$ shutdown -r now Failed to open /dev/initctl: No such device or address Failed to talk to init daemon.
$ systemctl stop named Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused
Even killing a deamon does not work anymore: $ killall named $ ps aux | grep named named 2027 0.0 0.0 0 0 ? Zs Feb18 0:20 [named] <defunct>
cu, Rudi Downgrading systemd, as suggested by Michael, fixed the issue. Now I have systemd downgraded and locked in zypper do it does not get messed with. A very serious issue, IMHO, since pid 1 process is jacked up, and in a stable release as opposed to tumbleweed/factory. I also saw growing numbers of zombies with the broken version, but the machine did not complain about running out of resources.
Regards,
Any news about a patch ? That is a big problem, on about 30 of my remote systems.... :( Testing the backroll on a virtual machine.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2015-02-23 12:49, Claudio ML wrote:
Il 19/02/2015 15:16, Moby ha scritto:
On 02/19/2015 06:03 AM, Ruediger Meier wrote:
On Thursday 19 February 2015, Michael J Dur wrote:
I'm able to reboot with 'reboot -f', or 'reboot -f & exit' Hm, this is what I did with about 15 machines yesterday. But this is really bad way.
via ssh. If login still worked it was luck because it seems that any login produces zombie processes. Some of our machines had already "two many open files" "to many processes" ... couldn't do nothing anymore.
There is ongoing discussion and the current patch offered for testing has not fixed the problem,
I downgraded all our systems. So far it seems only those that have had systemd segfault require a reboot after the downgrade.
On 2015-02-19 05:20, Ruediger Meier wrote:
On Wednesday 18 February 2015, Michael J Dur wrote:
Hello Moby,
There is a bug open that is the explanation for this behaviour. You can read the details here:
https://bugzilla.opensuse.org/show_bug.cgi?id=918226
For the moment you can go back to the previous version of systemd (and add a lock so it doesn't upgrade until the fix is out) with this command:
zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper al systemd-32bit systemd systemd-sysvinit Regarding this workaround. How could I safely reboot such affected system? Or at least stop services to remount ro etc.
$ shutdown -r now Failed to open /dev/initctl: No such device or address Failed to talk to init daemon.
$ systemctl stop named Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused
Even killing a deamon does not work anymore: $ killall named $ ps aux | grep named named 2027 0.0 0.0 0 0 ? Zs Feb18 0:20 [named] <defunct>
cu, Rudi Downgrading systemd, as suggested by Michael, fixed the issue. Now I have systemd downgraded and locked in zypper do it does not get messed with. A very serious issue, IMHO, since pid 1 process is jacked up, and in a stable release as opposed to tumbleweed/factory. I also saw growing numbers of zombies with the broken version, but the machine did not complain about running out of resources.
Regards,
Any news about a patch ? That is a big problem, on about 30 of my remote systems.... :( Testing the backroll on a virtual machine....
I believe the patch was put into the repos this morning. I saw 208-32.1 come down to our mirror. -Michael -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/23/2015 11:57 AM, Michael J Dur wrote:
On 2015-02-23 12:49, Claudio ML wrote:
Il 19/02/2015 15:16, Moby ha scritto:
On 02/19/2015 06:03 AM, Ruediger Meier wrote:
On Thursday 19 February 2015, Michael J Dur wrote:
I'm able to reboot with 'reboot -f', or 'reboot -f & exit' Hm, this is what I did with about 15 machines yesterday. But this is really bad way.
via ssh. If login still worked it was luck because it seems that any login produces zombie processes. Some of our machines had already "two many open files" "to many processes" ... couldn't do nothing anymore.
There is ongoing discussion and the current patch offered for testing has not fixed the problem,
I downgraded all our systems. So far it seems only those that have had systemd segfault require a reboot after the downgrade.
On 2015-02-19 05:20, Ruediger Meier wrote:
On Wednesday 18 February 2015, Michael J Dur wrote: > Hello Moby, > > There is a bug open that is the explanation for this behaviour. > You can read the details here: > > https://bugzilla.opensuse.org/show_bug.cgi?id=918226 > > For the moment you can go back to the previous version of systemd > (and add a lock so it doesn't upgrade until the fix is out) with > this command: > > zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 > systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper > al systemd-32bit systemd systemd-sysvinit Regarding this workaround. How could I safely reboot such affected system? Or at least stop services to remount ro etc.
$ shutdown -r now Failed to open /dev/initctl: No such device or address Failed to talk to init daemon.
$ systemctl stop named Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused
Even killing a deamon does not work anymore: $ killall named $ ps aux | grep named named 2027 0.0 0.0 0 0 ? Zs Feb18 0:20 [named] <defunct>
cu, Rudi Downgrading systemd, as suggested by Michael, fixed the issue. Now I have systemd downgraded and locked in zypper do it does not get messed with. A very serious issue, IMHO, since pid 1 process is jacked up, and in a stable release as opposed to tumbleweed/factory. I also saw growing numbers of zombies with the broken version, but the machine did not complain about running out of resources.
Regards,
Any news about a patch ? That is a big problem, on about 30 of my remote systems.... :( Testing the backroll on a virtual machine....
I believe the patch was put into the repos this morning. I saw 208-32.1 come down to our mirror.
-Michael zypper ref and then zypper up gave me the patch and it works fine.
-- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Il 23/02/2015 20:31, Moby ha scritto:
On 02/23/2015 11:57 AM, Michael J Dur wrote:
On 2015-02-23 12:49, Claudio ML wrote:
Il 19/02/2015 15:16, Moby ha scritto:
On 02/19/2015 06:03 AM, Ruediger Meier wrote:
On Thursday 19 February 2015, Michael J Dur wrote:
I'm able to reboot with 'reboot -f', or 'reboot -f & exit' Hm, this is what I did with about 15 machines yesterday. But this is really bad way.
via ssh. If login still worked it was luck because it seems that any login produces zombie processes. Some of our machines had already "two many open files" "to many processes" ... couldn't do nothing anymore.
There is ongoing discussion and the current patch offered for testing has not fixed the problem,
I downgraded all our systems. So far it seems only those that have had systemd segfault require a reboot after the downgrade.
On 2015-02-19 05:20, Ruediger Meier wrote: > On Wednesday 18 February 2015, Michael J Dur wrote: >> Hello Moby, >> >> There is a bug open that is the explanation for this behaviour. >> You can read the details here: >> >> https://bugzilla.opensuse.org/show_bug.cgi?id=918226 >> >> For the moment you can go back to the previous version of systemd >> (and add a lock so it doesn't upgrade until the fix is out) with >> this command: >> >> zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 >> systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper >> al systemd-32bit systemd systemd-sysvinit > Regarding this workaround. How could I safely reboot such affected > system? Or at least stop services to remount ro etc. > > $ shutdown -r now > Failed to open /dev/initctl: No such device or address > Failed to talk to init daemon. > > $ systemctl stop named > Failed to get D-Bus connection: Failed to connect to > socket /run/systemd/private: Connection refused > > Even killing a deamon does not work anymore: > $ killall named > $ ps aux | grep named > named 2027 0.0 0.0 0 0 ? Zs Feb18 0:20 [named] > <defunct> > > > cu, > Rudi Downgrading systemd, as suggested by Michael, fixed the issue. Now I have systemd downgraded and locked in zypper do it does not get messed with. A very serious issue, IMHO, since pid 1 process is jacked up, and in a stable release as opposed to tumbleweed/factory. I also saw growing numbers of zombies with the broken version, but the machine did not complain about running out of resources.
Regards,
Any news about a patch ? That is a big problem, on about 30 of my remote systems.... :( Testing the backroll on a virtual machine....
I believe the patch was put into the repos this morning. I saw 208-32.1 come down to our mirror.
-Michael zypper ref and then zypper up gave me the patch and it works fine.
Here no patch avaiable for now... Any way to force the update ? Claudio. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Il 24/02/2015 09:44, Claudio ML ha scritto:
Il 23/02/2015 20:31, Moby ha scritto:
On 02/23/2015 11:57 AM, Michael J Dur wrote:
On 2015-02-23 12:49, Claudio ML wrote:
Il 19/02/2015 15:16, Moby ha scritto:
On 02/19/2015 06:03 AM, Ruediger Meier wrote:
On Thursday 19 February 2015, Michael J Dur wrote: > I'm able to reboot with 'reboot -f', or 'reboot -f & exit' Hm, this is what I did with about 15 machines yesterday. But this is really bad way.
> via ssh. If login still worked it was luck because it seems that any login produces zombie processes. Some of our machines had already "two many open files" "to many processes" ... couldn't do nothing anymore.
> There is ongoing discussion and the current patch offered for > testing > has not fixed the problem, > > I downgraded all our systems. So far it seems only those that have > had systemd segfault require a reboot after the downgrade. > > On 2015-02-19 05:20, Ruediger Meier wrote: >> On Wednesday 18 February 2015, Michael J Dur wrote: >>> Hello Moby, >>> >>> There is a bug open that is the explanation for this behaviour. >>> You can read the details here: >>> >>> https://bugzilla.opensuse.org/show_bug.cgi?id=918226 >>> >>> For the moment you can go back to the previous version of systemd >>> (and add a lock so it doesn't upgrade until the fix is out) with >>> this command: >>> >>> zypper -n in --oldpackage systemd-32bit-208-23.3.x86_64 >>> systemd-208-23.3.x86_64 systemd-sysvinit-208-23.3.x86_64 && zypper >>> al systemd-32bit systemd systemd-sysvinit >> Regarding this workaround. How could I safely reboot such affected >> system? Or at least stop services to remount ro etc. >> >> $ shutdown -r now >> Failed to open /dev/initctl: No such device or address >> Failed to talk to init daemon. >> >> $ systemctl stop named >> Failed to get D-Bus connection: Failed to connect to >> socket /run/systemd/private: Connection refused >> >> Even killing a deamon does not work anymore: >> $ killall named >> $ ps aux | grep named >> named 2027 0.0 0.0 0 0 ? Zs Feb18 0:20 [named] >> <defunct> >> >> >> cu, >> Rudi Downgrading systemd, as suggested by Michael, fixed the issue. Now I have systemd downgraded and locked in zypper do it does not get messed with. A very serious issue, IMHO, since pid 1 process is jacked up, and in a stable release as opposed to tumbleweed/factory. I also saw growing numbers of zombies with the broken version, but the machine did not complain about running out of resources.
Regards,
Any news about a patch ? That is a big problem, on about 30 of my remote systems.... :( Testing the backroll on a virtual machine.... I believe the patch was put into the repos this morning. I saw 208-32.1 come down to our mirror.
-Michael zypper ref and then zypper up gave me the patch and it works fine.
Here no patch avaiable for now...
Any way to force the update ?
Claudio.
Sorry, my fault, the patch is present. systemd-sysvinit-208-32.1.x86_64 Claudio. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Claudio ML -
Michael J Dur -
Moby -
Ruediger Meier