0

For testing purposes I called procmail by my .forward file

|/usr/bin/procmail

and by the rules in .procmailrc it started a job named "start", which was simply an infinite loop

while true
do
 date>>logfile
 sleep 300
done

To my surprise this job (or anything else related to procmail or .forward) does not appear as a separate process in the output of ps -ef (not as my own process and not as that of anybody else), so I cannot kill it and it writes one timestamp each 5 minutes into the log. Even deleting the shell script does not work, obviously it is already in memory and does not need to be read again. Now I thought, at least the job will terminate after a reboot, but it didn't. The only thing I can do for stopping the output is making the logfile unwritable to all, but even then the job continues to run (I see it when I make the file readable again).

Now my question is: How can I kill this script as non-root user? Or if not at all: What did I do wrong? How do I have to call a script by procmail to show up in the ps-output and (more important) to make it killable for me?

I have no root access to the machine, but I have physical access, so I can restart it. The OS seems to be x86_64-suse-linux, uname -a shows Linux 3.11.10-7-default #1 SMP. My shell is bash.

@Anthon: mailq shows an empty mail queue. Renaming start, .procmailrc and .forward does not change anything.

@EightBitTony:

nameofpc:~ > ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Apr24 ?        00:00:13 /sbin/init showopts
root         2     0  0 Apr24 ?        00:00:00 [kthreadd]
root         3     2  0 Apr24 ?        00:00:00 [ksoftirqd/0]
root         5     2  0 Apr24 ?        00:00:00 [kworker/0:0H]
root         7     2  0 Apr24 ?        00:00:00 [migration/0]
root         8     2  0 Apr24 ?        00:00:00 [rcu_bh]
root         9     2  0 Apr24 ?        00:00:00 [rcuob/0]
root        10     2  0 Apr24 ?        00:00:00 [rcuob/1]
root        11     2  0 Apr24 ?        00:00:00 [rcuob/2]
root        12     2  0 Apr24 ?        00:00:00 [rcuob/3]
root        13     2  0 Apr24 ?        00:00:11 [rcu_sched]
root        14     2  0 Apr24 ?        00:00:07 [rcuos/0]
root        15     2  0 Apr24 ?        00:00:04 [rcuos/1]
root        16     2  0 Apr24 ?        00:00:04 [rcuos/2]
root        17     2  0 Apr24 ?        00:00:03 [rcuos/3]
root        18     2  0 Apr24 ?        00:00:01 [watchdog/0]
root        19     2  0 Apr24 ?        00:00:01 [watchdog/1]
root        20     2  0 Apr24 ?        00:00:00 [migration/1]
root        21     2  0 Apr24 ?        00:00:00 [ksoftirqd/1]
root        23     2  0 Apr24 ?        00:00:00 [kworker/1:0H]
root        24     2  0 Apr24 ?        00:00:01 [watchdog/2]
root        25     2  0 Apr24 ?        00:00:00 [migration/2]
root        26     2  0 Apr24 ?        00:00:00 [ksoftirqd/2]
root        28     2  0 Apr24 ?        00:00:00 [kworker/2:0H]
root        29     2  0 Apr24 ?        00:00:01 [watchdog/3]
root        30     2  0 Apr24 ?        00:00:00 [migration/3]
root        31     2  0 Apr24 ?        00:00:00 [ksoftirqd/3]
root        33     2  0 Apr24 ?        00:00:00 [kworker/3:0H]
root        34     2  0 Apr24 ?        00:00:00 [khelper]
root        35     2  0 Apr24 ?        00:00:00 [kdevtmpfs]
root        36     2  0 Apr24 ?        00:00:00 [netns]
root        37     2  0 Apr24 ?        00:00:00 [writeback]
root        38     2  0 Apr24 ?        00:00:00 [kintegrityd]
root        39     2  0 Apr24 ?        00:00:00 [bioset]
root        40     2  0 Apr24 ?        00:00:00 [kblockd]
root        41     2  0 Apr24 ?        00:00:00 [ata_sff]
root        42     2  0 Apr24 ?        00:00:00 [md]
root        44     2  0 Apr24 ?        00:00:00 [khungtaskd]
root        45     2  0 Apr24 ?        00:00:00 [kswapd0]
root        46     2  0 Apr24 ?        00:00:00 [ksmd]
root        47     2  0 Apr24 ?        00:00:01 [khugepaged]
root        48     2  0 Apr24 ?        00:00:00 [fsnotify_mark]
root        49     2  0 Apr24 ?        00:00:00 [crypto]
root        54     2  0 Apr24 ?        00:00:00 [kthrotld]
root        55     2  0 Apr24 ?        00:00:00 [scsi_eh_0]
root        56     2  0 Apr24 ?        00:00:00 [scsi_eh_1]
root        57     2  0 Apr24 ?        00:00:00 [scsi_eh_2]
root        58     2  0 Apr24 ?        00:00:00 [scsi_eh_3]
root        59     2  0 Apr24 ?        00:00:00 [scsi_eh_4]
root        60     2  0 Apr24 ?        00:00:00 [scsi_eh_5]
root        68     2  0 Apr24 ?        00:00:00 [kpsmoused]
root        72     2  0 Apr24 ?        00:00:01 [kworker/0:1H]
root        73     2  0 Apr24 ?        00:00:00 [deferwq]
root       114     2  0 Apr24 ?        00:00:00 [kmpath_rdacd]
root       141     2  0 Apr24 ?        00:00:00 [khubd]
root       151     2  0 Apr24 ?        00:00:00 [kworker/1:1H]
root       152     2  0 Apr24 ?        00:00:00 [kworker/2:1H]
root       154     2  0 Apr24 ?        00:00:00 [kworker/3:1H]
root       220     2  0 Apr24 ?        00:00:00 [jbd2/sda5-8]
root       221     2  0 Apr24 ?        00:00:00 [ext4-rsv-conver]
root       222     2  0 Apr24 ?        00:00:00 [ext4-unrsv-conv]
root       260     1  0 Apr24 ?        00:00:11 /usr/lib/systemd/systemd-journald
root       261     2  0 Apr24 ?        00:00:00 [kauditd]
root       296     1  0 Apr24 ?        00:00:00 /usr/lib/systemd/systemd-udevd
root       381     2  0 Apr24 ?        00:00:00 [irq/46-mei_me]
root       382     2  0 Apr24 ?        00:00:00 [hd-audio0]
root       387     2  0 Apr24 ?        00:00:00 [kvm-irqfd-clean]
root       426     2  0 Apr24 ?        00:00:00 [jbd2/sda7-8]
root       427     2  0 Apr24 ?        00:00:00 [ext4-rsv-conver]
root       428     2  0 Apr24 ?        00:00:00 [ext4-unrsv-conv]
root       430     2  0 Apr24 ?        00:00:00 [jbd2/sda9-8]
root       431     2  0 Apr24 ?        00:00:00 [ext4-rsv-conver]
root       432     2  0 Apr24 ?        00:00:00 [ext4-unrsv-conv]
root       438     2  0 Apr24 ?        00:00:01 [jbd2/sda6-8]
root       439     2  0 Apr24 ?        00:00:00 [ext4-rsv-conver]
root       440     2  0 Apr24 ?        00:00:00 [ext4-unrsv-conv]
avahi      624     1  0 Apr24 ?        00:01:38 avahi-daemon: running [fphct03.local]
root       625     1  0 Apr24 ?        00:00:00 /sbin/rpcbind -w -f
nscd       628     1  0 Apr24 ?        00:00:07 /usr/sbin/nscd --foreground
message+   631     1  0 Apr24 ?        00:00:10 /bin/dbus-daemon --system --address=systemd: --
root       642     1  0 Apr24 ?        00:00:04 /usr/lib/systemd/systemd-logind
root       644     1  0 Apr24 ?        00:00:07 /usr/local/natinst/nisvcloc/bin/nisvcloc -D
root       647     1  0 Apr24 ?        00:00:03 /usr/sbin/rsyslogd -n
root      1233     1  0 Apr24 ?        00:00:00 /usr/sbin/sshd -D
root      1241     1  0 Apr24 ?        00:00:01 /usr/sbin/ypbind -n -no-dbus
root      1246     2  0 Apr24 ?        00:00:00 [rpciod]
root      1247     2  0 Apr24 ?        00:00:00 [nfsiod]
root      1255     1  0 Apr24 ?        00:00:00 /usr/sbin/rpc.gssd -D -p /var/lib/nfs/rpc_pipef
root      1261     1  0 Apr24 ?        00:00:00 /usr/sbin/rpc.idmapd -p /var/lib/nfs/rpc_pipefs
root      1264     2  0 Apr25 ?        00:00:00 [kworker/u8:2]
root      1276     2  0 Apr24 ?        00:00:00 [nfsv4.0-svc]
root      1298     1  0 Apr24 tty1     00:00:00 /sbin/agetty --noclear tty1 linux
ntp       1319     1  0 Apr24 ?        00:00:11 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u n
root      1351     1  0 Apr24 ?        00:00:00 /usr/bin/kdm
root      1395     1  0 Apr24 ?        00:00:29 /usr/bin/python /usr/sbin/denyhosts --daemon --
root      1437     1  0 Apr24 ?        00:00:00 /usr/lib/postfix/master
root      1450     1  0 Apr24 ?        00:00:00 /usr/sbin/cron -n
postfix   1460  1437  0 Apr24 ?        00:00:00 qmgr -l -t fifo -u
root      1633     1  0 Apr24 ?        00:00:02 /usr/lib/upower/upowerd
polkitd   1638     1  0 Apr24 ?        00:00:09 /usr/lib/polkit-1/polkitd --no-debug
root      1678     1  0 Apr24 ?        00:00:41 /usr/lib/udisks2/udisksd --no-debug
rtkit     1748     1  0 Apr24 ?        00:00:02 /usr/lib/rtkit/rtkit-daemon
root      1777     1  0 Apr24 ?        00:00:00 /usr/lib/bluetooth/bluetoothd
root      1789     1  0 Apr24 ?        00:00:00 /usr/lib/systemd/systemd-hostnamed
root      1979  1351  0 Apr25 tty7     00:00:48 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth /v
root      1987  1351  0 Apr25 ?        00:00:00 -:0
kdm       1988  1987  0 Apr25 ?        00:02:09 /usr/lib64/kde4/libexec/kdm_greet
root     17533     2  0 Apr26 ?        00:00:00 [kworker/u8:1]
root     21461     2  0 08:20 ?        00:00:00 [kworker/2:1]
root     22873     2  0 12:10 ?        00:00:00 [kworker/1:1]
postfix  23129  1437  0 12:47 ?        00:00:00 pickup -l -t fifo -u
root     23171     2  0 12:50 ?        00:00:00 [kworker/2:2]
root     23266     2  0 13:05 ?        00:00:00 [kworker/3:1]
root     23300     2  0 13:11 ?        00:00:00 [kworker/0:2]
root     23393     2  0 13:20 ?        00:00:00 [kworker/3:2]
root     23407     2  0 13:22 ?        00:00:00 [kworker/0:0]
root     23428     2  0 13:26 ?        00:00:00 [kworker/1:0]
root     23481  1233  0 13:34 ?        00:00:00 sshd: myuserid [priv]
myuserid    23484     1  0 13:34 ?        00:00:00 /usr/lib/systemd/systemd --user
myuserid    23485 23484  0 13:34 ?        00:00:00 (sd-pam)
myuserid    23486 23481  0 13:34 ?        00:00:00 sshd: myuserid@pts/2
myuserid    23487 23486  0 13:34 pts/2    00:00:00 -bash
root     23547     2  0 13:35 ?        00:00:00 [kworker/2:0]
root     23561     2  0 13:35 ?        00:00:00 [kworker/0:1]
myuserid    23595 23487  0 13:37 pts/2    00:00:00 ps -ef
nameofpc:~ >

