I am trying to set up a shared volume in a minikube Kubernetes cluster to allow multiple pods to communicate with each other. What is configured is:
A PVC using the nfs-server-provisioner dynamic provisioner
Multiple Pods (some are jobs) that mount the PVC
The goal is to have an init container in each pod that creates a directory on startup using the Pod's name as the directory name, and have a job scan that directory and do some stuff.
I have this configured, and no errors are thrown, but the directory isn't created.
When trying to do this manually I see some strange behavior; mkdir returns a non-error code but doesn't do anything:
< ssh into pod >
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$ ls -al /output/
total 8
drwxrwxrwx 2 user users 4096 Sep 28 13:28 .
drwxr-xr-x 1 root root 4096 Sep 28 13:27 ..
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$ mkdir /output/test
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$ echo $#
0
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$ ls -al /output/
total 8
drwxrwxrwx 2 user users 4096 Sep 28 13:28 .
drwxr-xr-x 1 root root 4096 Sep 28 13:27 ..
user#802542b3ccb195b001258094dc543606-1601299620-zcszs:~$
I am able to touch files:
user#802542b3ccb195b001258094dc543606-1601299740-bw2hj:~$ ls -al /output/
total 8
drwxrwxrwx 2 user users 4096 Sep 28 13:29 .
drwxr-xr-x 1 root root 4096 Sep 28 13:29 ..
user#802542b3ccb195b001258094dc543606-1601299740-bw2hj:~$ touch /output/test
user#802542b3ccb195b001258094dc543606-1601299740-bw2hj:~$ ls -al /output/
total 8
drwxrwxrwx 2 user users 4096 Sep 28 13:29 .
drwxr-xr-x 1 root root 4096 Sep 28 13:29 ..
-rw-r--r-- 1 user users 0 Sep 28 13:29 test
user#802542b3ccb195b001258094dc543606-1601299740-bw2hj:~$
Here is the nfs mount:
Filesystem Size Used Avail Use% Mounted on
10.110.46.205:/export/pvc-2e433dc6-018d-11eb-be1a-0242766f1f7c 252G 134G 107G 56% /output
The same behavior is observed when using regular volumes. I am using the Docker driver but also observed this with the virtualbox driver. Is this a minikube issue? I would expect mkdir to error out if it can't complete.
minikube version: v1.13.1
commit: 1fd1f67f338cbab4b3e5a6e4c71c551f522ca138-dirty
I noticed that a lot of commands were missing when using VSCode terminal. So I tried a ls -l / on both my distro's and VSCode's terminals.
Linux Mint Xfce Terminal:
livy#linux-mint:~$ ls -l /
total 2097252
drwxr-xr-x 2 root root 4096 Aug 13 15:13 bin
drwxr-xr-x 4 root root 4096 Aug 13 15:15 boot
drwxr-xr-x 2 root root 4096 Aug 13 15:06 cdrom
drwxr-xr-x 20 root root 4260 Aug 15 08:40 dev
drwxr-xr-x 147 root root 12288 Aug 13 16:46 etc
drwxr-xr-x 4 root root 4096 Aug 13 15:06 home
lrwxrwxrwx 1 root root 33 Aug 13 15:07 initrd.img -> boot/initrd.img-4.15.0-54-generic
lrwxrwxrwx 1 root root 33 Aug 13 15:04 initrd.img.old -> boot/initrd.img-4.15.0-54-generic
drwxr-xr-x 23 root root 4096 Aug 13 15:07 lib
drwxr-xr-x 2 root root 4096 Jul 29 19:15 lib64
drwx------ 2 root root 16384 Aug 13 14:59 lost+found
drwxr-xr-x 2 root root 4096 Jul 29 19:14 media
drwxr-xr-x 2 root root 4096 Jul 29 19:14 mnt
drwxr-xr-x 3 root root 4096 Aug 13 15:18 opt
dr-xr-xr-x 214 root root 0 Aug 15 08:40 proc
drwx------ 4 root root 4096 Aug 13 15:07 root
drwxr-xr-x 32 root root 940 Aug 15 08:41 run
drwxr-xr-x 2 root root 12288 Aug 13 15:14 sbin
drwxr-xr-x 2 root root 4096 Jul 29 19:14 srv
-rw------- 1 root root 2147483648 Aug 15 08:40 swapfile
dr-xr-xr-x 13 root root 0 Aug 15 09:31 sys
drwxrwxrwt 15 root root 4096 Aug 15 08:53 tmp
drwxr-xr-x 11 root root 4096 Jul 29 19:14 usr
drwxr-xr-x 11 root root 4096 Jul 29 19:50 var
lrwxrwxrwx 1 root root 30 Aug 13 15:07 vmlinuz -> boot/vmlinuz-4.15.0-54-generic
And here is the result from VSCode terminal:
livy#linux-mint:~$ ls -l /
total 2097204
drwxr-xr-x 6 nfsnobody nfsnobody 4096 Aug 13 16:00 app
lrwxrwxrwx 1 livy livy 7 Aug 15 09:13 bin -> usr/bin
drwxr-xr-x 2 livy livy 80 Aug 15 09:13 boot
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Aug 13 15:06 cdrom
drwxr-xr-x 5 livy livy 340 Aug 15 09:13 dev
drwxr-xr-x 15 livy livy 860 Aug 15 09:13 etc
drwxr-xr-x 4 nfsnobody nfsnobody 4096 Aug 13 15:06 home
lrwxrwxrwx 1 livy livy 33 Aug 15 09:13 initrd.img -> boot/initrd.img-4.15.0-54-generic
lrwxrwxrwx 1 livy livy 33 Aug 15 09:13 initrd.img.old -> boot/initrd.img-4.15.0-54-generic
lrwxrwxrwx 1 livy livy 7 Aug 15 09:13 lib -> usr/lib
lrwxrwxrwx 1 livy livy 9 Aug 15 09:13 lib64 -> usr/lib64
drwx------ 2 nfsnobody nfsnobody 16384 Aug 13 14:59 lost+found
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Jul 29 19:14 media
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Jul 29 19:14 mnt
drwxr-xr-x 3 nfsnobody nfsnobody 4096 Aug 13 15:18 opt
dr-xr-xr-x 209 nfsnobody nfsnobody 0 Aug 15 09:13 proc
drwxr-xr-x 6 livy livy 160 Aug 15 09:13 run
lrwxrwxrwx 1 livy livy 8 Aug 15 09:13 sbin -> usr/sbin
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Jul 29 19:14 srv
-rw------- 1 nfsnobody nfsnobody 2147483648 Aug 15 08:40 swapfile
drwxr-xr-x 7 livy livy 140 Aug 15 09:13 sys
drwxr-xr-x 4 livy livy 80 Aug 15 09:13 tmp
drwxr-xr-x 12 nfsnobody nfsnobody 4096 Aug 13 16:00 usr
drwxr-xr-x 7 livy livy 160 Aug 15 09:13 var
lrwxrwxrwx 1 livy livy 30 Aug 15 09:13 vmlinuz -> boot/vmlinuz-4.15.0-54-generic
From the file owners, permissions, and modification date... it looks like they are working on different file systems. VSCode's /bin even points to /usr/bin, while it is not the case in Xfce terminal. The strange thing is that I can still use VSCode's terminal to navigate my home directory (/home/livy) and make changes to files. It even sources the content of my ~/.bashrc file.
What I am missing here?
I was having this exact same issue and discovered that the cause was that VSCode was installed as a Flatpak package. Uninstall it (be it a snap or a Flatpak package) and install the .deb file distributed by Microsoft.
I am trying to upgrade zookeeper from 3.4.8 to 3.4.13.
Before upgrade the content of /usr/lib/zookeeper
drwxr-xr-x 5 root root 4.0K Aug 23 08:39 .
drwxr-xr-x 77 root root 12K Aug 23 08:50 ..
drwxr-xr-x 2 root root 4.0K Aug 23 08:39 bin
lrwxrwxrwx 1 root root 19 May 24 11:25 conf -> /etc/zookeeper/conf
drwxr-xr-x 2 root root 4.0K Aug 23 08:39 lib
-rw-r--r-- 1 root root 12K May 24 11:25 LICENSE.txt
-rw-r--r-- 1 root root 170 May 24 11:25 NOTICE.txt
-rw-r--r-- 1 root root 1.3M Aug 23 08:39 zookeeper-3.4.8.jar
lrwxrwxrwx 1 root root 38 Aug 23 08:39 zookeeper.jar -> /usr/lib/zookeeper/zookeeper-3.4.8.jar
As mentioned in answer I have downloaded the zookeeper from this link and placed the zookeeper-3.4.13.jar in /usr/lib/zookeeper and pointed the symbolic link like below
lrwxrwxrwx 1 root root 39 Aug 30 03:19 zookeeper.jar -> /usr/lib/zookeeper/zookeeper-3.4.13.jar
But on checking the status after resarting zookeeper it is still pointing to 3.4.8
ubuntu#vrni-platform:/etc/zookeeper/conf$ telnet localhost 2181
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
status
Zookeeper version: 3.4.8--1, built on 02/06/2016 03:18 GMT
It appears this is because of the way the jars are loaded from /usr/lib/zookeeper/bin/zkEnv.sh
#release tarball format
for i in "$ZOOBINDIR"/../zookeeper-*.jar
do
CLASSPATH="$i:$CLASSPATH"
done
Can someone let me know is this some known issue is zkEnv.sh? Is this expected?
This has been answered in zookeeper mailing list. We should not have multiple zookeeper-<version>.jar in the CLASSPATH.
This is on Ubuntu 14.04 LTS
EDIT:
WAL-E installed using pip, with secret keys managed by envdir, according to the instructions https://gist.github.com/elithrar/8682235 and https://github.com/wal-e/wal-e#dependencies.
I am trying to restore a database using WAL-E, and everything appears to go well initially, as I have Postgres installed and running, and can easily create or restore a database and access it locally and remotely via pgadmin. Where it goes bad is when I try to perform a restore from an S3 backup using wal-e fetch-backup. It appears to go well up until the point of starting the postgres.
There are a number of errors that come up, appearing to be either missing packages or permissions issues, like the following:
* Starting PostgreSQL 9.3 database server
* The PostgreSQL server failed to start. Please check the log output:
2015-07-11 00:41:11 EDT LOG: database system was interrupted; last known up at 2015-06-30 05:00:02 EDT
2015-07-11 00:41:11 EDT LOG: starting archive recovery
Traceback (most recent call last):
File "/usr/local/bin/wal-e", line 5, in <module>
from pkg_resources import load_entry_point
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3084, in <module>
#_call_aside
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3070, in _call_aside
f(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3097, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 651, in _build_master
ws.require(__requires__)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 952, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 847, in resolve
new_requirements = dist.requires(req.extras)[::-1]
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2602, in requires
dm = self._dep_map
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2803, in _dep_map
self.__dep_map = self._compute_dependencies()
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2825, in _compute_dependencies
for req in self._parsed_pkg_info.get_all('Requires-Dist') or []:
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2794, in _parsed_pkg_info
metadata = self.get_metadata(self.PKG_INFO)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1617, in get_metadata
return self._get(self._fn(self.egg_info, name))
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1728, in _get
with open(path, 'rb') as stream:
IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/six-1.9.0.dist-info/METADATA'
2015-07-11 00:41:11 EDT LOG: invalid checkpoint record
2015-07-11 00:41:11 EDT FATAL: could not locate required checkpoint record
2015-07-11 00:41:11 EDT HINT: If you are not restoring from a backup, try removing the file "/var/lib/postgresql/9.3/main/backup_label".
2015-07-11 00:41:11 EDT LOG: startup process (PID 1693) exited with exit code 1
2015-07-11 00:41:11 EDT LOG: aborting startup due to startup process failure
I had several of these and was able to resolve them by changing the group and modifying the permissions on the noted files to match others in the directory, but I suspect the problem has more to do with how and/or where these packages were installed. After resolving the above issue, postgres still fails to start up, returning the following:
* Starting PostgreSQL 9.3 database server
* The PostgreSQL server failed to start. Please check the log output:
2015-07-11 00:30:04 EDT LOG: database system was interrupted; last known up at 2015-06-30 05:00:02 EDT
2015-07-11 00:30:04 EDT LOG: starting archive recovery
Traceback (most recent call last):
File "/usr/local/bin/wal-e", line 5, in <module>
from pkg_resources import load_entry_point
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3084, in <module>
#_call_aside
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3070, in _call_aside
f(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3097, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 651, in _build_master
ws.require(__requires__)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 952, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 839, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'wal-e==0.8.1' distribution was not found and is required by the application
2015-07-11 00:30:04 EDT LOG: invalid checkpoint record
2015-07-11 00:30:04 EDT FATAL: could not locate required checkpoint record
2015-07-11 00:30:04 EDT HINT: If you are not restoring from a backup, try removing the file "/var/lib/postgresql/9.3/main/backup_label".
2015-07-11 00:30:04 EDT LOG: startup process (PID 1495) exited with exit code 1
2015-07-11 00:30:04 EDT LOG: aborting startup due to startup process failure
It is complaining about the 'wal-e==0.8.1' distribution was not found..., but it is clearly installed and executable:
ls -l /usr/local/lib/python2.7/dist-packages
total 608
drwxr-sr-x 2 root staff 4096 Jul 10 20:14 argparse-1.3.0.dist-info
-rw-r--r-- 1 root staff 88400 Jul 10 20:14 argparse.py
-rw-r--r-- 1 root staff 65659 Jul 10 20:14 argparse.pyc
drwxr-sr-x 6 root staff 4096 Jul 9 22:36 azure
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 azure-0.11.1.egg-info
drwxr-sr-x 5 root staff 4096 Jul 9 22:36 babel
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 Babel-1.3.egg-info
drwxr-sr-x 57 root staff 4096 Jul 9 22:36 boto
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 boto-2.38.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 concurrent
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 dateutil
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 debtcollector
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 debtcollector-0.5.0.dist-info
-rw-r--r-- 1 root staff 207 Jul 10 20:10 easy-install.pth
-rw-r--r-- 1 root staff 126 Jul 10 20:33 easy_install.py
-rw-r--r-- 1 root staff 315 Jul 10 20:33 easy_install.pyc
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 futures-3.0.3.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 gevent
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 gevent-1.0.2.egg-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 greenlet-0.4.7.egg-info
-rwxr-xr-x 1 root staff 82869 Jul 9 22:36 greenlet.so
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 iso8601
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 iso8601-0.1.10.egg-info
drwxr-sr-x 15 root staff 4096 Jul 9 22:36 keystoneclient
drwxr-sr-x 2 root staff 4096 Jul 10 20:33 _markerlib
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 msgpack
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 msgpack_python-0.4.6.egg-info
drwxr-sr-x 5 root staff 4096 Jul 9 22:36 netaddr
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 netaddr-0.7.15.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 netifaces-0.10.4.egg-info
-rwxr-xr-x 1 root staff 58386 Jul 9 22:36 netifaces.so
drwxr-sr-x 4 root staff 4096 Jul 9 22:36 oslo
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 oslo_config
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 oslo.config-1.14.0.dist-info
-rw-r--r-- 1 root root 299 Jul 9 22:35 oslo.config-1.14.0-py2.7-nspkg.pth
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 oslo_i18n
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 oslo.i18n-2.1.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 oslo_serialization
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 oslo.serialization-1.7.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 oslo_utils
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 oslo.utils-1.8.0.dist-info
-rw-r--r-- 1 root root 299 Jul 9 22:35 oslo.utils-1.8.0-py2.7-nspkg.pth
drwxr-sr-x 5 root staff 4096 Jul 10 20:14 pbr
drwxr-sr-x 2 root staff 4096 Jul 10 20:14 pbr-1.3.0.dist-info
drwxr-sr-x 4 root staff 4096 Jul 10 20:10 pip-7.1.0-py2.7.egg
drwxr-sr-x 3 root staff 4096 Jul 10 20:33 pkg_resources
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 python_dateutil-2.4.2.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 python_keystoneclient-1.6.0.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 python_swiftclient-2.4.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 pytz
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 pytz-2015.4.dist-info
drwxr-sr-- 3 root staff 4096 Jul 9 23:25 requests
drwxr-sr-- 2 root staff 4096 Jul 9 23:25 requests-2.7.0.dist-info
drwxr-sr-x 3 root staff 4096 Jul 10 20:33 setuptools
drwxr-sr-x 2 root staff 4096 Jul 10 20:33 setuptools-18.0.1.dist-info
drwxr-sr-x 3 root staff 4096 Jul 9 22:36 simplejson
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 simplejson-3.7.3.egg-info
drwxr-sr-- 2 root staff 4096 Jul 9 23:26 six-1.9.0.dist-info
-rw-r--r-- 1 root root 29664 Jul 9 23:26 six.py
-rw-r--r-- 1 root root 29006 Jul 9 23:26 six.pyc
drwxr-sr-x 4 root staff 4096 Jul 9 22:36 stevedore
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 stevedore-1.6.0.dist-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 swiftclient
drwxr-sr-x 7 root staff 4096 Jul 9 22:35 wal_e
drwxr-sr-x 2 root staff 4096 Jul 9 22:35 wal_e-0.8.1.egg-info
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 wrapt
drwxr-sr-x 2 root staff 4096 Jul 9 22:36 wrapt-1.10.5.egg-info
I have done quite a bit of searching, but haven't found anything that helps. Any suggestions or points in the right direction are appreciated.
Additionally, it would be of great interest to solve this to ensure that my primary installation will behave in the event that a restoration is necessary. Backing up is pointless if I can't restore it.
I am not entirely sure what resolved the The 'wal-e==0.8.1' distribution was not found errro, but on rebooting I never saw that again.
Aside from that, fixing this was rather straightforward.
The executable bit on a number of python distributions was not set.
Chowning these fixed the error:
chmod o+x /usr/local/lib/python2.7/dist-packages/requests-2.7.0.dist-info/
chmod o+x /usr/local/lib/python2.7/dist-packages/requests
...
Reason backup_label is not created properly
Run the below command in your Master
su postgres
psql -c "select pg_start_backup('initial_backup');"
rsync -cva --inplace --exclude=pg_xlog
/var/lib/postgresql/9.1/main/
slave_IP_address:/var/lib/postgresql/9.1/main/
psql -c "select pg_stop_backup();"
cd /var/lib/postgresql/9.1/main
create file name recovery.conf add the below lines
standby_mode = 'on'
primary_conninfo = 'host=master_IP_address
port=5432 user=rep password=yourpassword' trigger_file =
'/tmp/postgresql.trigger.5432'
service postgresql restart
So i used THIS Tutorial from Eugene Ch'ng for setting up a MongoDB Shard-Cluster. Following all his steps works perfect.
My cluster contains 4 raspberry-pi (b+) and my MacBook.
After setting up my Config-Server (only one for now, due to hardware shortage), i came to the point where i should start the "mongos" instance. But there is none.
/opt/mongo/bin contains:
pi#pi01 /opt/mongo/bin $ ls -l
total 48536
-rwxr-xr-x 1 root root 4986476 May 28 20:16 bsondump
drwxr-xr-x 2 root root 4096 Jun 1 08:24 cfg0
-rw-r--r-- 1 root root 2376 May 29 10:34 log.cfg0
-rwxr-xr-x 1 root root 2734964 May 28 20:28 mongo
-rwxr-xr-x 1 root root 6942152 May 28 20:28 mongod
-rwxr-xr-x 1 root root 5006660 May 28 20:32 mongodump
-rwxr-xr-x 1 root root 4990416 May 28 20:36 mongoexport
-rwxr-xr-x 1 root root 5018040 May 28 20:39 mongofiles
-rwxr-xr-x 1 root root 5007712 May 28 20:43 mongoimport
-rwxr-xr-x 1 root root 4977940 May 28 20:47 mongooplog
-rwxr-xr-x 1 root root 4990044 May 28 20:50 mongoperf
-rwxr-xr-x 1 root root 5013980 May 28 20:54 mongorestore
Even this wasn't helping me:
sudo find / -name 'mongos'
Where can i find the 'mongos' process to start the mongodb route-server?
Thank you for your help in advance.