Well today is a glorious day as I finally managed to fix a problem that had been haunting my server for a month or so.  In the end it was a solution that I’ve been taught countless times as something I should be doing by default when upgrading php but alas my mind is not on of the more expensive models and so it rarely does what it should..

So it all started with a fairly minor issue I noticed in WordPress.   When I would try to load up the media gallery I would be greeted with a nice 502  Nginx error.  I’m sure if I wasn’t running nginx then it would have a blank white page or an apache error.  So naturally I started with the nginx error logs which didn’t lead to much.. Then I setup php to log all errors and again that didn’t lead me to much, finally however I monitored my httpd-error.log and this lovely message turned up:

[warn] (2)No such file or directory: Cannot reinit SSLMutex
/libexec/ld-elf.so.1: /usr/local/lib/php/20060613/gd.so: Undefined symbol “zend_parse_parameters_none”

After some asking around on irc I was told that it was definitely a php problem.  Nothing more specific than that, just a php problem.  There were a bunch of forum posts saying it might have something to do with fastCGI but all the suggestions had no effect.  However there was one forum I foudn that through a suggestion out there that lit up a light bulb in my brain.  That being that if php5-extensions isn’t recompiled and reinstalled when php is updated sometimes the fit hits the shan.  Sure enough I had upgrade php5 a while back, and then again since then but hadn’t bothered to recompile the extensions.  Hell I hadn’t even recompiled Zend or Eaccelerator which is pretty standard.

So long story slightly shorter, I went in deinstalled and cleaned up my php5-extensions, reinstalled it and viola, problem solved!!

Well this was a jolly good problem that took 4 hours to fix.

I’ve implemented the Audio Module this week to allow our Sound team to upload soundtrack, foley and effects work just the same as the 2D and 3D guys upload their work.  Unfortunately when I went to upload a 40MB .ogg file the connection to the server was reset pretty much exactly after 60 seconds.  So, easy enough I figured I’d just have to go into my php.ini file and change the max upload sizes, max connection times and all of that fun stuff.  Well I went through and changed every conceivable directive in there that had anything to do with connection times and upload sizes.  Nada!  I created .htaccess files in the /drupal dir with php_values to the same effect.. Nada!  I went to one of my wordpress blogs and tried to upload the same file and guess what?  SAme thing happened, re-assuring me that this wasn’t a drupal only problem.  So I tried increasing the Timeout value in apache, nada.  Got onto IRC on #php and no one had a clue.  Hours and hours of googling led to ZERO solutions.  It wasn’t until I decided to try this in Opera instead of Firefox that I was able to get a glimmer of understanding as to what was going on.  Just to once again re-iterate how much better of a browser Opera is than firefox, how exponentially better in every conceivable way except for compatability, Opera is compared to firefox, it took me 30 seconds to figure out and solve this problem once I had opera loading the pages.  Instead of just sending me a nebulous Server Connection Reset error after 60 seconds like FF did, Opera immediately spat out a 413 Error ‘Entity too large’.  Why Firefox didn’t touch on client_max_body_size 300M;

this at all, ever is beyond me but it was a simple matter of going into  my nginx.conf file and “setting client_max_body_size” to 300M and the problem was solved.

Sooo, if you are experiencing a Connection reset error while trying to upload files and you just happen to be running Nginx go and check out your nginx.conf file and make sure client_max_body_size is set nice and high.

If you are having troubles compiling FFMPEG and are seeing errors with LibGL such as:

No package ‘x11-xcb’ found

You need to do a few things.

Firstly upgrade X11: portupgrade libX11. This has been noted to solve a lot of problems so do this first, retry and see if it fixes it.

This however might fail in which case you are going to need to upgrade xproto first as X11 will look for a later version of Xproto than might already be on the server. doing a simple portupgrade might not work so:
So cd /usr/ports/x11/xproto & make clean & make deinstall & make reinstall

now you should be able to go into /usr/ports/x11/libX11 and:
make clean & make deinstall & make reinstall

and now finally LibGL will install properly and consequentially so will FFMPEG

So after running into this problem suddently and for no ‘apparent’ reason(although it became apparent later) I noticed the complete lack of real support docs online in regards to the ALSA underrun problem.  Hopefully I can rememdy this a little bit and help some people out.

Last week I noticed skype audio was getting really choppy, it was the equivalent of seeing the conversation through a strobe light.  Odd I thought but didn’t pay it too much heed, that was until the end of the week when the audio simply stopped all together and skype refused to close down normally.  I would have to manually kill the process in terminal after the sound cut out.  This problem was exclusive to skype, which made it even more frustrating as I could have youtube and/or music playing in exaile while skype was screwing the pooch.

It occured to me today that something indeed had been changed recently right before this problem started and that was me fiddling with pulse’s daemon.conf and enabling real-time scheduling.  I can’t remember what for but this was part of the problem.  In fact there is even a mention in pulseaudio’s man page in regards to the possibility of real-time scheduling causing problems which I’ll quote here:

Alternatively,  if the risk of locking up the machine is considered too
big to enable real-time scheduling,  high-priority  scheduling  can  be
enabled  instead  (i.e.  negative  nice  level). This can be enabled by
passing –high-priority (see above) when starting  PulseAudio  and  may
also  be  enabled  with  the approriate option in daemon.conf. Negative
nice levels can only be enabled when  the  appropriate  resource  limit

RLIMIT_NICE  is  set  (see setrlimit(2) for more information), possibly
configured in /etc/security/limits.conf. A resource limit of 31 (corre‐
sponding with nice level -11) is recommended.

At this point I got a little excited as the solution seemed within reach.  I hashed out real-time schedule and implemented high-priority scheduling, restarted pulseaudio and loaded up skype.  It started fine but when I made a test call I was once again plagued by ALSA underruns.

They key here was to adjust the nice level.  I incrementally went down from -11 all the way to 3 (as in plus 3 not -3), restarted pulseaudio, loaded skype and viola!  Problem solved.  The nice level might be different for you so maybe experiment with that a little bit.

Summary:

• edit ~/.pulse/daemon.conf (or /etc/pulse/daemon.conf if you run as system)
• Hash out realtime-scheduling and realtime-priority
• Unhash high-priority and nice-level
• set nice level to 3 (not -3 or -11 for that matter)

Update:  Bah, I am still seeing these under runs.  The severity of them has gone down as skype doesn’t completely cut out now and lock up but I am getting audio cutting in and out every 2-3 seconds when making a call via skypeout.

Searching around the skype forums I found this and this actually seems to have done the trick completely:

Edit your ~/.asoundrc file

# Part I directly from ALSA Dmix Wiki

pcm.skype {
type dmix
ipc_key 1024
slave {
pcm “hw:0,0″
period_time 0
period_size 1024
buffer_size 8192
#format “S32_LE”
#periods 128
rate 44100
}
}

pcm.dsp0 {
type plug
slave.pcm “skype”
}

# This following device can fool some applications into using pulseaudio
pcm.dsp1 {
type plug
slave.pcm “pulse”
}

ctl.mixer0 {
type hw
card 0
}

pcm.pulse { type pulse }
ctl.pulse { type pulse }
pcm.!default {
type pulse
}

ctl.!default {
type pulse
}