2013-02-20 4 views
19

Ich habe ähnliche Probleme wie viele Benutzer beim Kompilieren von Assets auf ihrer produktiven Box. Der einzige Unterschied ist, dass ich keinen Hinweis mehr aus der Spur bekommen kann, um das Problem zu lösen."Befehl fehlgeschlagen mit Status()" beim Vorkompilieren von Assets

rake assets:precompile RAILS_ENV=production --trace 
** Invoke assets:precompile (first_time) 
** Execute assets:precompile 
/usr/local/rbenv/versions/1.9.3-p362/bin/ruby /usr/local/rbenv/versions/1.9.3-p362/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets --trace 
** Invoke assets:precompile:all (first_time) 
** Execute assets:precompile:all 
** Invoke assets:precompile:primary (first_time) 
** Invoke assets:environment (first_time) 
** Execute assets:environment 
** Invoke environment (first_time) 
** Execute environment 
** Invoke tmp:cache:clear (first_time) 
** Execute tmp:cache:clear 
** Execute assets:precompile:primary 
rake aborted! 
Command failed with status(): [/usr/local/rbenv/versions/1.9.3-p362/bin/r...] 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/file_utils.rb:53:in `block in create_shell_runner' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/file_utils.rb:45:in `call' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/file_utils.rb:45:in `sh' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/file_utils_ext.rb:39:in `sh' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/file_utils.rb:80:in `ruby' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/file_utils_ext.rb:39:in `ruby' 
/home/app/application/ruby/1.9.1/gems/actionpack-3.2.12/lib/sprockets/assets.rake:12:in `ruby_rake_task' 
/home/app/application/ruby/1.9.1/gems/actionpack-3.2.12/lib/sprockets/assets.rake:21:in `invoke_or_reboot_rake_task' 
/home/app/application/ruby/1.9.1/gems/actionpack-3.2.12/lib/sprockets/assets.rake:29:in `block (2 levels) in <top (required)>' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/task.rb:205:in `call' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/task.rb:205:in `block in execute' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/task.rb:200:in `each' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/task.rb:200:in `execute' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/task.rb:158:in `block in invoke_with_call_chain' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/task.rb:151:in `invoke_with_call_chain' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/task.rb:144:in `invoke' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/application.rb:116:in `invoke_task' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/application.rb:94:in `block (2 levels) in top_level' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/application.rb:94:in `each' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/application.rb:94:in `block in top_level' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/application.rb:133:in `standard_exception_handling' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/application.rb:88:in `top_level' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/application.rb:66:in `block in run' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/application.rb:133:in `standard_exception_handling' 
/usr/local/rbenv/versions/1.9.3-p362/lib/ruby/1.9.1/rake/application.rb:63:in `run' 
/usr/local/rbenv/versions/1.9.3-p362/bin/rake:32:in `<main>' 
Tasks: TOP => assets:precompile 

Es gibt effektiv keinen Statuscode, nur das scheitern. Es macht auch keinen Unterschied, ob ich Rake direkt oder über bundle exec anrufe.

über die Umwelt Debian Squeeze-Box mit einer globalen rbenv Installation (/usr/local/rbenv wie Sie aus der Spur sehen). Ruby 1.9.3 2012-12-25 Patchlevel 362.

Irgendwelche Hinweise/Ideen zu diesem Thema?

Antwort

18

Ich werde das selbst beantworten, weil ich es mehr oder weniger lösen könnte. Wenn jemand Ergänzungen hat, zögere nicht, eine eigene Antwort zu schreiben oder diese Antwort/Frage zu kommentieren.

Was ich bisher herausgefunden:

Wenn man sich durch zB mit assets:precompile spielen nur die primären Aktiva Kompilieren (assets:precompile:primary) oder explizit assets:precompile:all rufen Sie könnten mit einem Hinweis auf die Quelle am Ende der Ihr Problem. In meinem Fall lief ich in Errno::EACCES auf beiden public/ und tmp/. Irgendwie wurde das nicht angezeigt, also stellen Sie sicher, dass Ihr Benutzer die vollen Rechte hat, Dateien und Ordner dort zu erstellen/löschen.

In meinem Fall funktionierte es manchmal, weil ich die Rails-App heruntergefahren und vorkompiliert hatte, während es heruntergefahren war. Da Vorkompilieren eine Menge Speicher zuweist, habe ich einige Versuche und Fehler gemacht und habe schließlich die bekannteNachricht erhalten, wenn Rake versucht, asstes:precompile:primary auszuführen. Die Aufgabe wurde einfach wegen zu viel Speicher gelöscht.

Ein weiteres Problem war, dass Ritzel bootstrap nicht finden konnten, um es in der Assets-Pipeline auf Vorkompilierung zu setzen. Bewegt gem 'bootstrap' außerhalb von group :assets löste dies. Das war auch etwas, worauf ich hingewiesen wurde, als ich mit den Befehlen herumspielte.

Der beste Weg zu lösen - oder besser: umgehen - dieses Problem besteht darin, Ihre Assets einfach lokal zu kompilieren. Werfen Sie einfach eine rake assets:precompile RAILS_ENV=development in Ihr Terminal und deployen Sie dann public/assets. Denken Sie daran, diesen Ordner in Ihrer Entwicklungsumgebung nach der Bereitstellung zu löschen, oder Sie werden am Ende debuggen, warum Ihre Änderungen unter app/assets/* in der Entwicklung nicht wirksam werden. Das funktioniert zumindest für mich (tm).

Alternativ kann auch das Wachstum Ihrer Swap-Partition funktionieren. Das Kompilieren auf einem VPS, wo Sie Swap verwenden müssen, kann jedoch länger dauern, also bleibe ich beim lokalen Weg.

+0

Sie hatten Recht auf über den Prozess durch das OS – rainkinz

6

Ich hatte auch dasselbe Problem. Ich reparierte es durch Hinzufügen von Swap (in meinem Fall 1 GB für 512 RAM auf meinem Server verfügbar)