From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 7 Sep 2015 10:02:58 -0700 (PDT) From: Frankie Wild To: voidlinux Message-Id: <9fc97550-d596-4848-829f-6f91727820b4@googlegroups.com> In-Reply-To: References: <2da6d03f-ec11-4c39-8f61-5210d5c643dd@googlegroups.com> Subject: Re: Random crashes and log-outs of E19 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_141_252735894.1441645378820" ------=_Part_141_252735894.1441645378820 Content-Type: multipart/alternative; boundary="----=_Part_142_155451955.1441645378820" ------=_Part_142_155451955.1441645378820 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Turns out to be more than that. I reinstalled udisks2 with external drive unplugged. Now the occasional log-outs happen with the notice udisks2 successfully reinstalled... It happens about 10-15 times a day, so I am at the point of reinstalling the whole system or trying out Manjaro OpenRC, although I like Void and am sure that udisks2 is used throughout all distributions nowaday, replacing the good old HAL. On Sunday, September 6, 2015 at 8:37:26 PM UTC+3, Frankie Wild wrote: > > The errors got more informative. It's definitely being caused by the > external drive I am using from time to time. Obviously it's crashing due to > the periodic nature of remounting the devices that udisks uses and happens > when I unplugged the external hdd earlier, not quite sure why it's not > event based rather than interval based. > > On Sunday, September 6, 2015 at 1:07:52 PM UTC+3, Frankie Wild wrote: >> >> dbus-monitor --system >> >> dbus-monitor: unable to enable new-style monitoring: >> org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 matched >> rules; type="method_call", sender=":1.68" (uid=1000 pid=28279 >> comm="dbus-monitor --system ") interface="org.freedesktop.DBus.Monitoring" >> member="BecomeMonitor" error name="(unset)" requested_reply="0" >> destination="org.freedesktop.DBus" (bus)". Falling back to eavesdropping. >> signal time=1441533725.361185 sender=org.freedesktop.DBus -> >> destination=:1.68 serial=2 path=/org/freedesktop/DBus; >> interface=org.freedesktop.DBus; member=NameAcquired >> string ":1.68" >> >> dbus-monitor --session >> signal time=1441533710.331885 sender=org.freedesktop.DBus -> >> destination=:1.6 serial=2 path=/org/freedesktop/DBus; >> interface=org.freedesktop.DBus; member=NameAcquired >> string ":1.6" >> signal time=1441533710.331920 sender=org.freedesktop.DBus -> >> destination=:1.6 serial=4 path=/org/freedesktop/DBus; >> interface=org.freedesktop.DBus; member=NameLost >> string ":1.6" >> >> >> This might give some clue if someone else is experiencing a similar >> behavior. >> >> I have also tried to exclusively stop the remounting of the devices over >> a certain period of time, since I suspect this is the case when the crashes >> happen. >> >> udisks --inhibit-all-polling >> >> >> Or >> >> udisks2 --inhibit-all-polling >> >> >> >> Both resulting in command not found. >> >> >> On Sunday, September 6, 2015 at 12:31:46 PM UTC+3, Frankie Wild wrote: >>> >>> Interestingly enough it seems related to the udiskd daemon. At least >>> this is what I am seeing for a second in the log upon crash before being >>> presented with login screen. >>> >>> Another thing I've noticed is that about the same time the crashes >>> started a glitch in E19 appeared as well. Again random, when I am trying to >>> close a window on the taskbar the mouse would move precisely to the center >>> of the screen and does that constantly until reboot. >>> >>> On Friday, September 4, 2015 at 6:50:49 PM UTC+3, Frankie Wild wrote: >>>> >>>> I believe it's since I installed latest updates two days ago. >>>> >>>> At the time it occurs I get a black screen with a few lines of errors >>>> and then back to login screen. >>>> >>>> I couldn't memorize what the errors were at the time. I have checked >>>> all logs in /var/log to no avail... >>>> >>>> Where could they be, so that I can post more info on the errors ? >>>> >>> ------=_Part_142_155451955.1441645378820 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Turns out to be more than that. I reinstalled udisks2 with= external drive unplugged. Now the occasional log-outs happen with the noti= ce udisks2 successfully reinstalled...=C2=A0

