A long time ago I copied/modified a script that used inotify to tell me the results of an automatic clamscan when something was downloaded to Downloads - I followed this online resource: https://fitzcarraldoblog.wordpress.com/2017/03/05/using-the-clamav-daemon-to-scan-files-placed-in-my-downloads-directory-in-gentoo-linux/.

My question: How do I find out what is executing this script, called clamscanInotify.sh?

Though the tutorial suggested using crontab, which I did and have since edited out of my crontab -e file, this script is still somehow being executed.

I have checked;

  1. my user's crontab,

  2. my root's crontab,

  3. all the cron.daily/weekly/etc,

  4. /etc/cron.d/

and cannot what is executing the script. I've looked in the journal using;

journalctl -b | grep cron

or for when I know the approximate time I downloaded something,

journalctl -b | grep -e "10:00" 

I've also just used grep to search for the string of the name of the executable - clamscanInotify.sh,

sudo grep -rnw / -e "clamscanInotify.sh",

but did not find the string anywhere, not even in /etc/.

I do not have at/atd daemon and I cannot think of what else to do to look for whatever is calling this executable script, clamscanInotify.sh.

It is also not in Linux Mint's "Startup Applications" selection using the GUI for the desktop.

I don't simply want to delete the *.sh file, but my screen and terminals filling up with zenity windows and messages is annoying.

Any ideas of where to look?


Here is a pic of my (h)top;

enter image description here

  • what's PID 8815 at this moment? – Jeff Schaller Nov 5 '18 at 21:50
  • you also have pid 2283 calling it – Jeff Schaller Nov 5 '18 at 21:51
  • It is "bash", the 2nd in hierarchy under "/usr/lib/gnome-terminal/gnome-terminal-server" – nate Nov 5 '18 at 21:52
  • sbh@sbh ~/ $ sudo ps -p 2283 PID TTY TIME CMD 2283 ? 00:00:22 gnome-terminal- sbh@sbh ~/ $ sudo ps -p 8815 PID TTY TIME CMD 8815 pts/2 00:00:00 bash – nate Nov 5 '18 at 21:54
  • So you want to find the "grandparent" of a process? Could that not be achieved with ps -o ppid= -p $PPID unless the currently running child (or its immediate parent) were double-forked and thus have PID one as their "foster grandparent"? Also there are alternatives to crond such as atd. Could it be that you ended up choosing one of those? – 0xC0000022L Nov 7 '18 at 9:00

The slow way would be to use PS: what does "ps -o comm= -p $PPID" do to capture the parent process(es) until you find something interesting.

Since you're using bash in the script, add:

ps -o pid=,comm= -p $PPID

and redirect that to a temporary file. Inspect the contents of that file and then inspect the parent tree; if, for example, that file contains:

8815 bash

then follow up with:

ps -o ppid=,comm= -p 8815

where here we're asking for process 8815's parent pid and command.

With a Linux system, insert pstree -s -p $$ to ask for the ancestry chain for the current process ($$).

At some point you'll end up with your desktop manager or whatever method you used to log in.

It's entirely possible that one of your bash initialization scripts is setting this up; I would borrow this answer, for example and run something like:

bash -ix </dev/null 2>trace

and then search the trace file for the inotify script in question. As the linked answer also says, the best initial guesses are:

  • ~/.bash_profile
  • ~/.profile
  • ~/.bash_login
  • /etc/profile
  • ~/.bashrc

... in which case you could try:

grep clamscanInotify.sh ~/.bash_profile ~/.profile ~/.bash_login /etc/profile ~/.bashrc
| improve this answer | |
  • okay thank you. I looked at stackoverflow.com/questions/685435/… but the first 4 I couldn't get to work - my fault I know. I'll start now... – nate Nov 5 '18 at 22:12
  • I had it called in ~/.bashrc (for some reason I don't know).... Thanks for all the help - I really liked learning it! – nate Nov 5 '18 at 22:37
  • 1
    Isn't it always the case -- you find it in the last place you look :) – Jeff Schaller Nov 5 '18 at 22:37
  • just a note, i realize grep missed the script name because it overlooked 'dot' files. adjusting shopt as in: unix.stackexchange.com/questions/264523/… – nate Nov 6 '18 at 2:27
  • 1
    True; it's not every day that you want to glob in dot-files; grep will see them if you list them explicitly (as I did), or if you use a glob that will pick them up, e.g. grep clamscanInotify.sh .[a-z]* – Jeff Schaller Nov 6 '18 at 2:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.