Fork Bomb!

June 3, 2011

A few days ago I had to deal with my first ever real-life fork-bombed server.

By logging in to the console, I was somehow able to get a shell (one process). Having got that shell, even though I was root, it was difficult to be able to spawn other processes. It turned out that this was because we had restricted the CPU count on the kernel command line (maxcpus=2) so that a dual processor, 16-core machine had only one eighth of its processing power available. The dynamic change to the nproc value does not take this into account, so this unprivileged user was able to fork-bomb the entire machine.

The first thing you might want to do in this situation is to run ps -eaf. That’s another process, and even as root, you don’t get to do it. Being Linux, you can see how many processes exist on the system by listing /proc:
cd /proc
echo *

Neither of these commands spawn a new shell, they are both shell builtin commands, so they will work. In this case, with over 69,000 processes, I killed the output before I got too bored. Since there are usually around 200 processes running, that was enough to tell me that something was wrong.

After many attempts, a ps command did work, and confirmed that a certain shell script was being run a lot of times. I couldn’t cat that file, and didn’t even have its full name (ps truncates output to match the terminal’s width). I had the PID, so /proc/$PID/fd gave the filename.

It’s not possible to cat the script to see what it’s doing, so more builtin commands are required.
$ while read f
> do
> echo $f
> done < /path/to/script.sh

This uses all builtin commands, and tells you what the script is. From there, you may have some insight into what it is doing, and how to stop it.


Shell Scripting Recipes – Expert Ingredients for Linux, Bash and more

May 29, 2011

Another update on the upcoming Shell Scripting Recipes book. The writing is complete, the editing formatting and reviewing is now almost totally complete. In the meantime, Amazon’s UK discount has dropped to £4.80; Amazon.com is still offering a whopping $19.76 (40%) off the pre-order price. The trend seems to be that the prices are going back upwards towards the list price as the launch date (12th August 2011) comes closer so you may save more by ordering a copy now.

The full chapter list is at http://sgpit.com/book/ along with links to other pages with more details about the book.


Update on Shell Scripting Recipes book

April 23, 2011

Wow, it’s been nearly two months since I last made a post about the upcoming book on shell scripting. I’m really sorry, I had intended to give much more real-time updates here. The book focusses on GNU/Linux and the Bash shell in particular, but it does cover the other environments too – Solaris, Bourne Shell, as well as mentions for ksh, zsh, *BSD and the rest of the Unix family.

In terms of page count, it is currently 89% finished. There is still the proof-reading to be done, and whatever delivery details the publishers need to deal with, so the availability date of some time in August is still on schedule. I notice that http://amzn.com/1118024486 is already offering a massive discount on the cover price; I have no idea what that is about, I’m trying not to take offence – they can’t have dismissed the book already as I have not quite finished writing it yet! So hopefully you can get a bargain while it’s cheap.

The subject matter has the potential to be quite boring if presented as a list of tedious system administration tasks, so I have tried to make it light and fun whenever I can; it’s still with Legal at the moment, but I hope to have a Space Invaders clone written entirely in the shell published in the book. People don’t tend to see the Shell as being capable of doing anything interactive at all, so it is nice to write a playable interactive game in the shell. The main problem in terms of playability is in working out how much to slow it down, and at what stage! Of course, being a shell script, you can tweak the starting value, the level at which it speeds up, and anything else about the gameplay. If the game doesn’t make it in to the book, I’ll post it here anyway, and will welcome your contributions on gameplay.

Other than games, I’ve got recipes for init scripts, conditional execution, translating scripts into other (human) languages, even writing CGI scripts in the shell. There is coverage of arrays, functions, libraries, process control, wildcards and filename expansion, pipes and pipelines, exec and redirection of input and output; this book aims to cover pretty much all that you need to know about shell scripting without being a tedious list of what the bash shell can do.

There is a status page at http://sgpit.com/book which also has order information; you can pre-order your copy from there.


Shell Scripting Recipes

March 3, 2011

This is just a heads-up that my Shell Scripting Recipes book is due out in August 2011.

I hope to publish more details here as things progress; for now, it is well on the way, but it is not too late for readers to contact me (steve@steve-parker.org) if there is anything that you see as vital for a Shell Scripting Recipes book which was maybe missing from some other book you saw.

http://amzn.com/1118024486
Shell Scripting Recipes by Steve Parker

Part I covers Language and Usage; all of the concepts of the Shell and how it works.
Part II is Recipes using System Tools. This covers the commands that are necessary for shell scripting, and includes quite a few surprising ways to use them.
Part III is Recipes using Shell Features. This is similar to Part II but it gives concrete uses for the theory presented in Part I.
Part IV is Recipes for Systems Administration. This provides (and explains) various recipes for real-world systems administration tasks of and beyond the ordinary.

