This week I’ve decided to exchange Redmine for the ChiliProject. The reason for this is the support for Ruby 1.9. My Apache Passenger server runs Ruby 1.9 so for Redmine I needed a seperate webserver.
When I tried to access the “My Account” page I recieved the following error:
ArgumentError (invalid byte sequence in US-ASCII):
passenger (3.0.7) lib/phusion_passenger/rack/request_handler.rb:96:in `process_request'
passenger (3.0.7) lib/phusion_passenger/abstract_request_handler.rb:513:in `accept_and_process_next_request'
passenger (3.0.7) lib/phusion_passenger/abstract_request_handler.rb:274:in `main_loop'
passenger (3.0.7) ...
passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:357:in `server_main_loop'
passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:206:in `start_synchronously'
passenger (3.0.7) helper-scripts/passenger-spawn-server:99:in `<main>'
Rendering /data/www/rails/chili/public/500.html (500 Internal Server Error)
How should I solve this? The chiliproject has an issue related to this: https://www.chiliproject.org/issues/591.
The following Apache configuration fixed the issue: (The sample is on a FreeBSD system)
I added the following code to a file in the /usr/local/apache22/envvars.d/environment.env
Problems I ruled out or fixed
While trying I also made sure the following things were configured:
I made sure the database is UTF-8. I re-created the database
an ran the migrations again.
create database chiliproject character set utf8;
I used the mysql2 connector instead of the mysql connector in database.yml
Are you trying to install / run Rails 3.1 on a FreeBSD system…?
make install clean
make install clean
Now it should work :-)
Yesterday I did a Ruby update of my Freebsd ports.
It mentioned Ruby needed to be updated. I always thinks this is Scary because I have several sites depending on the my Ruby installation.
You need to update once in a while, so I just upgraded it…
Today I saw my mysql-backup-cron Ruby script gave the following error:
mysql_backup.rb:3:in `require': no such file to load -- rubygems (LoadError)
from mysql_backup.rb:3:in `<main>
WTF. I tried to run a rake task of my Rails apps.. The same error…
The gems still seem work. The command below nicely showed my Gems.
After trying to reinstall the rubygems port which didn’t do a thing.
I found the solution was to REINSTALL RUBY completely.
make install clean
BTW. My Rails apps were not affected because they run in an RVM environment …
I’m a big fan of the FreeBSD port system. But the last few weeks
I had problems updating my freebsd ports.
A growing number of ports were giving the following error: “cc: /sbin:/bin:/…:/root/bin: No such file or directory”
A full sample:
libtool: link: cc -shared .libs/lqr_gradient.o .libs/lqr_rwindow.o .libs/lqr_energy.o .libs/lqr_cursor.o .libs/lqr_carver.o .libs/lqr_carver_list.o .libs/lqr_carver_bias.o .libs/lqr_carver_rigmask.o .libs/lqr_vmap.o .libs/lqr_vmap_list.o .libs/lqr_progress.o -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib -L/usr/local/lib /usr/local/lib/libglib-2.0.so /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin /usr/local/lib/libintl.so /usr/local/lib/libiconv.so /usr/local/lib/libpcre.so -lm -Wl,-soname -Wl,liblqr-1.so.3 -o .libs/liblqr-1.so.3
cc: /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin: No such file or directory
gmake: *** [liblqr-1.la] Error 1
gmake: Leaving directory `/usr/ports/graphics/liblqr-1/work/liblqr-1-0.4.1/lqr'
gmake: *** [all-recursive] Error 1
gmake: Leaving directory `/usr/ports/graphics/liblqr-1/work/liblqr-1-0.4.1'
gmake: *** [all] Error 2
*** Error code 1
After a lof of debugging and digging deeply in the /work directories of the broken ports. I found out
that libtool was generating a ‘wrong’ cc command. The part -L /sbin:/bin/usr/bin … etc was wrong. The path seperator ‘:’ should not be used. I thought libtool was broken. (Rule X pragmatic programmer: “SELECT Isn’t broken” ;-) )
After dinging deeply in this script I saw the $path variable was placed in this command…
After typing ‘set’ to see all environment variables I found out I defined a custom $path variable.
Probably by a typing mistake. Because the real environment variable for path is PATH (uppercase…)
After remove this variable ‘path’ (“unset path” in bash), all my problems were gone…. Yess !
So some words of wisdom: NEVER define an environment variable ‘path’ on freebsd !! (And be VERY careful with your other environment variables!)
After updating my FreeBSD port php and apache I suddenly got a whole lot of core dumps. The hosted websites were running fine, but the core dumps didn’t feel quite right.. (of course).
Another FreeBSD server of mine, also updated to the same version, didn’t have these core dumps.
Doing some research on the web I found that a wrong order in extensions.ini could be a cause of my problems.
Changing the order of the extensions.ini solved my problem!
The following extensions.ini is is working for me: