Open ossi1967 opened 7 years ago
Thank you very much for reporting it!
As soon as you uncheck "Run collectd" and go for Accept, the command
systemctl --user stop collectd
is run. If it hangs on that, something significant is wrong. In general, collectd opens several proc and sys files and analyzes them. Since its running as a user (not root), it shouldn't lock itself unless there is a bug in collectd or Sailfish X adaptation.
Since we know that bluetooth is not the strongest part of adaptation, maybe you could try to comment out this line in /etc/collectd.conf (https://github.com/rinigus/collectd/blob/sailfish/contrib/sailfish/collectd.conf#L181) and see if you can get the same 100% lock case?
I commented the line out, still the same issue.
Tried to do the
systemctl --user stop collectd
manually from a ssh session - the thing hangs, there's no error or such, I just don't get my command prompt back unless I Ctrl+C.
First I thought the behaviour was dependent on whether or not the GUI is loaded. This is wrong, it was probably a coincidence based on my usage pattern.
What I noticed when keeping the SSH session open and running top: First, it takes a while for collectd to show up there at all. A few minutes. Then it takes it's seat at the top of the list quickly where it shows up with a 100% reading. This changes only after the screen got blank, the CPU values will drop to anything from 5% to 25% roughly, only to go up immediately when the screen goes on again.
Thank you very much for testing! Does this systemctl --user stop collectd
hang every time you use it? For example, if you start it from gui and within a minute try to close it using command line?
I cannot reproduce it on my device, but it has older SFOS version (the port hasn't been updated yet) and we would probably have to wait and see whether its applicable on other devices as well.
Oh - I wasn't aware that you depended on a port that doesn't yet have the latest Sailfish version. In addition to the Xperia X (where the issue occurs) I now tested it on the Jolla 1 and on the tablet, both with 2.1.3. On these devices, there's no problem. So I guess it doesn't depend on the OS version.
What I did was
systemctl --user start collectd
from the command line and then trying to manually stop it again while watching the output of top
in a second terminal. It stops nicely as long as it doesn't give any unusual CPU readings. Once the CPU percentage goes up to 100%, I cannot stop it any more. After I try, here's what systemctl --user list-units
tells me:
collectd.service loaded deactivating stop-sigterm stop Collectd statistics daemon
If it's something specific to the Xperia X, I wonder if it's specific to my device or the model as such. Remember I installed it in the first place because I felt (and still feel) battery life isn't what it should be.
Or maybe something went wrong when I installed / first used it? Would it be a good idea to uninstall and re-install it? If so: Anything I should delete manually because it might be left over from the deinstallation? Or are there any logs etc. you'd want me to check first?
Hardware: Sony Xperia X
OS: Sailfish 2.1.3.5
Component: collectd Reproducible: reliably (changed from "not reliably" to "reliably" as the factor is time; it will happen, but only after a few minutes)
Sometimes when I run SystemDataScope, after a while collectd will show up in the output of top as using 100% of a CPU. When this happens, I try to stop it using the SystemDataScope settings. (I don't really know if unchecking "run collectd" and accepting the new settings from there is supposed to do the trick; anyway, that's what I try.) In this situation, when I try to close the SystemDataScope UI right after I left the settings page, SailfishOS tells me that the application doesn't respond and gives me the choice to either wait or kill it. Waiting doesn't help, so I switch off the phone to get rid of both collectd and SystemDataScope reliably.
I've not been able to identify a pattern and to reliably reproduce the issue. If I remember correctly, though, in all 3 cases I left the SystemDataScope UI up and running while I put the phone aside and let it go to sleep eventually. I cannot recall a collectd related issue when the SystemDataScope UI wasn't up.