Got a SIGABRT while executing native code - error when running xsp4 on AWS during Cloudformation

Question

I'm getting an error when starting the xsp4 server on an AWS Ubuntu AMI. The error is initialize: mono_thread_create_internal () failed, and then:

Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application.

The same command executes without errors on my own computer. Any idea what the error is - maybe a missing package, some configuration or something like that?

Edit: Huh, that's weird, it's working when I log in via ssh and manually run the command. I need to run it during CloudFormation however, and it fails there. Maybe something isn't fully setup yet during CloudFormation, or the user account is different? But on second thought, doesn't CloudFormation run as root?

Full log:

+ xsp4 --port 80
Cloud-init v. 0.7.9 running 'modules:final' at Sun, 22 Oct 2017 17:18:30 +0000. Up 12.78 seconds.
Cloud-init v. 0.7.9 finished at Sun, 22 Oct 2017 17:19:27 +0000. Datasource DataSourceEc2.  Up 69.50 seconds
xsp4
Listening on address: 0.0.0.0
Root directory: /var/www/HelloWebApi
Listening on port: 80 (non-secure)
Hit Return to stop the server.
The server is not started.
  at Mono.WebServer.ApplicationServer.Stop ()  in :0 
  at (wrapper remoting-invoke-with-check) Mono.WebServer.ApplicationServer:Stop ()
  at Mono.WebServer.XSP.Server.DebugMain (System.String[] args, Boolean root, IApplicationHost ext_apphost, Boolean quiet)  in :0 
initialize: mono_thread_create_internal () failed
Stacktrace:

  at  
  at (wrapper managed-to-native) System.Net.Sockets.Socket.socket_pool_queue (System.Net.Sockets.SocketAsyncCallback,System.Net.Sockets.SocketAsyncResult) 
  at System.Net.Sockets.Socket.QueueSocketAsyncResult (System.Collections.Generic.Queue`1,System.Net.Sockets.SocketAsyncWorker,System.Net.Sockets.SocketAsyncResult) 
  at System.Net.Sockets.Socket.AcceptAsync (System.Net.Sockets.SocketAsyncEventArgs) 
  at Mono.WebServer.ApplicationServer.RunServer () 
  at System.Threading.ThreadHelper.ThreadStart_Context (object) 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object) 
  at System.Threading.ThreadHelper.ThreadStart () 
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) 

Native stacktrace:

        /usr/bin/mono() [0x49ff2f]
        /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390) [0x7f39c549b390]
        /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38) [0x7f39c50f5428]
        /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a) [0x7f39c50f702a]
        /usr/bin/mono() [0x630409]
        /usr/bin/mono() [0x63069c]
        /usr/bin/mono() [0x63076f]
        /usr/bin/mono() [0x58e6e5]
        [0x4044ec36]

Debug info from gdb:


=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Answer 1

If it works after SSH and not directly they most probably it is a TTY missing issue. If your server requires TTY then it won't start this way

As you mentioned in your response that xsp4 waits for enter key to exit and take --nonstop if you don't want the behavior, then you should use that arg. It will make sure the TTY is not required.

In case if a executable actually still requires TTY then you can look at the script command. Which does allocate a TTY and execute the command. See below for more details

http://man7.org/linux/man-pages/man1/script.1.html