@tripleee: .procmailrc (yes, I know that there is some garbage in) was something like

# .procmailrc
# routes incoming mail to appropriate mailboxes
PATH=/usr/local/bin:/usr/bin:/bin
MAILDIR=$HOME/.mailspool   # all mailboxes are in .mailspool/
#DEFAULT=$HOME/.mailspool/mbox
DEFAULT=/var/spool/mail/myuserid
LOGFILE=/dev/null
SHELL=/bin/bash
{
:0
* ^From myemail@myexternalfreemailprovider\.com
{
 :0
 | /home/myuserid/start >/dev/null
}
}

If you ask why I need this: I want to make sure each time I get mail at my external freemail account, that a job (let's call it payload.sh) on the host (which has no cron and no at) is run once every 6 hours. So I forward the mail from my external mail account to the host, where procmail starts my script "start" each time a new mail arrives. And in "start" I would check if an earlier "start" script is still running. If yes, then exit the new, second "start", if not (probably due to a shut down of the host), then "start" will call payload.sh every 6 hours. If you know a simpler solution for this problem then feel free to write it here.

  • Have you looked at the mailq for the user, it could be that old mail re-initiates the script once it is being resend, although it shouldn't if you have removed/changed your .forward and .procmailrc. – Anthon Apr 25 '14 at 11:30
  • "Now I thought, at least the job will terminate after a reboot, but it didn't." - yes it did, something has restarted it. Paste the output of a ps -ef please. – EightBitTony Apr 25 '14 at 12:41
  • What did your .procmailrc look like? – tripleee Apr 28 '14 at 8:52
  • If your mail is arriving on a different host which had your $HOME mounted (or vice versa), the process is still running there. A quick glance at your Received: headers of a recent incoming message should reveal where Procmail is actually running. See also web.archive.org/web/20070813144716/http://partmaps.org/era/mail/… – tripleee Apr 28 '14 at 8:56
  • tripleee, I added the .procmailrc and a comment to it above. I think you are right. Thank you for your answer. The mail seems to arrive on a different host, but I have no access to this host. So I hope the jobs will finish once this other host will reboot. But still the question: Do you know how to kill such a procmail-job running on another host? Maybe by sourcing in a second shell script during each run through the loop? – user66131 Apr 28 '14 at 23:37
0

As unearthed in the comment thread above, the explanation is that Procmail runs on a different host than the one you are logged into. Typically, this happens when the admins have decided that they want the mail delivery host separate from regular production machines etc. One common arrangement is that the mail delivery host has your home directory NFS-mounted so that it can deliver messages where you can read them, but otherwise a separate local file system which users do not have access to (but read on...)

If you have login access to the mail handling host, simply log in to it and kill the unwanted process.

If you don't have login access, you can run arbitrary pieces of code on the mail handling host by adding a script to your .procmailrc and sending yourself an email which triggers the condition for running this code.

For example,

:0
* ^Subject: secret sauce
| ps -wallx >ps.out

(Obviously, use a different trigger so that others cannot trivially mess with your experiment.)

Once this triggers, you should have what you need to change the action to a kill command with the PID of the process you want to terminate.

(And once you are done, you will want to clean out this recipe from your .procmailrc.)

Paranoid admins don't like the fact that Procmail can do this. Doing "creative" things with this facility will likely result in Procmail being banned, or you being thrown out. Use with care.

  • If you are lucky, the mail host has cron even though your regular machine doesn't; but abusing this is probably crossing the line of "creative". – tripleee Apr 29 '14 at 7:21
  • Yes, the mailhost has...;-) And this would be the best not only for me but also for the mailhost, so I would not call it abuse. No additional processes running within the six hours period, no procmail necessary after installing the final crontab, no email forwarding necessary, so less load on both machines. If it is allowed to start a process on the mailhost by an external procmail trigger then it should not be forbidden to start the same process much easier by a crontab file. Maybe I will go this way. If not I will try the watch command. Thanks a lot for your kind help, tripleee. – user66131 May 5 '14 at 22:36

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.