7

Just as it says, I can't get capistrano 3 to do assets:precompile correctly. Even after hours, it still says writing to the .css file on the server.

UPDATE:

I was playing around and I tried a m1.medium. Same thing happened when it got to a certain point it simply stopped precompiling. Not errors are thrown, the cursor simply flashes.

It looks like it is still working, as it just says:

I, [2013-12-31T01:18:45.210416 #31413] INFO -- : Writing /var/www/app/releases/20131231011622/public/assets/application-998b176a776d6aff56fce8af9ca0d861.css

When I look at the cpu usage from any instance It looks like this:

enter image description here

It seems like the process is done, but it isn't. I created a fake application from scratch and it uploads perfectly with the same capistrano settings. I am using ckeditor, bootstrap-sass and a custom engine if that makes a difference.

If I need to show any other files I would be happy to add them here.

Thanks

Update 2 I got it to work on m1.medium instances, but it still fails on m1.small or t1.micro instances. So I assume it is with the ssh.

moosilauke18
  • 921
  • 3
  • 8
  • 26
  • What happens when you compile your assets locally? – Noz Dec 23 '13 at 21:21
  • I haven't tried that. How would I do that? And is it possible to change assets:precompile since it uses rake now? – moosilauke18 Dec 23 '13 at 21:49
  • 1
    You can run the `rake assets:precompile --trace` command on your dev machine, have a look at the output. Make sure you have `tmp/*` in your .gitignore so you're not saving any precompiled assets to source. Also are you deploying to a VPS? If so, it might be worthwhile to monitor your CPU usage. – Noz Dec 23 '13 at 22:03
  • I'm deploying to Ec2. I can run rake assets:precompile --trace and there doesn't seem to be any problem. – moosilauke18 Dec 23 '13 at 22:20
  • Are you using one of the micro instances? – Noz Dec 23 '13 at 22:24
  • I was and thought that was the problem because of the low cpu, so I tried an m1.small with no change. – moosilauke18 Dec 23 '13 at 22:42
  • Are you certain there wasn't a change? `rake assets:precompile` can take up to 10 minutes depending on how fast your machine is and the number of assets there are. It's a pretty demanding process and I wouldn't run it on a machine with any less than 1GB of ram. Takes 6-7 minutes and 75% of my available memory on a 1GB DO droplet for me. Worst case scenario is to take the poor mans approach. Run it on your development machine and commit it to source control / or tar gz the compiled assets and stick the end results in your public/assets directory. – Noz Dec 23 '13 at 23:13
  • I did some more testing. It turns out, on my dev computer it takes around 5-10 minutes to do the css file. But once it is cached in the temp file it precompiles fast. So, I'm thinking about doing a local precompile, rsyncing it to my production server then running it on the server. Then cleaning up my local dev computer with a task. – moosilauke18 Dec 27 '13 at 03:36
  • I would recommend making a copy (or git branch) and simplifying your entire Rails app down to the simplest thing that causes the problem. Then at that point you will probably know a few workarounds and you can submit a good bug report to the software project causing the problem. – David Grayson Jan 04 '14 at 19:45
  • Do you have an option to precompile locally and then push the compiled assets to the host? This is generally not a bad idea if you want to minimize downtimes though it bloats your git repo – bbozo Jan 05 '14 at 12:39

2 Answers2

1

I had a similar issue where Capistrano 3 freezes on assets:precompile.

For me it turned out that it was an SSH problem due to the prolonged time it takes to precompile assets on production! Especially if the server memory and CPU specs are not too high.

Although my connection to the production server was pretty fast and reliable, it seemed that my SSH client just gave up reading output from SSHD server after a certain amount of time.

The Fix

Add the following in /etc/ssh/sshd_config on production server to keep connection with SSH client alive:

ClientAliveInterval 30
ClientAliveCountMax 10

This fixed the issue and now Capistrano 3 completes deployment with no problems.

sampoh
  • 3,066
  • 1
  • 16
  • 14
moeabdol
  • 4,779
  • 6
  • 44
  • 43
0

  1. Is this a Windows instance? Windows instances by default use the IE6 Javascript/CSS engine which is PATHETICALLY SLOW and accurately reflects the problem that you are facing.

  2. If it is a Linux instance, try adding the uglifier and therubyracer gems in your Gemfile, and also make sure to install Firefox/libv8

Subhas
  • 14,290
  • 1
  • 29
  • 37
  • It is a linux and I currently have `uglifier` and `therubyracer` in the Gemfile. I just went into the server and installed `libv8-3.7.12.22`. – moosilauke18 Dec 31 '13 at 21:40
  • 1
    I believe I solved the problem. After doing some reading on Heroku, therubyracer is not suggested as it uses a lot of memory. So I installed node.js on my server and removed therubyracer. Next I increased the SSH keepalive higher. – moosilauke18 Dec 31 '13 at 23:28
  • Excellent. I was planning to suggest node.js, but I had (still have) one nagging doubt. You had an error when compiling the CSS file. But node.js is a Javascript runtime. Not sure why a Javascript runtime will help compile CSS O_o – Subhas Jan 01 '14 at 07:44
  • Since I am using Sass, I thought that it uses node.js. I am now able to deploy on a m1.medium instance, but anything smaller still fails. This makes me think that it has more to do with a failed SSH connection. – moosilauke18 Jan 02 '14 at 01:07
  • If that is the case try running the command with nohup to avoid interruption. – rlecaro2 Jan 02 '14 at 12:51
  • how would I go about running nohup with capistrano? – moosilauke18 Jan 06 '14 at 01:48
  • I'd recommend precompiling locally and pushing the final compiled css – Anna Billstrom Jan 06 '14 at 22:30