grep hanging there doing nothing indicates the file does not “return” any data.
Such as you might simulate with
mkfifo myfifo; grep foo myfifo ; rm myfifo # <-- grep hangs waiting for data coming through the pipe.
grep foo /dev/zero # <-- grep hangs because /dev/zero dev-zeroes
(DO remove that myfifo file after testing, many programs do not like named unconnected pipes hanging around.)
Quite possible some of the weird files under /sys do something like this.
Also I suspect it is possible that there are infinite symlink loops under /sys which would also look like a hang. strace -e file will tell, and grep being in a loop should show quite some CPU/IO usage.
A fifo would explain it and is not unlikely. I have to admit, I still don’t get the point of the exercise And I like fifos and all, but will probably concentrate on making them for websockets
I think the only thing we learned from my end is that it doesn’t cause a kernel panic and a reboot on Volla?
Thank you @nephros for pointing to some reasons why grep may “hang”. Because for me (while testing the original topic) grep does not consume any CPU time when it hangs, it is likely similar to your “named pipe”-case example: The file content is inaccessible.
But as @poetaster repeatedly insisted, we should not get sidetracked and focus on reproducible SailfishOS reboots triggered by grepping or other means of reading files.
Knowing now, that the offender apparently is in a directory after /b*/, but before /sys/, I was able to narrow it down to:
fgrep -rsc foo /d/ > /dev/null # Always ends in rebooting the SailfishOS device
But /d/ does not contain any dot files or directories!?!
So what could cause the difference in behaviour? Note tat the hanging state can be explained by the many special files in subdirectories of /d/ and is not the point: What is triggering a reboot is the question of interest.
Now I am confused, but will stop for today.
debug_read_status() is from drivers/usb/gadget/u_serial.c in the kernel sources, see Index of /sources/4.0.1.48/ (Jolla where are the sources for 4.3 ?) and the kernel-adaptation tarball.
in this function there are various accesses done to members of structures referenced by a pointer, namely ui_dev, tty and gser. We can discard tty since it is protected by a if (tty) whenever used. If I assume that ui_dev is properly defined, I end up with gser that may be NULL. Looking here and there in the file, it seems that it could be the case and its various usages are all protected. But not in here. There is a if (gser->get_dtr) that should have been if (gser && gser->get_dtr).
I’ve no idea where to submit a patch for kernel adaptation. Moreover, I even don’t know how to test this hypothesis because I’ve no idea how to recompile a kernel for my JollaC. And even if I know, I’ve no idea how to put it properly on the phone and recover in case it’s not working. I’ll ask on IRC #sailfishos-porter channel.
It would, but the root directory ("/") and all its top level directories ("/*") should contain no files and directories starting with a dot (".").
The actual difference is the order in which the directories are processed, exacerbated by the fact that grep freezes when processing certain files; thus it does not reach the critical file triggering the reboot.
/usb* sure yields nothing (because there is no such directory IMHO), but what about a grep -Frsc bla /d/?
If that does not make your device reboot, you may continue looking for the offending file (or a different cause, though I assume that to be unlikely), while the search has ended for dcaliste (Jolla C) and me (Xperia X).
Well, I assume the diverging results mostly originate from everybody is testing with different commands (and thus testing different things).
So @ric9k, @poetaster, @nephros, does a grep -Frsc bla /d/ # (please use exactly this command)
really not trigger a reboot on your devices?
And if it does not, does grep not return to the command prompt (that is the exact criteria for “to hang”) without using CPU (see top in a second window).
P.S.: @Inte, reading which file does trigger the reboot on your device?
You might use for determining this a
I did grep -Frsc bla /d/ | tee grep-Frsc-bla and both console output and the teed file hang hang for a while at the place below, and a couple of other places, but then continue after a couple of seconds:
That file being called a “pipe” makes me suspicious, is this supposed to act as a kind of fifo, producing data only after enabling some kind of trace? That would explain why grep doesn’t get anything.
The file itself looks like a regular file, but probably debugfs doesn’t have real fifo or other special files.
In general I wonder why the kernel debugfs (so /d/) is mounted at all in “production” devices. It is done by sys-kernel-debug.mount and sys-kernel-debug-tracing.mount, but why?
@nephros, @poetaster, thank l you for testing. Well, if the (ab-)used utility for triggering the reboot hangs, it cannot get to the file which triggers a reboot.
Thus my strategy was to omit the locations which cause hangs repeatedly (by placing the start of the search after them, again and again), which is how I ultimately determined that file triggering the reboots for the Xperia X and Jolla C.
IMO you both became side-tracked into researching the “hangs” again, which is not the original question, albeit an interesting one.
I do like the question @nephros raises, because if there is no real reason (other than convenience for developers) and we can show that this bears some dangers on most devices (hence my insisting on testing), the logical consequence is to ask Jolla and SailfishOS porters to switch it off:
P.S.: BTW, the “pipe” / “FIFO” file(s) you both observed are just what is commonly called “named pipe” on UNIXes. I can see why one might employ that for debugging purposes.
As another sidetracking side-node, you can’t simply stop the mount service or unmount the tracing fs. But you can compile trace-cmd and use trace-cmd stop or reset to stop all traces, and then umount it.
And I like fifos and all, but will probably concentrate on making them for websockets