Nfs – Find out what NFSD processes are actually doing

Commenting on the tooling.

We've tried online wiki's but found a number of limitations, which may be personal taste, but include document structure and most critically having to be connected to the documentation server.

Being connected is a serious problem if you are either offline or onsite (obviously you can mitigate the onsite with a secured SSL connection et. al.)

Our current documentation process is:

• static html generator
• markdown syntax
• distributed versioning system

We have a 'formal' layout for the documentation and that provides the structure for the menus (and the associated CSS for visual styling etc.)

Static HTML Generator

We use an in house static html generator based on cubictemp and a number of other tools: pygments, docutils.

The generated pages are (not?)obviously ugly looking, as most of us/our sysadmins/programmers know what is aesthetically beautiful but have a total lack of coordination into building such.

But it affords/let's us include configuration files, sample scripts, pdf, etc, without having to worry about html formatting screwing it up or worrying about where to find it on the 'server' for downloading.

If it's not HTML, just drop it in the folder and add a url link to it.

HTML provides 'potential' structure for layout, and also critically provides 'linking' between knowledge/content items (as well as base structure mechanisms, such as being able to create menus, table's of content etc.) With HTML, each user can now run a small web server on their machine whether lighttpd or something small or just go full blown with Apache or IIS.

All our machines have the grunt for basic html serving, and works well enough for us.

MARKDOWN syntax.

We use a bastardised version of MARKDOWN, Textish and or reStructuredTEXT to let our 'creative' juices write documentation without having to worry about HTML.

It also means everyone get's to use their favourite editor (I use Scintilla on Windows and *Nix) while the others here use vi/vim.

Distributed Versioning System.

We use Git to 'distribute' the documentation between users. Oh, and we use it's versioning capacity too.

The key advantage for us is that we can all work on updating the documentation without having to be connected to the server, and without having to publish 'completed' works. We can all work on the same parts of the documentation, or different parts, or just consume the information.

Personally, I hate being tied to a server to update blogs let alone wiki's. Git works well for us.

Commenting on the Workflow

Wiki's seem to be the "fashion" for knowledge dissemination / codification, but as commented elsewhere all processes become difficult to sustain, and finding the mix of tools that best supports your teams needs and is sustainable will take time.

The better solutions just end up being discovered and not mandated.

YOu can do this with a combination of ps , awk and kill:

ps -eo pid,etime,comm

Gives you a three column output, with the process PID, the elapsed time since the process started, and the command name, without arguments. The elapsed time looks like one of these:

mm:ss
hh:mm:ss
d-hh:mm:ss

Since you want processes that have been running for more than a week, you would look for lines matching that third pattern. You can use awk to filter out the processes by running time and by command name, like this:

ps -eo pid,etime,comm | awk '$2~/^7-/ && $3~/mycommand/ { print $1 }'

which will print the pids of all commands matching 'mycommand' which have been running for more than 7 days. Pipe that list into kill, and you're done:

ps -eo pid,etime,comm | awk '$2~/^7-/ && $3~/mycommand/ { print $1 }' | kill -9