Solved FreeBSD 11.0 Crashes When Installing Ruby

Hey all.

I have a FreeBSD 11.0 droplet on digital ocean and I decided to uninstall vim-lite and install vim today, so I can install some plugins that need Python support. I refreshed the ports tree and installed with vim with make WITHOUT_X11=yes install clean but every time it gets to installing Ruby (ruby-2.3.3_1,1) the server crashes. It responds to ping (or maybe that is some DO magic) but the console is dead and SSH connections are refused, I had top running at the time in a different putty session and interestingly that kept going, but the moment I closed top that terminal was dead, I didn't even get a prompt back.

These are the last lines of output from Ruby before it crashes:

99% [926/933] vm_backtrace.c
99% [927/933] vm_dump.c
99% [928/933] vm_eval.c
99% [929/933] vm_exec.c
99% [930/933] vm_insnhelper.c
99% [931/933] vm_method.c
99% [932/933] vm_trace.c
100% [933/933] vsnprintf.c
Generating RI format into /usr/ports/lang/ruby23/work/ruby-2.3.3/.ext/rdoc...


I have to hard reset the machine to get back in. Any ideas?

Thanks!

Tab
 
The only time I had this kind of problem using FreeBSD, it was because I had a faulty memory stick.

EDIT: you can see the crach report at /var/crash.
 
I was expecting more. Do you have dumpdev="AUTO" on your rc.conf?

Anyway, do a memory test!

No I don't have dumpdev="AUTO" in my rc.conf. I don't think I can do a memory test! I've used memtest86 before, but this is a VM floating in the cloud :rolleyes:
 
Hum... please place that on your rc.conf and so we will have more info about the crash the next time it crash.
I just use VM to do some OS testing from time to time, then I do not know if that crash may be caused by a hypervisor issue or something more low level, or what.

I think would be interesting if you point out what hypervisor you are using. And lets wait for someone with more knowledge about your issue appear. :)

EDIT: I mean, it is not normal a package compilation break the entire system. This kind of behavior usually indicate a hardware problem, memory is the most common one, but since you are using VM I do not know how to properly try to help you.
 
Hum... please place that on your rc.conf and so we will have more info about the crash the next time it crash.
I just use VM to do some OS testing from time to time, then I do not know if that crash may be caused by a hypervisor issue or something more low level, or what.

I think would be interesting if you point out what hypervisor you are using. And lets wait for someone with more knowledge about your issue appear. :)

EDIT: I mean, it is not normal a package compilation break the entire system. This kind of behavior usually indicate a hardware problem, memory is the most common one, but since you are using VM I do not know how to properly try to help you.

I will raise a SR with digital ocean to see if there is some underlying hardware issue. I added the dumpdev switch to my rc.conf and tried to install ruby23 again, crashed again at the same point but still no dump file. This is the smallest size droplet and only has 500MB of RAM (and.. I'm using ZFS), so perhaps that has something to do with it?
 
Well, when there is low ram memory the system rely on swap, what make it very slow but do not break the system. However, if also there is not enough swap it will probably break the system, I think.

EDIT: ZFS usually only require high memory when you are using dedup, and/or L2ARC, but I never used it with 500MB only...

SirDice would certanly be a good one to help you to nail it.
 
Really, using ZFS on anything other than real hardware is kind of pointless, and running it on 500MB of RAM is going to lead to crashes. I was a bit surprised when I learned DigitalOcean offered it as an option. ZFS was designed to host virtual machines, not run on virtual machines.
 
I agree with the precedings comments, it is not a good idea running ZFS on a VM and with such low amount of RAM.

Additionally that RAM is not enough to build software other than very basic (small) ports/packages.

Finally, if by any chance you are using tmpfs for /tmp that will further lower the amount of available memory, depending on the running task.

If you really need to build software on that machine, I would suggest to ask for an upper configuration, and of course reinstall using UFS.
 
Hey all.

Thanks for the responses, I agree, I was foolish to choose the ZFS option, but what can I say, I'm so used to having ZFS on my servers now I didn't really think about it :oops:.

I grew the swap volume to 4GB and tried again with 'swapinfo -h' polling in another session and it's barely using any swap and still crashes.

Going to bump it up to the 4CPU/8GB RAM spec for an hour, seeing as it will only cost me 10 pence. Will report back!
 
Worked fine with the higher spec.. Still not too sure why it wouldn't work with 500MB if it wasn't filling swap. Oh well, working now. Thanks all :beer:
 
Back
Top