I do intend to keep you appraised of progress; you can also follow my personal blog at http://steve-parker.org/urandom/ for more detailed updates. The RSS feed for that blog is http://steve-parker.org/urandom/rss.php.


lsof, fuser, nohup, disown, bg, fg, and jobs

February 4, 2011

Bit of a cheeky one here – what does anybody want to know about these topics?

There is a book in the pipeline, and I have lots to say about all these things, but am very interested to hear what you think is easy / hard / intuitive / arcane / stupid about these commands and the whole job control side of Unix/Linux and the different shells.

lsof is great, but almost only GNU/Linux; fuser is good, but restricted in how much it actually tells you – you have to go digging into PIDs to see what has to be KILLed or otherwise dealt with.

What, oh faithful few who may still be following this terribly intermittent blog, do you want to see on the subject of processes and job control in the *nix shell?


2010 in review

January 2, 2011

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

Featured image

A helper monkey made this abstract painting, inspired by your stats.

About 3 million people visit the Taj Mahal every year. This blog was viewed about 26,000 times in 2010. If it were the Taj Mahal, it would take about 3 days for that many people to see it.

The busiest day of the year was November 9th with 142 views. The most popular post that day was Simple Maths in the Unix Shell.

Where did they come from?

The top referring sites in 2010 were steve-parker.org, google.com, google.co.in, ubuntuforums.org, and rackerhacker.com.

Some visitors came searching, mostly for bash maths, suid bit, shell script timestamp, awk one liners, and bash field separator.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

Simple Maths in the Unix Shell January 2007
12 comments

2

Timestamps for Log Files March 2007
4 comments

3

suid shell scripts – setting “the SUID bit” April 2007
5 comments

4

IFS – Internal Field Separator September 2007
10 comments

5

Calculating Averages March 2007
7 comments


inodes – ctime, mtime, atime

October 7, 2010

http://www.unix.com/tips-tutorials/20526-mtime-ctime-atime.html has a really good explanation of the different timestamps in a Unix/Linux inode. GNU/Linux has a useful utility called “stat” which displays most of the inode contents:
$ stat .bashrc
File: `.bashrc'
Size: 3219 Blocks: 8 IO Block: 4096 regular file
Device: fe00h/65024d Inode: 33 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ steve) Gid: ( 1000/ steve)
Access: 2010-10-07 01:11:21.000000000 +0100
Modify: 2010-08-19 21:22:20.000000000 +0100
Change: 2010-08-19 21:22:21.000000000 +0100
$

As Perderabo explains in the above-linked post:

Unix keeps 3 timestamps for each file: mtime, ctime, and atime. Most people seem to understand atime (access time), it is when the file was last read. There does seem to be some confusion between mtime and ctime though. ctime is the inode change time while mtime is the file modification time. “Change” and “modification” are pretty much synonymous. There is no clue to be had by pondering those words. Instead you need to focus on what is being changed. mtime changes when you write to the file. It is the age of the data in the file. Whenever mtime changes, so does ctime. But ctime changes a few extra times. For example, it will change if you change the owner or the permissions on the file.

Let’s look at a concrete example. We run a package called Samba that lets PC’s access files. To change the Samba configuration, I just edit a file called smb.conf. (This changes mtime and ctime.) I don’t need to take any other action to tell Samba that I changed that file. Every now and then Samba looks at the mtime on the file. If the mtime has changed, Samba rereads the file. Later that night our backup system runs. It uses ctime, which also changed so it backs up the file. But let’s say that a couple of days later I notice that the permissions on smb.conf are 666. That’s not good..anyone can edit the file. So I do a “chmod 644 smb.conf”. This changes only ctime. Samba will not reread the file. But later that night, our backup program notices that ctime has changes, so it backs up the file. That way, if we lose the system and need to reload our backups, we get the new improved permission setting.

Here is a second example. Let’s say that you have a data file called employees.txt which is a list of employees. And you have a program to print it out. The program not only prints the data, but it obtains the mtime and prints that too. Now someone has requested an employee list from the end of the year 2000 and you found a backup tape that has that file. Many restore programs will restore the mtime as well. When you run that program it will print an mtime from the end of the year 2000. But the ctime is today. So again, our backup program will see the file as needing to be backed up.

Suppose your restore program did not restore the mtime. You don’t want your program to print today’s date. Well no problem. mtime is under your control. You can set it to what ever you want. So just do:
$ touch -t 200012311800 employees.txt
This will set mtime back to the date you want and it sets ctime to now. You have complete control over mtime, but the system stays in control of ctime. So mtime is a little bit like the date on a letter while ctime is like the postmark on the envelope.

This is a really clear, thorough explanation of ctime and mtime. Unfortunately, it is not possible to find the original creation time of a file, though that is somewhat meaningless as things are copied, moved, linked, changed; what is the creation time of a file which was created, removed, then created afresh, for example?