grep'n'dash

So you somehow have gotten in to the position that you have a file called '-f' containing various strings and one of those strings managed to be '-lookatme!' which is exactly what you need to find. The subtleties of combining the UNIX shell and commands sometimes both confuse and surprise users with unexpected output. Finding these neat tricks will help you understand the intricacies of your *NIX system.

So here is our absurdly named file:

> ls -la
total 32
-rw-r--r--   1 will sysadmin      80 Apr 18 11:08 -f
drwxr-xr-x   3 will sysadmin    4096 Apr 18 11:08 .
drwxr-xr-x   3 will sysadmin    4096 Apr 18 09:50 ..

And look at what's inside:

> cat ./-f
string1
string2
string3
string4
string1
string2
-lookatme!
string3
string4
-end

In this very basic example we want to find the string '-lookatme!'. Using grep we must escape the '-' character in the string we are looking for:

>grep "\-lookatme!" ./-f
-lookatme!

Or we can wrap the filename around double-quotes:

>grep "\-lookatme!" "-f"
-lookatme!

You can even search an entire directory for that ridiculous string:

>grep "\-lookatme!" *
-f:-lookatme!

Binding Solaris processes

Sometimes you may need to bind a particular process to a CPU so it gets all the resources it needs. This is done two simple commands:

psradm -i 1

First we disable interrupts on the above process and makes it available for LWP handling. Since the CPU will be needed only for the particular process we assign it we don't need to worry about network or I/O interrupts.

pbind -b 1 2222

Here we bind process ID 2222 to CPU 1.

To view current bindings use:

pbind -q

And finally to unbind any specific process:

pbind -u <PID>  (pbind -u 2222 for our process above)

Solaris 10 maximum TCP connections

We have quite a few servers whose applications rely on very fast TCP connections. Thousands of ports are open and closed every minute all internally. Although nothing like a large scale website it still is something to deal with. Our Solaris 10 servers came with 128 connections max per port. An issue we saw with when an otherwise quiet server had an increased amount of traffic to it connections were failing. The server hit it's maximum number of connections per port (128 for us) and wouldn't receive anymore until a port freed up. Unfortunately the server CPU and memory usage hit the roof and slowed down the OS and any running applications. So when the application on the client side told the server to close the connection, the server asked the application holding the port open if it can close it but under load the application was unable to respond. The server slowed down to a halt and well production chaos!

So to alleviate this we increase the maximum connection amount to 4192 which gave us plenty of room for now:

ndd -set /dev/tcp tcp_conn_req_max_q 4192