ROS 2.0 Failing to Start


#1

Having issues getting the ROS to start consistently.
Running Ubuntu 16.04.3 LTS

I’ve installed the ROS per the instructions. I was able to get it running once or twice, but then when I would shut it down, it would fail to start up again. I’ve gotten a myriad of errors, here is the latest.

[email protected]:~/kros$ npm start

> [email protected] start /home/ubuntu/kros
> npm run build && node dist/index.js


> [email protected] build /home/ubuntu/kros
> rm -rf dist; ./node_modules/.bin/tsc

info: Realm Object Server version 2.0.2 is starting
info: Realm sync server started ([realm-core-4.0.2], [realm-sync-2.0.2]) service=sync
Segmentation fault (core dumped)

npm ERR! Linux 4.4.0-97-generic
npm ERR! argv "/home/ubuntu/.nvm/versions/node/v6.11.4/bin/node" "/home/ubuntu/.nvm/versions/node/v6.11.4/bin/npm" "start"
npm ERR! node v6.11.4
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! [email protected] start: `npm run build && node dist/index.js`
npm ERR! Exit status 139
npm ERR! 
npm ERR! Failed at the [email protected] start script 'npm run build && node dist/index.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the my-ros-app package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     npm run build && node dist/index.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs my-ros-app
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls my-ros-app
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/ubuntu/kros/npm-debug.log

I’ve deleted this ROS and init new versions, all have the same issues.
– This is a purely vanilla install so far.


#2

Interesting discovery.

If I run ros start from the project directory, I get the seg fault.
HOWEVER, if I run ros start --loglevel=all if boots up just fine.


#3

When you create a project, the recommended way to run it is via npm start, but I couldn’t figure out how to pass the cmd line arguments (--logleve=all) through this, which is needed to keep it from seg-faulting when starting up.

Soooo… I edited the index.ts file and added a few additions to get it to boot up correctly:

server.start({
        dataPath: path.join(__dirname, '../data'),
        logLevel: 'all',
        address: '0.0.0.0'
    })

Note that the address is also required, otherwise it binds to 127.0.0.1 and won’t respond to requests either.

With this change to the TypeScript file, pm2 should also work now.

Some improvements to the docs would be great as well as fixing the Seg Fault when starting w/o log level set to all.

Hope this helps.


(Ian Ward) #4

Thank you @netizen01 we will get this sorted right away


(Kræn Hansen) #5

Getting segmentation faults are definitely something we should fix right away - its very interesting that this behaviour is changed when setting the log-level. What happens if you move the data directory? (move instead of remove - because I would love to get that zipped up and sent to us for investigations).


#6

Shutdown instances.
Moved data to “data2”.
Ran ros start and it created a new data dir.
However, it still crashed…

info: Realm Object Server version 2.0.2 is starting
info: Realm sync server started ([realm-core-4.0.2], [realm-sync-2.0.2]) service=sync
info: Directory holding persistent state: /home/ubuntu/kros/data/sync/user_data service=sync
info: Operating mode: master_with_no_slave service=sync
info: Listening on 127.0.0.1:43907 (sync protocol version 22) service=sync
info: sync-client: Connection[1]: Connected to endpoint '127.0.0.1:43907' (from '127.0.0.1:36782')
info: sync-client: Connection[2]: Connected to endpoint '127.0.0.1:43907' (from '127.0.0.1:36784')
info: sync-client: Connection[3]: Connected to endpoint '127.0.0.1:43907' (from '127.0.0.1:36786')
info: Starting auth provider 'password'
info: sync-client: Connection[4]: Connected to endpoint '127.0.0.1:43907' (from '127.0.0.1:36788')
info: Autocreated realm-admin user
info: 127.0.0.1 - GET /realms/files/%2F__admin HTTP/1.1 200 41 - 7.468 ms
info: 127.0.0.1 - GET /realms/files/%2F__revocation HTTP/1.1 200 46 - 3.386 ms
info: 127.0.0.1 - GET /realms/files/%2F__wildcardpermissions HTTP/1.1 200 55 - 14.106 ms
info: 127.0.0.1 - GET /realms/files/%2F__password HTTP/1.1 200 44 - 7.569 ms
info: Realm Object Server has started and is listening on http://0.0.0.0:9080
info: sync-client: Connection[5]: Connected to endpoint '0.0.0.0:9080' (from '127.0.0.1:38896')
error: Sync Connection[5]: Session[5]: Bad client file ident (client_file_ident=3,  client_file_ident_secret=4264450923579321035). service=sync
info: sync-client: Connection[5]: Received: ERROR(error_code=208, message_size=34, try_again=0, session_ident=5)
info: sync-client: Connection[5]: Connection closed due to error reported by server: Bad client file identifier (IDENT) (208)
info: sync-client: Closing Realm file: /home/ubuntu/kros/realm-object-server/listener/realms.realm

From what I can tell the sync services hold onto connections too long and you have to give them a few minutes to shutdown for the node instance to be able to spin up new sync servers and get things going again … (if that makes sense)
—> good way to test this:

  1. Start ROS in the terminal on your server.
  2. Connect with the Realm Studio Mac App
  3. While connected with the studio app, CRTL+C the ROS node app.
  4. Witness the chaos.
  5. Close the Studio Browser for that connection
    5a. (It seems the studio browser is not releasing and closing the connection completely after you close the window)
    5b. Log chaos on the server continues…
  6. QUIT the Studio Browser.
  7. The ROS server finally shuts down.

#7

Probably worth documenting the pm2 process. Notably the process to get it installed into the system daemons so it survives a reboot: pm2 startup


(Kræn Hansen) #8

Okay - so this suggests to me that we solved the segmentation fault by letting ROS recreate its persistent state, could I get you to zip up that data folder and upload it here as an attachment?

I tried to reproduce your environment, but I couldn’t get the segmentation fault :confused:

On your other point, the “Bad client file ident” error happens when a client tries to sync a file with ROS that was deleted and created again, but this client fails because the file got replace without its knowledge. I think this might be an artifact from a sync client (perhaps Realm Studio) that was opened during the move of the data-folder.


#9

Got it. I will see what I can do…


(Govind singh) #10

did you got any solution to this.
i am facing the same issue