Hi Hamish, > - Xorg, seeing as it's what's using lots of CPU power. > > - LightDM, seeing as the issue only occurs when I use LightDM.
I'd start with these two. The bug is probably LightDM's, e.g. it's repeatedly asking Xorg to do some work on its behalf, though it might be it's making a reasonable request which Xorg is doing inefficiently and SDDM doesn't make the same request. I doubt it's the latter though because Xorg is prodded by a lot of different client and a problem would have already come to light. So, concentrating on LightDM, see if it has debug which you can enable and find the output in the logs or journal. This might be the easiest way to spot the problem, e.g. it's unhappy a file is missing. Ensure the problem is occurring at the time, e.g. high CPU use. Next step would be to attach to it's running processes with strace(1) to see what it's doing. ‘systemctl status lightdm.service’ will probably show multiple process IDs to choose from, but not display the PIDs for its threads. One way to obtain all of them is ‘sudo lsof /usr/bin/lightdm’. Given those PIDs, ‘sudo strace -fp '42 314 1718'’ will attach to all of them and any new children. You'll hopefully see they're all blocked, i.e. consuming no resources. Many will be blocked on a file descriptor. ‘sudo lsof -p 42’ will lists the FDs of PID 42, out of interest. Type a character into LightDM and see if it creates a flurry of syscalls. They should die down to idle again. If not, there's your clue. It might be sending a request to the Xorg X server over and over. strace's output can be stuffed to a file with -o instead of scrolling up the screen. -e will let you filter out boring system calls, or concentrate on particular ones, e.g. the ‘%desc’ set. Happy hunting! -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-07-07 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
