Zeeky

5. Ok, now search for "user_frame" (without the inverted commas). You should see something like this:

Save the file and proceed to Step 2.

[root@ensim1 virtual]# find . -name mqueue -exec du -hsc {} \;
.
..
4.0k ./site10/fst/var/spool/mqueue
4.0k total
77G ./site11/fst/var/spool/mqueue
77G total
64k ./site12/fst/var/spool/mqueue
64k total
..
.
^C

[root@ensim1 virtual]# cd site11/fst/var/spool/mqueue
[root@ensim1 mqueue]# ls -lah
.
.
-rw------- 1 root mail 38MB Sep 11 14:19 dfh8B6Jpa13658
-rw------- 1 root root 38MB Sep 11 14:49 dfh8B6nsJ21407
-rw------- 1 root mail 38MB Sep 11 14:57 dfh8B6vFi23054
-rw------- 1 root root 38MB Sep 11 15:51 dfh8B7pAN03118
^C

[root@ensim1 mqueue]# ls -lah |grep 38MB |wc -l
2074
[root@ensim1 mqueue]#

This command will help you find the current culprit sites that are holding up the space. Then you can just delete away the queues. But, becarefull about deleting legitimate queues. You may want to delete only those which are huge in size.

Now, issue the following commands:

[root@ensim1 root]# cd /home/virtual
[root@ensim1 virtual]# for i in `sitelookup -a domain`;do if [ -s /home/virtual/$i/etc/mail/local-host-names ];then /bin/fixmqueue.sh $i;fi;done;

This command will convert all the /var/spool/mqueue directories of all the sites currently hosted for the system to save the queue files owned as the siteadmin user of the corresponding sites. This will prevent the system from saving the unnecessary queues as 'root' and wasting space.

The idea is to setgid the /var/spool/mqueue directory of the virtual site. By doing so, files saved in the mqueue directory will automatically be owned by the admin of the site thus restricting the mail queue space to the site's quota.

In order to save the queues as the siteadmin of the sites, the sendmail.cf of the site needs to be modified. By default ensim runs the sendmail for any or all sites as the user 'mail'. So, when it saves the queues it saves them as root:mail. To alter this to siteadmin:siteadmin, the "O DefaultUser=mail:mail" setting in sendmail.cf needs to be changed to "O DefaultUser=siteadmin:siteadmin". This is exactly what the above script does. The script above actually creates a backup of the sendmail.cf before it can make the changes. I used Perl to modify the sendmail.mc because I personally find it more convenient than 'sed' to modify files on the fly.

This script will automatically setgid the /var/spool/mqueue directory of any newly created site in both Ensim Basic and Pro (3.1.x and 3.5.x).

It can also be downloaded from: http://zort.org/codes/bash/ensim/virtDomain.sh.var-spool-mqueue

A zombie is already a dead process. No wonder it could not be killed eh? To put it in more elegant words, I found this explanation online:

> When I run top, I have a zombie process (it's a cron job that does my
> nightly backup) running and I need to kill it. I have tried kill -9
> , but it doesn't work. Any ideas? Thanx.

should do it. This works because if a process dies (e.g. crond) then init (process 1) inherits its children and init will do the wait correctly.

If your process table is showing an abnormally high number of defunct processes, and if the problem recurs even after rebooting, it is advisable to determine the cause. Look at the PPID (parent process ID) for the defunct processes and try to find out why its child processes are becoming defunct. Examining the process table (ps -elf), grepping for the parent process in the rc scripts, and making use of utilities such as u386mon or cpqmon should help.

Most likely the process has gone to sleep at a priority below PZERO, therefore signals will never reach the process and it will remain unkillable.

For further explanation of what this means, read the following.

To start with, processes run in two modes: user mode and kernel mode. When a process is in user mode it responds to interrupts and signals. When a process in user mode receives an interrupt, or a signal or makes a system call, it goes through a call gate to enter kernel mode and executes the kernel code (see fig. 1).

Once a process is in kernel mode it ignores all interrupts and signals until it is about to return to user mode. Most kernel functions execute quickly, and upon exiting kernel mode, they handle all interrupts and signals. After running for a maximum of one second, the process is preempted and is returned to the runqueue. Since kernel functions execute quickly this is not typically the cause of unkillable processes. To understand this, it is necessary to go into more detail about what goes on in kernel mode.

The following diagram (fig. 2) will be useful in understanding the details of what goes on in kernel mode. You may wish to print it out. A similar, easier to read, version of this diagram can be found on the cover of Maurice Bach's book _The Design of the UNIX Operating System_.

When a process is in kernel mode it may do a number of things. The first possibility is that it will just run some kernel code. In this case it will quickly run the code and then return to user mode or, if the program has finished, it will exit. Immediately after exiting a process is what is called a "zombie". Typically this will show up on your ps as a process. Usually the process that started this process (the parent) will clean up after the zombie (the now dead child process). If the parent has already exited then init will eventually clean up this zombie process.

Sometimes a process needs some resources that are not available at the time. If this is the case, the process is put to sleep. When a process goes to sleep it waits on an address and at a priority. This address is the value that appears in the field WCHAN when ps(C) is run with the -l option. This address is determined by the device driver that has been called and is typically the address of a local variable in the device driver.

If the process is sleeping at priority above PZERO, which is defined in /usr/include/sys/param.h, and the process receives a signal, the process is put back in the runqueue, and when it is run it returns to user mode. As it returns to user mode the signal is handled, and if a kill -9 has been sent, the process is killed.

If a process is sleeping at a priority below PZERO, signals will not cause the process to be woken up. The priority that a process sleeps at is determined by the device driver that has been called. The device driver should only put a process to sleep below PZERO if it is certain that the resource will be freed quickly so that the process can be woken up. If the process that you are trying to kill is sleeping below PZERO it will only be woken up when the resource it was waiting for has been freed. Once the process is woken up, it is put back on the run queue, and when it gets to run and as it returns to user mode, the signals are handled. If the process is never woken up by the driver the signals will never reach the process and it will remain unkillable.

The only other reason a process may be unkillable is if the process is being ptraced. The kernel will only ptrace a process on the behalf of a user process. Ptraces are for the most part only performed by debuggers.

In unix-like operating systems, ALL processes (apart from the first one) are created by other processes. To create a new process, a current process does a fork(2) system call. The kernel then creates the internal structures needed in the process table. Often, the parent process does a wait4(2) system call, which means it waits for the child process to finish. This means you can get a little info about the process after it finished, like cpu time, etc.

If you don't care when the process finishes, you have to explicitly say so, otherwise the kernel will keep the info in the process table expecting your process to eventually call wait4(2) or a similar function. A process that has finished (and so is using no memory) but has not yet been "reaped" is called a Zombie, and the kernel is keeping its process table entry alive.

Two ways to avoid creating Zombies (other than calling one of the wait() functions) include:

1. handling the SIGCHLD signal
   


2. fork(2) and then get the child to fork(2) again and then exit immediately, so that you've created a grandchild rather than a child.