killall - All bark and no bite? Why does killall not kill at all.

It's a rare occurrence that I kill processes on my Linux boxes. Processes exit or close normally. The odd time Firefox on my desktop, or Apache on a server needs an extra kick.

killall is a handy utility for finding the process IDs of all processes matching your specification and killing them. If you have 4 Firefox instances running, you don't need to find their process IDs in your process tree and laboriously kill each one. You just issue the command killall firefox

However, you'll have noticed it doesn't always kill a process, and some folks tend to blame killall. This is most likely due to the fact they didn't RTFM.

The default killall operation issues a SIGTERM to the process. Once the process receives the notice, it should clean up and exit. But if your process has crashed or has run away, it will never receive the notice or it's completely ignored. killall does not live up to it's name sake. One by one you start issuing kill -9 commands....

When you issue the kill command the appending '-9' infroms kill to send a SIGKILL, and this is the key point. We need to tell killall to send SIGKILL and not the polite SIGTERM.

So you can use:

> killall -s SIGKILL firefox

or

> killall -9 firefox

You should not however issue kill -9 or killall -9 unless your processes have not responded to the SIGTERM command. You should always attempt to shutdown application gracefully.

Recompile PHP with bundled GD library

When a security issue or bug is discovered in a library, the issue can be fixed easily. The library package is rebuilt, redeployed, and all the applications that use it are protected from the issue. When bundling is allowed, the distro needs to find all the packages the library was bundled with. All of those packages need to be fixed. You shouldn't assume an upstream maintainer is plugging security issues. There are several other technical reasons that I won't cover here, but you get the idea. 

How does this affect your web server?

So there's no bundled libraries in Debian or Ubuntu. Debian policy does not build packages with embedded copies of 3rd party code. Due to upstream syncing issues, package maintainer animosity, and Debian policy, GD sources used for libgd in Debian are missing certain functions.

If you happily installed PHP with GD using apt-get install php5-gd you should be aware the following functions are missing

    function imageantialias
    function imagecolormatch
    function imageconvolution
    function imagecreatefromxbm
    function imagecreatefromxpm
    function imagefilter
    function imagelayereffect
    function imagerotate
    function imagexbm

Galleries, images, and photos will suddenly disappear from your web-pages. Errors logs will start to fill up with messages similar to this one:

PHP Fatal error:  Call to undefined function imageantialias()

How can I fix undefined function errors?

Recompile PHP. Don't fret, this is straight forward in Debian.

Install build tools required to compile source code
> apt-get install build-essential debhelper fakeroot

Obtain the PHP source code
> cd /usr/src
> sudo apt-get source php5

Install all dependencies required to build PHP5
> sudo apt-get build-dep php5

Build the package
> cd php5-x.x.x (replace 'x' correct version number)
> sudo dpkg-buildpackage -rfakeroot

This will take some time, treat yourself to a refreshment
When the .deb is compiled, traverse back a folder.
> cd ..

Install the required package*
> sudo dpkg -i php5-gd_5.x.x.x.deb

*Don't forget to restart apache.

Be a good administrator, hold that package

You've customized your current package and you don't want to overwrite it, no matter what. Holding a package informs the package manager to retain the current installed version. The next time you run apt-get update and apt-get upgrade you won't overwrite all of your hard work.

Using dpkg
> sudo echo php5-gd hold | dpkg --set-selections

Using apt
> sudo sudo apt-mark hold php5-gd