It happens = about 10-15 times a day, so I am at the point of reinstalling the whole sys= tem or trying out Manjaro OpenRC, although I like Void and am sure that udi= sks2 is used throughout all distributions nowaday, replacing the good old H= AL.

On Sunday, September 6, 2015 at 8:37:26 PM UTC+3, Frankie Wild w= rote:
The erro= rs got more informative. It's definitely being caused by the external d= rive I am using from time to time. Obviously it's crashing due to the p= eriodic nature of remounting the devices that udisks uses and happens when = I unplugged the external hdd earlier, not quite sure why it's not event= based rather than interval based.

On Sunday, September 6, 2015 at 1= :07:52 PM UTC+3, Frankie Wild wrote:
dbus-monitor --system

dbus-= monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.= AccessDenied: "Rejected send message, 1 matched rules; type=3D&qu= ot;method_call", sender=3D":1.68" (uid=3D1000 pid=3D28279 co= mm=3D"dbus-monitor --system ") interface=3D"org.freedesktop.= DBus.Monitoring" member=3D"BecomeMonitor" error name=3D= "(unset)" requested_reply=3D"0" destination=3D"org= .freedesktop.DBus" (bus)". Falling back to eavesdropping.
signal time=3D1441533725.361185 sender=3Dorg.freedesktop.DBus ->= destination=3D:1.68 serial=3D2 path=3D/org/freedesktop/DBus; interface=3Do= rg.freedesktop.DBus; member=3DNameAcquired
=C2=A0 =C2=A0stri= ng ":1.68"

dbus-monitor --session
signal time=3D1441533710.331885 sender=3Dorg.freedesktop.DBus ->= ; destination=3D:1.6 serial=3D2 path=3D/org/freedesktop/DBus; interface=3Do= rg.freedesktop.DBus; member=3DNameAcquired
=C2=A0 =C2=A0stri= ng ":1.6"
signal time=3D1441533710.331920 sender=3Dorg.= freedesktop.DBus -> destination=3D:1.6 serial=3D4 path=3D/org/freedeskto= p/DBus; interface=3Dorg.freedesktop.DBus; member=3DNameLost
= =C2=A0 =C2=A0string ":1.6"


This might give some clue if someone else is experiencing a similar= behavior.=C2=A0

I have also tried to exclusively = stop the remounting of the devices over a certain period of time, since I s= uspect this is the case when the crashes happen.

<= pre style=3D"border:1px solid rgb(187,204,221);padding:1em;line-height:1.1e= m;overflow:auto;background-color:rgb(235,241,245)">udisks --inhibit-all-pol= ling

Or=C2=A0

udisks2 --inhibit-all-polling


Both resulting in command not found.=C2=A0


On Sunday, September 6, 2015 at 12:31:46 = PM UTC+3, Frankie Wild wrote:
Interestingly enough it seems related to the udiskd daemon. At l= east this is what I am seeing for a second in the log upon crash before bei= ng presented with login screen.

Another thing I've n= oticed is that about the same time the crashes started a glitch in E19 appe= ared as well. Again random, when I am trying to close a window on the taskb= ar the mouse would move precisely to the center of the screen and does that= constantly until reboot.

On Friday, September 4, 2015 at 6:5= 0:49 PM UTC+3, Frankie Wild wrote:
I believe it's since I installed latest updates two d= ays ago.=C2=A0

At the time it occurs I get a black scree= n with a few lines of errors and then back to login screen.

<= /div>
I couldn't memorize what the errors were at the time. I have = checked all logs in /var/log to no avail...=C2=A0

= Where could they be, so that I can post more info on the errors ?=C2=A0
------=_Part_142_155451955.1441645378820-- ------=_Part_141_252735894.1441645378820--