Build from source question

Biggen

Have a quick question about building from source. Your instructions have this section after building with Yarn:

Now you have to create a config file for xo-server:
$ cd packages/xo-server
$ mkdir -p ~/.config/xo-server
$ cp sample.config.toml ~/.config/xo-server/config.toml

The directory I'm making, is that supposed to be under the packages/xo-server directory? The way I read it with the ~ character, it appears to be the user home directory.

So is it /home/user/.config/xo-server or /path/to/xo_source/packages/xo-server/.config/xo-server ?

Biggen

So I think I figured it out. I think it is the user home directory (whatever user is running the xo-server) which is root in my case. So that directory is being created at /root/.config/xo-server.

When starting the xo-service with yarn start, I'm getting this:

root@debian:/opt/xo/packages/xo-server# yarn start
yarn run v1.21.1
$ node bin/xo-server
  app-conf /opt/xo/packages/xo-server/config.toml +0ms
  app-conf /root/.config/xo-server/config.toml +3ms
2019-12-12T20:14:36.323Z xo:main INFO Configuration loaded.
2019-12-12T20:14:36.331Z xo:main INFO Web server listening on http://[::]:80
2019-12-12T20:14:36.387Z xo:xo-mixins:hooks DEBUG start start…
2019-12-12T20:14:36.520Z xo:xo-mixins:hooks WARN hook start failure: { error:
   { Error: Command failed with exit code 5: vgchange -an
    at makeError (/opt/xo/node_modules/execa/lib/error.js:56:11)
    at handlePromise (/opt/xo/node_modules/execa/index.js:114:26)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:189:7)
     command: 'vgchange -an',
     exitCode: 5,
     signal: undefined,
     signalDescription: undefined,
     stdout: '',
     stderr: '  Logical volume debian-vg/root contains a filesystem in use.\n  Can\'t deactivate volume group "debian-vg" with 2 open logical volume(s)',
     failed: true,
     timedOut: false,
     isCanceled: false,
     killed: false,
     [Symbol(originalCallSite)]: [ CallSite {}, CallSite {}, CallSite {}, CallSite {} ],
     [Symbol(mutatedCallSite)]: [ CallSite {}, CallSite {}, CallSite {}, CallSite {} ] } }
2019-12-12T20:14:36.526Z xo:xo-mixins:hooks DEBUG start finished
2019-12-12T20:14:36.527Z xo:xo-mixins:hooks DEBUG clean start…
2019-12-12T20:14:36.556Z xo:xo-mixins:hooks DEBUG clean finished
Warning: connect.session() MemoryStore is not
designed for a production environment, as it will leak
memory, and will not scale past a single process.
2019-12-12T20:14:36.610Z xo:main INFO Setting up / → /opt/xo/packages/xo-web/dist

I can successfully connect to XO via the web interface from my web browser so it appears to be working. I just want to know if the above error messages/codes are normal.

Biggen

Well replying to myself again. As far as I can tell, the above error message is normal. I've tested it on a few different systems and I get the same error codes on all of them. I'm following the build from sources tutorial exactly as well. No script. Everything by hand a step at a time.

XO seems to work fine after starting it with the above error message.

However, there does seem to be a problem with this section:

yarn global add forever
yarn global add forever-service
# Be sure to edit the path below to where your install is located!
cd /home/username/xen-orchestra/packages/xo-server/bin/
# Change the username below to the user owning XO
forever-service install orchestra -r username -s xo-server

So installing the forever and the forever-service goes ok. There is something about a module incompatibility however installing both the forever and forever-service. Its the same error message for both so I'm only putting it in there below once:

root@debian:/var/log# yarn global add forever
yarn global v1.21.1
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.9: The platform "linux" is incompatible with this module.
info "fsevents@1.2.9" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Installed "forever@1.0.0" with binaries:
      - forever

Running the last command, forever-service install orchestra -r root -s xo-server, adds it as a service in /etc/init.d. You can then start it via service orchestra start. No problem there. The problem is stopping it. When you issue service orchestra stop it doesn't stop the service. Syslog has this in it when stopping it:

Dec 13 10:24:45 debian systemd[1]: Stopping LSB: forever-service startup script for orchestra...
Dec 13 10:24:45 debian orchestra[1987]: /etc/init.d/orchestra: line 101: export: `failed:': not a valid identifier
Dec 13 10:24:45 debian orchestra[1987]: /etc/init.d/orchestra: line 102: /root/.forever: Is a directory
Dec 13 10:24:45 debian orchestra[1987]: Shutting down orchestra: mesg: ttyname failed: Inappropriate ioctl for dev
Dec 13 10:24:45 debian orchestra[1987]: -bash: line 0: export: `failed:': not a valid identifier
Dec 13 10:24:45 debian orchestra[1987]: -bash: line 1: /root/.forever: Is a directory
Dec 13 10:24:45 debian orchestra[1987]: Not running
Dec 13 10:24:45 debian systemd[1]: Stopped LSB: forever-service startup script for orchestra.

Running ps aux | grep xo shows all the instances (I started several of them) running after issuing stop commands.

root@debian:/opt/xen-orchestra/packages/xo-server/bin# ps aux | grep orchestra
root       1243  1.2 14.0 1276300 139988 ?      Sl   10:09   0:15 /usr/bin/node /opt/xen-orchestra/packages/xo-ser       ver/bin/xo-server
root       1258  0.0  2.9 873656 29172 ?        Sl   10:09   0:00 /usr/bin/node /opt/xen-orchestra/node_modules/je       st-worker/build/workers/processChild.js
root       1529  0.1  9.6 1266420 96356 ?       Sl   10:17   0:01 /usr/bin/node /opt/xen-orchestra/packages/xo-ser       ver/bin/xo-server
root       1544  0.0  2.9 873656 29336 ?        Sl   10:17   0:00 /usr/bin/node /opt/xen-orchestra/node_modules/je       st-worker/build/workers/processChild.js
root       1921  0.4  9.5 1262924 94976 ?       Sl   10:24   0:01 /usr/bin/node /opt/xen-orchestra/packages/xo-ser       ver/bin/xo-server
root       1936  0.0  2.9 873656 29188 ?        Sl   10:24   0:00 /usr/bin/node /opt/xen-orchestra/node_modules/je       st-worker/build/workers/processChild.js
root       2084  0.0  0.0  12780   952 pts/0    S+   10:29   0:00 grep orchestra

The problem appears to be the forever-service not being able to stop it properly. Running service orchestra status shows:

Dec 13 10:24:45 debian systemd[1]: Stopping LSB: forever-service startup script for orchestra...
Dec 13 10:24:45 debian orchestra[1987]: /etc/init.d/orchestra: line 101: export: `failed:': not a valid identifier
Dec 13 10:24:45 debian orchestra[1987]: /etc/init.d/orchestra: line 102: /root/.forever: Is a directory
Dec 13 10:24:45 debian orchestra[1987]: Shutting down orchestra: mesg: ttyname failed: Inappropriate ioctl for device
Dec 13 10:24:45 debian orchestra[1987]: -bash: line 0: export: `failed:': not a valid identifier
Dec 13 10:24:45 debian orchestra[1987]: -bash: line 1: /root/.forever: Is a directory
Dec 13 10:24:45 debian orchestra[1987]: Not running
Dec 13 10:24:45 debian systemd[1]: Stopped LSB: forever-service startup script for orchestra.

Any idea on why forever-service can't shut it down? This is a Debian 9 system.

I don't have to use the forever-service to start/stop the XO server. But since I'm following your instructions, I thought you'd like to know that it doesn't work 100% as described.

olivierlambert

I don't know, likely the forever part of the doc is outdated. Ping julien-f

julien-f

olivierlambert I'm not very familiar with Forever, I can't help you on this.

I think we should remove it from our documentation unless someone from the community is willing to maintain it. Maybe a pinned thread on this forum would make more sense.

olivierlambert

Okay, we should probably reduce the documentation and send to some projects made to run Node program in background (eg a link to forever project etc.)

ruskofd

Why not using a systemd unit instead of forever ?

Biggen

ruskofd said in Build from source question:

Why not using a systemd unit instead of forever ?

This is exactly what I did. Created a service file in etc/systemd/system that points back to the xo-server bin file.