Project 1 Setup: Forkbomb+VM

If you can't, or simply don't want to, run the project VM on your equipment, you can use a combination of CSE machines. The primary machine is forkbomb, which is dedicated to this course. As its name implies, we have a machine because of the threat of runaway fork'ing - a fork bomb that clogs the machine with processes. The primary symptom of a fork bomb is that you are effectively locked out of your account: because you've exceeded your per-user process limit, you can't start any new processes, including the one needed to kill all those runaway ones causing the problem. That's one downside of forkbomb relative the running in the VM.

Additionally, no one is going to let you boot your own kernel on a shared CSE machine, so we need something other than forkbomb to test your kernel. We'll use the same VM as we'd use for all project 1 work, except that you'll be able to run it on a lab, Windows workstation and its contents are reinitialized every time you quit VMware Player.

Basic forkbomb Setup

This project needs a lot of disk space, more than your home directory probably provides. On forkbomb you have a dedicated working directory in a place that has "lots of space". Your directory is:

/cse451/<login_name>

For example, my directory is /cse451/zahorjan.

Note that this directory is not backed up. You can/should copy your files to your home directory, on a schedule that you deem prudent. (Your home directory is mounted on forkbomb, and is in fact your home directory there.)

If your shell implementation has a bug and goes into a loop creating processes, you will exceed the per-user process limit. At that point, you can't execute commands in the existing shell, nor ssh into forkbomb to get a new shell, because those things require starting a process.

To guard against that, if you're using bash¹ the command:

ulimit -u 16

will limit the total number of processes the current shell (or any of its children) can fork to 16. Then, should a fork bomb go off, you can use another shell to kill it:

killall myprog.exe

where you should use the name of your executable as the killall argument.

Execute

tar xzf /cse/courses/cse451/11sp/linux-2.6.38.2-CSE451.tar.gz

in your /cse451/xxx directory. Enter the directory that was created (linux-2.6.38.2). To build the kernel, say

make -j 2 bzImage

When that completes, you should find the file ./arch/x86/boot/bzImage has been created.

You need to run Vmware Player on a lab Windows machine and then open the course virtual machine.

• Copy /cse/courses/cse451/11sp/FC13-CSE451-2011-04-09.tar.gz to somewhere you have at least 17GB of disk space - most likely, the local machine.
• Un-tar it.
• Start VMware Player and point it at the .vmx file in the directory you just created.
• Boot the VM.

You should now be able to communicate with the VM through host only networking. If that fails, it might be a configuration issue with the lab workstations:

• Bring up the Network Control Center, either through the desktop GUI (Start -> Control Panel -> Network and Sharing Center -> Change Adapter Settings) or by typing "ncpa.cpl" into the Run prompt.
• Right click on VMWare Virtual Ethernet Adaptger VMnet1, and then select Enable.

For user account names/passwords on the VM, see the VM setup page.

• Fetch the .../linux-2.6.38.2/arch/x86/boot/bzImage file you built on forkbomb to the local machine.
• Use host only networking to move it onto the VM.
• Overwrite the existing 2.6.83.2 kernel with your bzImage, e.g.,

  sudo mv ~/bzImage /boot/vmlinuz-2.6.38.2-CSE451

• Reboot the VM

Q: Is there any way for a user to kill the set of processes in a
fork infinite loop themselves (or is the only recourse to send
mail to support)?

A: If the process runs away, and consumes all of their allowed
process slots, there's nothing they can do.  However, they can
run their assignment in a shell window with a lower process limit
so that they can kill the runaways in the other shell.  Basically:

Open 2 sessions to forkbomb.

In ONE of the sessions issue the command: "limit maxproc 64" (or an
even lower number). Then run your code from that session. This will
give you at least 64 free process slots in the other session to be
able to kill any runaways.

If using bash use "ulimit -Su 64" or a lower number.