boltblog

Pausing and continuing a process on Linux

Posted on February 25, 2012

If you want to pause a process while you do something else, like for instance stop a heavy file operation while you're just moving some stuff around quickly, there are two signals to pay attention to: STOP and CONT.

STOP will pause a process (not actually stop it - it doesn't die)
CONT continues a stopped process, and does nothing if the process isn't stopped.

An easy way to experiment with this is to start xeyes:

$ xeyes &
[1] 26114

In this case, xeyes got the Process ID (PID) 26114. You can use "ps" to find Process ID's of running processes.

Xeyes is an application that shows two "eyes" on the screen, with eyeballs following your mouse pointer around.

To pause this process I use, in my case "kill -STOP 26114". Notice the eyes stop moving to follow the mouse pointer. "kill -CONT 26114" resumes the application.

 

Filed under: Howto's, Linux No Comments

Linux on Mac Mini – power on after power loss

Posted on February 17, 2012

The Mac Mini doesn't save this information in its BIOS (or equivalent), so you need to set it on each boot. I use my distribution's /etc/rc.local file for this.

Either way, these are the commands to run (copy, and uncomment the correct line for your Mini):

## PPC Mac Mini
#echo server_mode=1 > /proc/pmu/options

## Intel Mac Mini
#setpci -s 0:1f.0 0xa4.b=0

## nVidia Mac Mini
#setpci -s 00:03.0 0x7b.b=0x19

## Unibody Mac Mini
#setpci -s 0:3.0 -0x7b=20

gitolite: ‘foo’ does not appear to be a git repository – ForceCommand

Posted on January 11, 2012

Many people seem to get the following error message when trying to manipulate a remote git/-olite repository:
fatal: 'foo' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

The problem here, which is absolutely not explained by the above error message, is likely to be that the remote command gitolite specifies in "~/.ssh/authorized_keys" is not used.

This can in turn be caused by two things, as far as I know:

  • You are using an ssh key which appears in the authorized_keys file without gitolite's "command=..." configuration, in which case the solution is to use a separate public/private key pair for git
  • Your SSH server has a ForceCommand directive in sshd_config (/etc/ssh/sshd_config on debian) which overrides the "command=..." setting in authorized_keys. To solve this, that directive has to go, or an exception needs to be added for your git user with a Match clause in sshd_config.

In the latter case, there does not seem to be any sane way to retrieve the contents of the "command=..." statement. While the user supplied command is available in the environment variable $SSH_ORIGINAL_COMMAND while using ForceCommand, the command supplied by authorized_keys seems nowhere to be found. Thus you need an exception for the ForceCommand directive. If you find another way to avoid this, please leave a comment below?

Creating .deb-Packages With Checkinstall

Posted on January 4, 2012

If you've exhausted all other options, it might be time to compile from source, even in Debian.

If you're about to do that though, don't abandon the concept of .deb files and the advantages they bring with versioning and easy removal. Use "checkinstall".

Checkinstall is in the standard Debian repositories and encapsulates your install into a nice, easily installable and distributable .deb file. apt-getting it and reading the manual is easy enough, but if you want a howto, falkotimme.com has a nice one, archived here as a PDF.

Filed under: Linux, Reference No Comments

UDP through SSH

Posted on October 5, 2011

http://zarb.org/~gc/html/udp-in-ssh-tunneling.html
Good. Archived for personal reference.

copy here

Filed under: Linux, Reference No Comments

Fixing “shmget() failed: No space left on device”

Posted on September 14, 2011

I had this happen when someone ran a script to kill x11vnc every so often, using kill -9 (don't ask).

Killing x11vnc with SIGTERM (15) allows it to clean up its shared memory segments. SIGKILL (9) will not.

Googling around, I found a script over here (backup copy here).

The problem with that was that it's aimed at being run as the user, and it only supports usernames up to 10 characters, because of how "ipcs -m" prints its entries on Linux.

I wanted a solution that supported any length of username, and that could be run periodically, by root, as a cronjob to clean up after silly users, and that would also give me a report when it cleaned something, so I could see who was causing this.

The result was this script. It only supports Linux, and thus is a bit less portable than the one at karlrunge.com, but it does the job, even with long usernames, and generates such nice reports:

Removed SHM Segments:
___________________________
|   OWNER    |   COUNT    |
|------------|------------|
| bolt       |         42 |
|____________|____________|

Total: 42

Oops...

EDIT:
Updated script, automatically synced with the one I'm actually using available here.

SSH in a while loop – stdin problems

Posted on September 12, 2011

When SSH is used with a line like "while read ....", the while loop will only run once.
This can be seen by running this simple example:

$ seq 1 10 | while read line; do ssh remotehostname "echo x${line}x"; done
x1x

You might expect this to connect to the host with the name "remotehostname" 10 times, and each time print one of the numbers in the sequence from 1 to 10. This will, however, not be the case. The result is a single line, saying "1".

Where did the rest of the numbers go? To the SSH process.
By default, SSH runs off with the stdin file descriptor, preventing "read" from reading anything else from it. You can see this by trying the following example:

$ seq 1 10 | while read line; do ssh remotehostname "echo x${line}x; cat -"; done
x1x
2
3
4
5
6
7
8
9
10

Now all the numbers were printed, but they were all in a single ssh connection. As you can see, only the number "1" got the X'es on both sides, indicating it was printed by the "echo" instruction. The rest of the numbers come from "cat -", which basically takes whatever comes in on SSH's stdin, and dumps it to the stdout (the screen, in this case). So that's where they went!

Now, how do you remedy this?

Answer: SSH's -n switch. From the manual:
-n Redirects stdin from /dev/null (actually, prevents reading from stdin). This must be used when ssh is run in the background. A common trick is to use this to run X11 programs on a remote machine. For example, ssh -n shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically forwarded over an encrypted channel. The ssh program will be put in the background. (This does not work if ssh needs to ask for a password or passphrase; see also the -f option.)

So let's try that with -n, shall we?

$ seq 1 10 | while read line; do ssh -n remotehostname "echo x${line}x; cat -"; done
x1x
x2x
x3x
x4x
x5x
x6x
x7x
x8x
x9x
x10x

There. 10 SSH connections opened, 1 number printed each time. A total waste of time, but a rather simple example to follow :)

Set php.ini values using .htaccess

Posted on September 10, 2011

Did you know that you can set php.ini values right inside the .htaccess file?
You can do so by adding lines like these:
#format
php_value setting_name setting_value

#example
php_value upload_max_filesize 128M

Filed under: Linux, Reference 1 Comment

GCC stray X in program

Posted on September 10, 2011

Problem:
IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn/pi.c:1: error: stray ‘\357’ in program

This is caused by "invalid" characters in the code, specifically I encountered this while trying to compile the Intel EMGD driver for my EEEPC's graphics card.

Thanks to the helpful folks over here, there's a solution:
cd IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn
cat -v pi.c | awk '{if(NR>1) print $0}' > tmp # make strange characters on first visible and remove
mv tmp pi.c

That makes the invalid characters visible and removes them.
In this case, it leaves some partial, garbage comments behind, so the file still wont compile.
To resolve this, I opened the file in vim, and quickly searched for and removed the faulty comments (and some I didn't have to remove).
Remember to answer "no" to the question of re-extracting the tarball each time you retry building this.
Attached is the original driver file, and my modified copy of pi.c

Result:
"Completed EMGD Installation"

Lin_EMGD_1_6_RC_1922
modified pi.c

xorg.conf for KVM

Posted on September 3, 2011

Found this somewhere.
Works for me.

Section "ServerLayout"
Identifier "BodhiZazen's KVM xorg.conf"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "Module"
Load "record"
Load "dri"
Load "extmod"
Load "glx"
Load "dbe"
Load "dri2"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "InputDevice"
Identifier "Mouse0"
Driver "vmmouse"
Option "Protocol" "SysMouse"
Option "Device" "/dev/sysmouse"
Option "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 20.0 - 50.0
VertRefresh 40.0 - 80.0
Option "DPMS"

EndSection

Section "Device"
Identifier "Card0"
Driver "vesa"
VendorName "KVM - std"
BoardName "GD 5446"
BusID "PCI:0:2:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Modes "800x600"
EndSubSection
EndSection

Filed under: Linux, Reference No Comments