arangodb start command bug: different results of different order in the whole command

[mathsyouth]

trafficstars

My Environment

• ArangoDB Version: 3.6.8
• Storage Engine: RocksDB
• Deployment Mode: Cluster
• Deployment Strategy: ArangoDB Starter
• Configuration: 3 machines
• Infrastructure: own
• Operating System: Ubuntu 18.04
• Total RAM in your machine: 64Gb each
• Disks in use: HDD

Component, Query & Data

Affected feature: arangodb start command

Steps to reproduce

1. Run arangodb start:

ubuntu@Node2:~/arangodb3-3.6.8$ ./bin/arangodb start --server.storage-engine=rocksdb --auth.jwt-secret=./arangodb.secret --starter.data-dir=./data --starter.join arangodb1,arangodb2,arangodb3
2020-10-19T15:45:42+08:00 |INFO| Starting arangodb version 0.14.15, build e32307e in the background component=arangodb
2020-10-19T15:45:42+08:00 |ERRO| Cannot find arangod (expected at /usr/sbin/arangod). component=arangodb

How to solve this:
1 - Install ArangoDB locally or run the ArangoDB starter in docker. (see README for details).

2. Run arangodb start in the second way:

ubuntu@Node2:~/arangodb3-3.6.8$ ./bin/arangodb  --server.storage-engine=rocksdb --auth.jwt-secret=./arangodb.secret --starter.data-dir=./data --starter.join arangodb1,arangodb2,arangodb3 start
2020-10-19T15:48:37+08:00 |INFO| Starting arangodb version 0.14.15, build e32307e in the background component=arangodb
2020-10-19T15:48:37+08:00 |INFO| Waiting for starter API to be available ... component=arangodb

The arangodb services are launched successfully in the second way.

Problem

the order of start in the whole command effects the final results

Expected result

the order of start isn't important

[hesy007]

？？

[nikita-vanyasin]

@dothebart The issue is caused by the fact that shell script is not very smart at parsing command line arguments. It passes arangod path only if 'start' argument is a $1, although it can be at any place in command line: https://github.com/arangodb/oskar/blob/master/binForTarGz/arangodb

With new PR merged that will be fixed. But we should think about removing or simplifying this shell script in future.