Xorg.0.log stuck, never stops
Gene Heskett
gheskett at shentel.net
Sun Jun 14 14:54:41 UTC 2020
On Sunday 14 June 2020 10:16:47 Adam Nielsen wrote:
> > Because its also a devel machine, haveing 2 SSD's attached where it
> > can build the target sw, there are often 1 minimum to as high as 4
> > ssh -Y logins. But only one in the last several days.
>
> SSH wouldn't do it, but anything that runs on a timer could. For
> example if you have DPMS power saving to shut off the monitor after a
> few minutes, then when it wakes up again it may query the monitor so
> that it can set the correct screen resolution again.
>
> If you're running a full desktop environment (as opposed to a basic
> install) then there are many things it could be. If you're running a
> minimal Linux distro with a cut down Xorg install then power saving is
> about the only thing that could be on by default that might do this,
> that I can think of, not counting hardware issues/bad cables which you
> say aren't a problem given the lack of display issues.
>
> > I do not know that to be the case but if a part was
> > being carved at the time, I'd imagine it would be damaged as this
> > nominally 5 milliseconds means the machine is un-monitored for a
> > part wrecking way too long.
>
> This won't stop the system for five milliseconds, it will take five
> milliseconds for the process to complete but other programs will
> continue to run in the background.
>
> However if your lathe control software is that critical with timing,
> then it should be running with its priority set to "realtime" so that
> it takes priority over all other programs anyway. Otherwise anything
> could hold it up - e.g. random disk cache flushes.
>
> The timestamps are exactly 30 minutes apart down to the second, which
> is a common value for power saving options, so I'd start looking
> there.
>
> Power saving is one thing that can disrupt running processes because
> some devices take enough time to respond to wake up events that the
> system really can be completely blocked for a few milliseconds, so in
> your case where you need code running every millisecond to monitor
> external hardware, I'd be inclined to disable any power saving options
> I could find, including those in the kernel relating to CPU
> throttling, USB devices, etc.
>
> Cheers,
> Adam.
The one thing I found is this in the root crontab
/5 * * * * date & >>/tmp/mouse-trace; sudo lsusb -vv 2>/dev/null |
grep "Bus 001 Device 006" & >>/tmp/mouse-trace
/5 * * * * lsusb -v 2&>/dev/null | grep "Bus 001 Device 006"
>> /tmp/mouse-trace
Which I had added because the mouse was dissapearing. But thats a 5
minute interval, which I just expanded to a 30 minute repeat. I'll
comment it just for S&G.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
More information about the xorg
mailing list