Hi,
As the title says, I connect my android device and I start adb and after a short while the desktop freezes and then reboots.
Anyone has similar issues? Any ideas what to do?
I checked I have latest android tools that are in fedora repo (35.0.2-13..) but can’t help but notices there is new version on android site (36) and the version of adb is also quite old (at least 2024) there.
What do you have in journalctl for the time period of you plugging in your device and the machine rebooting.
Hopefully the disks are fsync’d before the reset…
What am I looking for. Simply perusing I don’t see anything suspicious.
I am trying to check it live. Now I connected the phone again. No issue in the logs… yet
I see a lots of:
Mar 25 12:57:59 fezzes-are-cool python3[2237]: Possibly lost 31 samples
Mar 25 12:57:59 fezzes-are-cool python3[2237]: Possibly lost 2 samples
Mar 25 12:57:59 fezzes-are-cool python3[2237]: Possibly lost 1 samples
Mar 25 12:57:59 fezzes-are-cool python3[2237]: Possibly lost 2 samples
But that is probably unrelated?
Dunno - we don’t know what causes the reboot, so anything that looks related to you plugging in an android phone and presumable firing up adb.
Feel free to replicate the reboot issue and then post the last n minutes or so of the journal output for the offending session.
Doubtful that python causes the reboot but I’ve no idea what “fezzes-are-cool” actually is.
no idea what “fezzes-are-cool” actually is
that is the name of the computer 
Feel free to replicate the reboot issue and then post the last n minutes or so of the journal output for the offending session.
Ok I will try
Should have clocked that from the position in the output. I normally have --no-hostname in there to reduce the size of pastes.
Aha, thanks for the tip!
Btw it happened just now, but logs are empty for about 30 seconds before it happened until the system starting again 
Bugger. that was my fear.
You can increase the frequency of systemd’s logger by adding SyncIntervalSec=1 to /etc/systemd/journald.conf.
Ok I will try that, thanks!
Just remember to remove it at the default is 5 minutes, according to the man page.
Ok, sadly these logs are the last before the reboot just now and the freeze and the reboot happened I think about 20-30 seconds after that.
Mar 25 13:38:15 systemd[1]: Starting systemd-tmpfiles-clean.service - Cleanup of Temporary Directories...
Mar 25 13:38:15 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Mar 25 13:38:15 systemd[1]: Finished systemd-tmpfiles-clean.service - Cleanup of Temporary Directories.
Mar 25 13:38:15 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 25 13:38:15 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Also it seems to be happening during different things. Sometimes I was listing packages with the ADB. Sometimes I was removing packages when it happened, but other times I was e.g. in the browser searching info about commands or packages (while being connected to the phone with ADB but doing nothing).
Does it occur if you have adb running with no phone connected (I’m wondering if the BIOS is causing a restart, because it doesn’t like something on the USB port, in which case we’ll never see anything in the kernel logs)
Does it occur with the phone plugged in but no adb running operational?
Good points, I will have to test it later and let you know, thanks a lot for helping me troubleshoot.
Only guess work Paul. Making stuff up as we go along! 
(I had a dodgy SATA cable once that would either cause timeouts on a disk, read/write errors where there were none or the entire machine would just reboot. Took weeks to track it down, as the connector was bad, the cable looked fine and I couldn’t reproduce the issue at will). one cheap SATA cable replacement later and the machine was rock solid.)
Any help appreciated! 
Haha I also already had several fights with bad cables, whenever something like this happenes I always try different cables and different ports
Okay, so I don’t need to have the phone connected. It happened again now and the only thing I did was adb start-server. It took about 15 minutes maybe. Is there a memory leak or something?
Also yesterday after all the testing I did, I have suspended the computer and when I wanted to wake up it didn’t. So I hard turned it off. When I returned to it later it didn’t want to turn on, it looked like memory training but nothing happened for half an hour. After another hard turn off it started and no other issues were perceived for normal work/use.
Interesting.
You can rule memory out (or in!) by firing up the adb server and running sudo memstrack. Might need to be installed from the repos, I don’t think it’s standard out of the box.
You can optionally apply a --throttle parameter to only show stuff using a substantial amount of memory, and whilst it can run without a tui and just generate a report file, it’ll write that to disk, and we know what can happen to disk files when the OS vanishes in the blink of an eye.
Fire it up alongside the adb server and hurry up and wait for a repeat performance - do you see anything sucking up more and more memory to cause the OOM handler to start killing stuff? If not, then it’s probably not memory starvation.
edit: could also, of course, just use btop/htop/insert top of choice, if you’re more familiar with them
Ok, it doesn’t look like a leak, memory and even processor are stable when it happens.
So it’s sitting there. looking normal… you’re doing nothing interesting other than watching it look normal and then… pop - reboot?
and if you don’t start an adb server, then it’s absoltuely fine?