This morning our server at work is dog slow. It appears that the nightly updatedb process has collided with an rsync that’s taking ages. Both processes wanting to use lots of disk IO is making the machine cranky.
I don’t really mind if updatedb takes a long time, so long as it stays out of the way. A simple solution to this is to renice updatedb. Something to keep in mind is that the updatedb process more than just one process; it’s updatedb + find + sort + frcode (some locate command). So, how can one renice the entire stack? One way is to dig out the PID of each process; another way is to use the process group.
I found out that when a process is started, it creates a process group. Anything that process forks/executes is also in this process group. You can use this command to determine the process group:
ps -eHo "%p %P %r %n %c" | less
The third column will contain the process group id; then it’s simply a matter of running:
Doing this is simple using Emacs’ macros. Type C-x ( to start defining the macro. Then, when it comes time to insert the digit, enter C-x C-k C-i. The next time you run the macro, the number will be incremented.
Say you need to add a zero-padded number. Enter C-x C-k C-f and use the typical printf string formats like %03d.
When you need to reset the counter, use C-x C-k C-c and enter in the start value.
Finally, if you need to repeat a number, use C-u C-x C-k C-i.
In the source directory under contrib/completions there is a bash completions directory. After sourcing that file you can then git <tab> <tab> and get all the git commands. You can also setup $PS1 to show you what branch is currently active with:
export PS1='[...]$(__git_ps1 "(%s)")[...]'
Make sure you use single quotes on the outside or it won’t work.
At some point I mistyped my google login and the username field always showed me the wrong one and the right one. Turns out you can prune out the form by arrowing down to the wrong entry and hitting shift+delete!
Here’s a nice trick to zero out a file that’s in use:
cat /dev/null > /path/to/file
The reason for this is that if you simply remove a file that’s in use by some process on the system, the disk space will not be released until the process closes the file or terminates.
By cating /dev/null and redirecting it to the file, it magically guts out the contents of the file while keeping the same inode. The process that has that file open will continue writing to it without knowing any better, and the disk space will be released.
Update: A simple test using python to keep a file handle open showed me that while the cat trick zeros out the file, python keeps track of the last position written to within the file. The next time the python process writes to the file, you’ll end up with null bytes at the beginning of the file.