WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: lack of inotyfid in busybox  (Read 3640 times)

Offline vinnie

  • Hero Member
  • *****
  • Posts: 1187
  • HandMace informatic works
lack of inotyfid in busybox
« 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?

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14754
Re: lack of inotyfid in busybox
« Reply #1 on: July 25, 2021, 11:44:52 AM »
libnotify and/or notification-daemon?

Online Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11514
Re: lack of inotyfid in busybox
« Reply #2 on: July 25, 2021, 12:01:19 PM »
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 :
Code: [Select]
        -f              Print data as file grows

Offline vinnie

  • Hero Member
  • *****
  • Posts: 1187
  • HandMace informatic works
Re: lack of inotyfid in busybox
« Reply #3 on: July 25, 2021, 12:39:52 PM »
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?

Offline vinnie

  • Hero Member
  • *****
  • Posts: 1187
  • HandMace informatic works
Re: lack of inotyfid in busybox
« Reply #4 on: July 25, 2021, 12:42:57 PM »
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 :
Code: [Select]
        -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?

Online Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11514
Re: lack of inotyfid in busybox
« Reply #5 on: July 26, 2021, 12:29:19 AM »
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.
« Last Edit: July 26, 2021, 08:46:49 AM by Rich »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11026
Re: lack of inotyfid in busybox
« Reply #6 on: July 26, 2021, 02:37:58 AM »
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.
The only barriers that can stop you are the ones you create yourself.

Offline vinnie

  • Hero Member
  • *****
  • Posts: 1187
  • HandMace informatic works
Re: lack of inotyfid in busybox
« Reply #7 on: July 27, 2021, 01:54:37 PM »
@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.
)