I have a Rails 5.2 app, and with cap 3.4.1 we are suddenly getting this weird error:
[b35efe76] Phusion Passenger(R) 6.0.8
DEBUG [b35efe76] Finished in 0.305 seconds with exit status 0 (successful).
(Backtrace restricted to imported tasks)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as deploy#host.com: undefined method `[]' for nil:NilClass
Trying to narrow it down, it happens when attempting to restart, because this is the line that fails:
cap production deploy:restart
The question is, how do I go about finding what file is trying to call [] on a nil value on? Running cap with --trace is of no value because it just gives me internal errors - nothing in my code. Basically, how do I find out what is nil?
One more clue, currently, I have a bunch of servers, if I run the cap restart command on server A, it restarts fine, on server B, it throws this error, so I'm guessing there's an environment variable on server A but not B, but the error is just so opaque I don't know where to begin.
Thanks for any help,
kevin
A wild guess: I had a similar problem and I could solve it by upgrading capistrano-passenger to >= 0.2.1
Looks like the version change of passenger from 6.0.7 to 6.0.8 has introduces a problem. I see you are also on 6.0.8, so it might affect you, too!
Link to the capistrano-passenger issue
Related
I've got this angular (12.2.12) app. Everything was working fine until today. When i tried ng serve --live-reload=false the process just failed. Browser application bundle generation completed successfully but right after that i've got this error message:
× ｢wdm｣: Error: invalid argument
at pathToArray (app_path\node_modules\memory-fs\lib\MemoryFileSystem.js:44:10)
at MemoryFileSystem.readdirSync (app_path\node_modules\memory-fs\lib\MemoryFileSystem.js:122:13)
at MemoryFileSystem.<computed> [as readdir] (app_path\node_modules\memory-fs\lib\MemoryFileSystem.js:279:34)
at app_path\node_modules\webpack\lib\CleanPlugin.js:65:7
at symbolIterator (app_path\node_modules\neo-async\async.js:3482:9)
at timesSync (app_path\node_modules\neo-async\async.js:2297:7)
at Object.eachLimit (app_path\node_modules\neo-async\async.js:3463:5)
at getDiffToFs (app_path\node_modules\webpack\lib\CleanPlugin.js:61:11)
at app_path\node_modules\webpack\lib\CleanPlugin.js:352:6
at Hook.eval [as callAsync] (eval at create (app_path\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:12:1)
I didn't change anything beisdes changing value for build / outputPath in angular.json (changing it back to previous value did not help to solve the problem). Any ideas what may be the problem?
One more thing: ng build works without any problems
Ok i apologize even tho i said i changed the outputPath back to it's previous value the opposite was true and i did not save the angular.json after changing it back.
Changing the value back and saving angular.json did actually resolve the issue. The problem happened because i changed the value of outputPath to shared network folder. This change caused ng serve to stop working.
(Not sure wheather to delete the question or keep it up with this answer)
I have set up a project, which uses Servant and Persistent, using a PostgreSQL backed. Everything works fine, when I run stack ghci, including migration, but when I run stack build, I get the following error:
Linking .stack-work\dist\29cc6475\build\ServantAuthTraining-exe\ServantAuthTraining-exe.exe ...
C://Users//Chris//AppData//Local//Programs//stack//x86_64-windows//ghc-8.8.3//mingw//bin/ld.exe: cannot find -llibpq
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)
-- While building package ServantAuthTraining-0.1.0.0 using:
C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_3.0.1.0_ghc-8.8.3.exe --builddir=.stack-work\dist\29cc6475 build lib:ServantAuthTraining exe:ServantAuthTraining-exe --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
I am on windows, and very new to all of the mentioned techs.
I can connect to the database via pgAdmin.
You likely need to pass something like --extra-include-dirs=C:\PostgreSQL\8.4\include --extra-lib-dirs=C:\PostgreSQL\8.4\lib (or whatever path) to stack so it knows where to find libpq. This can also be configured in your stack.yaml as described at https://docs.haskellstack.org/en/latest/yaml_configuration/#extra-include-dirsextra-lib-dirs.
I've been using my SQL database initialization script for a while, but it seems that recently the database crashes in the middle of the execution and I don't know why, but here's some details:
I am running OrientDB on Ubuntu 14 Trusty x64 (via Vagrant)
It always seems to crash while the script attempts to create a UNIQUE_HASH_INDEX, but doesn't always crash at the same UNIQUE_HASH_INDEX instruction
The script creates a lot of vertices and edges, but for example, it will crash here (see line with UNIQUE_HASH_INDEX):
CREATE CLASS Channel EXTENDS V;
CREATE PROPERTY Channel.version LONG;
CREATE PROPERTY Channel.channelId STRING;
CREATE INDEX Channel.uq_channelId ON Channel(channelId) UNIQUE_HASH_INDEX;
The database crashes entirely with the following error:
Creating index... Error:
com.orientechnologies.orient.core.exception.OStorageException: Error
on executing command: sql.create INDEX Channel.uq_channelId ON
Channel(channelId) UNIQUE_HASH_INDEX
Error: java.io.EOFException
Looking at the log files, the only hint I get are the last two lines:
2016-01-14 17:17:05:437 INFO Received signal: SIGTERM [OSignalHandler]
2016-01-14 17:17:05:454 INFO Received signal: SIGTERM [OSignalHandler]
How can I resolve this issue, or at least get better hints as to what is making the database crash?
I also test with OrientDB 2.1.6, as I was running the older version initially. Same problem.
Sorry, false alarm -- this is a Vagrant issue, not an OrientDB issue. Running the exact same script on a 32bit instance instead of 64bit solved my problem, and installing the same script on a real 64bit server also works.
When my script fails to parse for any reason, I get a stack trace from the compiler, with no insight at all into where in my script the problem lies:
mpurvis#citadel:~/coffee$ coffee -c Test.coffee
/usr/local/lib/node_modules/coffee-script/lib/command.js:15
return process.binding('stdio').writeError(line + '\n');
^
Error: No such module
at /usr/local/lib/node_modules/coffee-script/lib/command.js:15:20
at /usr/local/lib/node_modules/coffee-script/lib/command.js:167:7
at /usr/local/lib/node_modules/coffee-script/lib/command.js:115:26
at [object Object].<anonymous> (fs.js:108:5)
at [object Object].emit (events.js:64:17)
at afterRead (fs.js:1074:12)
at Object.wrapper [as oncomplete] (fs.js:246:17)
For now, it's just a toy script to try the system out, so I can usually just experiment until it works again, but that would be impossible in a file of any size. Is there some trick I'm not seeing to get the line where the error occurred?
Thanks!
the latest version from node isn't full compatible with cs..the node_stdio module ws removed...a simple way for fix it is open /usr/local/lib/node_modules/coffee-script/lib/command.js and change the line 15
process.binding('stdio').writeError(line + '\n')
for
process.stderr.write(line + '\n')
always you can get more help from github issues section
https://github.com/jashkenas/coffee-script/commit/c77f7737a5d94a05a999109810ea7634f540e1e2
good luck and happy coding
This doesn't look like a syntax issue. The error is coming from command.js, which is what defines the coffee command-line utility. If it were a compiler error, it would be from coffee-script.js.
So why is the process.binding('stdio') bit in command.js failing? There are two possibilities I can think of:
You're using a weird shell (or a weirdly configured one) that doesn't play nice with Node's version of stdio. This seems unlikely, but it's possible...
You're using a version of Node.js that CoffeeScript isn't currently compatible with. What do you get when you do node -v? Your safest bet is the latest 0.4.x, since those are stable releases (0.5.x is experimental).
This question is from awhile back.
Node 0.6.x throws a similar error with CoffeeScript 1.1.x; upgrading to 1.3.x does the trick.
Likely 2 different coffee-scripts on your system. check which coffee, than track down the older one and ice it. I had one from an install last summer (v1.1), it's all cleared up now.
Sorry, not really programming question, but I am not sure where else I could find some help.
After a recent update (Xorg was updated among other things), GTK apps stopped running in my kde4. I have a Debian unstable, updated around 22 April. When I try to run them I get the following error:
ga#grzes:~$ iceweasel
The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadName (named color or font does not exist)'.
(Details: serial 888 error_code 15 request_code 45 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
ga#grzes:~$ gimp The program 'gimp' received an X Window
System error.
This probably reflects a bug in the program.
The error was 'BadName (named color or font does not exist)'.
(Details: serial 6955 error_code 15 request_code 45 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
(script-fu:4643): LibGimpBase-WARNING **: script-fu: gimp_wire_read():
error
I have to restart the font server manually to have it fixed:
ga#grzes:~$ su
Password:
grzes:/home/ga# /etc/init.d/xfs restart
Stopping X font server: xfs.
Setting up X font server socket directory /tmp/.font-unix...done.
Starting X font server: xfs.
Any ideas what could be wrong? Is it a configuration issue? My system has been updated for the last 7 years, so I can have some old settings.
Debian unstable is very... unstable now, since a release was made a short time ago. Major changes and packages migrations are happening. Xorg (and all X related stuff) being one of the critical packages in that process. My advice is to perform a new update/upgrade in order to catch a new version that may resolve this problem.
It's very frequent that after an update some thing will get broken in inexplicable ways, simply because the developers are uploading new, and not much tested, version of the applications
I finally figured this out: seems like xfs is not compatible with the other components currently and luckily removing it form the system completely solves the problem.