Tiny Core Linux
Tiny Core Base => Corepure64 => Topic started by: vinnie on July 25, 2021, 11:21:09 AM
-
Some time ago I created a script that observed the changes of a file in the system using busybox inotifyd. But in the version of tinycore this program seems to be missing, what should I use instead?
-
libnotify and/or notification-daemon?
-
Hi vinnie
Checking TC4, 9, and 10 I don't see busybox ever including inotifyd.
... observed the changes of a file ...
Maybe you were thinking of tail -f :
-f Print data as file grows
-
libnotify and/or notification-daemon?
I think the second, to be clear, this:
https://busybox.net/downloads/binaries/1.31.0-i686-uclibc/busybox_INOTIFYD
Downloading this binary, it already work in tinycore as is, but why it is not already included in tinycore?
-
Hi vinnie
Checking TC4, 9, and 10 I don't see busybox ever including inotifyd.
... observed the changes of a file ...
Maybe you were thinking of tail -f :
-f Print data as file grows
Thanks Rich, but in this case my file is a lock file, so I have to check if it get erased or not.
I know that I can do it with other commands but it seems less elegant.
Is there a way to check instead that a process is always active?
-
Hi vinnie
... Is there a way to check instead that a process is always active?
If you know the PID for the process, you can check for the existence of /proc/PID/. If the process terminates, that
directory will no longer exist.
You could also check /proc/PID/status.
The State: field gives the current state of the process, including "T (stopped)", "Z (zombie)", etc.
The voluntary_ctxt_switches: and/or nonvoluntary_ctxt_switches: fields should be incrementing if the program is running.
Then there's /proc/PID/status.
The first field is the CPU run time of the process in nanoseconds. That number increments while the process runs.
-
Downloading this binary, it already work in tinycore as is, but why it is not already included in tinycore?
Our busybox build is not intended to be "everything on". It's also configured to only contain things used by the base and those commonly required otherwise.
-
@Rich
Thanks Rich, the idea to use inotifyd is because in theory (I haven't tested) it's more efficient than doing a loop, and in fact instead of checking the file I had thought to check just /proc/[pid] however I found out that inotify can't check those files because they are not real files.
@curaga
I mistakenly thought busybox was small enough to be included completely.
Maybe it might be an idea to add a package to the repository called the_rest_of_busybox :P
(
However I currently have solved the problem differently.
I needed to check a lockfile because (again going back to the docker parenthesis), when vscode closed the window for some reason the container was killed.
Then I realized that checking the lockfile was not reliable because after a sudden close it would not be deleted, so I wanted to check the pid.
But in the end I preferred to occupy the process with a menu with a read pending which surely occupies less resources than anything else.
)