Nohup & Sass: Proces nadal działa, ale po pewnym czasie pliki * .scss nie są kompilowane

Używam Sassa na serwerze CentOS 5.8 i chcę, aby działał po wylogowaniu z SSH, aby inni użytkownicy mogli edytować pliki * .scss przez kilka dni, a nawet tygodni, bez konieczności uruchamiania programu przy każdym logowaniu (w rzeczywistości , nie mają nawet dostępu SSH).

Użyłem następującego polecenia z tego pytania / odpowiedzi :

$ nohup sass --watch path / to / scss / files: path / to / css / output / files &

Następnie wylogowuję się z sesji SSH i proces jest kontynuowany. Wszystko działa dobrze (ponowne zalogowanie się i użycie dotyku do utworzenia pliku testowego (test.scss) poprawnie uruchamia utworzenie odpowiedniego pliku test.css) przez pierwsze kilka minut, ale po pewnym czasie pliki * .scss przestają się wyświetlać skompilowane ... Jednak

$ ps aux | grep „sass”

Pokazuje, że proces jest nadal uruchomiony.

Czy ktoś wie, co robię źle?

EDYCJA: to jest wynik, który otrzymuję od nohup.out:

/usr/local/rvm/rubies/ruby-1.9.3-p286/lib/ruby/1.9.1/yaml.rb:56:in '':
Wygląda na to, że w twojej instalacji ruby brakuje psych (dla wyjścia YAML).
Aby wyeliminować to ostrzeżenie, zainstaluj libyaml i ponownie zainstaluj ruby.
>>> Sass czeka na zmiany. Naciśnij Ctrl-C, aby zatrzymać.
>>> Wykryto nowy szablon: 
/home/*/sites/all/themes/test.scss
  nadpisz private_html / sites / all / themes // test.css
>>> Wykryto usunięty szablon: 
/home/*/sites/all/themes/test.scss

Błąd związany z YAML wydaje się niezwiązany z problemem, ponieważ Sass działa poprawnie przez krótki czas. Po prostu cicho przestaje działać w pewnym momencie, mimo że proces nadal działa ...

terminal process nohup

— Maurits
źródło

Czy masz jakieś wyjście w nohup.out?

— dset0x

Dzięki za pytanie, dodałem dane wyjściowe z nohup.out

— Maurits

Mam ten sam problem. Pracuję w przybliżeniu w tej samej konfiguracji od około tygodnia (Sass przez nohup pod Ubuntu 12.04). W ramach obejścia planuję uruchomić Sass za pomocą skryptu bash w średnio-częstym zadaniu cron, zabijając istniejące zadania sass przed uruchomieniem nowych. Czuję się niechlujny i sprawia, że czuję się nieswojo, szczególnie możliwość zabicia sassa podczas pisania na dysk. Ale ponieważ jestem jedynym użytkownikiem w moim systemie, ze stosunkowo rzadkimi zatwierdzeniami, mogę zaryzykować.

— Andy Giesler,

Ugh brzmi jak irytujący problem. Wątpliwy problem z nohupem, ponieważ jest powszechnie używany, dojrzały i prosty. Zrezygnujmy i tak. Problemem jest także eliminacja tła procesu.

Otwórz ekran ... dosłownie screen

uruchom polecenie bez nohup, ale pozwól nam je gdzieś zapisać

sass --watch path/to/scss/files:path/to/css/output/files 2>&1 | tee sass.log

2> i 1 upewniają się, że łapiemy STDERR i STDOUT, a tee wyświetla log na dysk

teraz odłącz ekran: ctrl+a d

wyloguj się, zaloguj ponownie i sprawdź, czy to robi różnicę. Nie musisz ponownie podłączać się do ekranu, ponieważ masz uruchomiony plik sass.log, ale zrobiłbyś to za pomocą screen -r.

— MattPark
źródło