Archive for the 'sysadmin' Category

Speed up Your SSH Connections for Free

Wednesday, August 8th, 2012

Adding the following directives to your .ssh/config should reduce your SSH connection establishment time significantly:

        ControlMaster auto
        ControlPersist yes
        ControlPath "/tmp/ssh-c-%r@%h:%p"

This works by having all SSH sessions sharing a single “control” connection.

The ControlMaster auto directive tells OpenSSH client to start a control master if one is not already running, otherwise it will reuse a previous one.

The ControlPersist yes directive tells the control master process to continue running in the background even though you’ve exited from the session, allowing subsequent sessions to reuse its connection.

The ControlPath is the control socket rendezvous point for masters and slaves. If you’re on a shared host, you might want to set it to a private location such as in your ~/.ssh/ directory instead of /tmp.

In my case, I stuck these into the wildcard Host section:

Host *
        Compression yes
        ServerAliveInterval 60
        ServerAliveCountMax 5
        ControlMaster auto
        ControlPersist yes
        ControlPath "/tmp/ssh-c-%r@%h:%p"

I’ve always known that OpenSSH had this functionality, but hadn’t bothered to try it out until now and it’s sooo very handy!

httpd exited on signal 11 – solved

Sunday, July 4th, 2010

tl;dr

It’s probably mod_php, and try recompiling PHP without zend_multibyte. If you have WITH_MULTIBYTE=true in /var/db/ports/php5/options, change it to WITHOUT_MULTIBYTE=true and rebuild the port.

Long Story

The Apache 2.2 processes on my FreeBSD box keep dying intermittently, with messages such as:


Jul 3 08:08:37 yama kernel: pid 13526 (httpd), uid 80: exited on signal 10
Jul 3 08:25:58 yama kernel: pid 33050 (httpd), uid 80: exited on signal 11

I’ve googled around and tried various extensions.ini reordering tricks without luck. Eventually, I figured out how to get Apache to dump core. First, you need to tell Apache where to dump core by adding the CoreDumpDirectory directive to your httpd.conf. Restart apache.

Then, check to make sure that the kern.coredump and kern.sugid_coredump sysctl variables are set to 1. Because Apache calls setuid and setgid to the configured user after listening on port 80 (privileged port), FreeBSD by default will refuse to dump core on segfaults. Setting kern.sugid_coredump will make it do so.


$ sysctl kern.coredump
kern.coredump: 1
$ sysctl kern.sugid_coredump
kern.sugid_coredump: 0
$ sudo sysctl kern.sugid_coredump=1
kern.sugid_coredump: 0 -> 1

Of course, you’d also need to make sure that your ulimit doesn’t prevent it from dumping core:


$ ulimit -c
unlimited

Great! Now wait for Apache to segfault (or, if you have a reproducible test case, hit it!)

You should now find httpd.core in the directory that you configured in httpd.conf (in my case, it is /tmp.)

Do the usual gdb stuff:


$ gdb /tmp/httpd.core /usr/local/bin/httpd

In my case, I found zend_multibyte_read_script near the top of the stack, so it’s pretty clear that PHP is to blame.
Did I mention that I abhor PHP? Someday I will get rid of it entirely!

This led me to more googling and found that I may have accidentally enabled Zend Multibyte support (well, its purpose is not very well documented and I just assumed that since I do lots of i18n work, it’ll come in handy. Okay so it’s my fault after all but it still shouldn’t crash!)

Changing WITH_MULTIBYTE=true to WITHOUT_MULTIBYTE=true in /var/db/ports/php5/options and rebuilding the port made the problem go away.

Hopefully, the above will help someone in a similar situation.