Error child process failed exited with error number 100

I tried to install mongoDB on my macbook air.

I’ve downloaded zipped file from official website and extract that file and move to root directory.
After that, under that directory, I’ve made /data/db and /log folder.

Here is my mongodb.config which describes the basic config for my DB.

dbpath = /mongodb/data/db
logpath = /mongodb/log/mongo.log
logappend = true
#bind ip = 127.0.0.1
port = 27017

fork = true
rest = true
verbose = true
#auth = true
#noauth = true

Additionally, I want to know what the # means in the config file.

I put this file to /mongodb/bin, /mongodb is the directory I extracted the files into.

I opened terminal and entered ./mongod --config mongodb.config and I got this back.

Juneyoung-ui-MacBook-Air:bin juneyoungoh$ ./mongod --config mongodb.config
about to fork child process, waiting until server is ready for connections.
forked process: 1775
all output going to: /mongodb/log/mongo.log
ERROR: child process failed, exited with error number 100

How can I handle this error and what this means?

ERROR: child process failed, exited with error number 100 #21

Dear all
I’m trying to test the branin.py on the cluster (On my laptop every thing is OK), and I have the following error when I try to start mongo using command ; «mongod —fork —logpath —dbpath».

ERROR: child process failed, exited with error number 100

I have to mention that, when I type «mongo» on the cluster it says:

MongoDB shell version: 2.4.9
connecting to: test
Server has startup warnings:
Mon May 11 13:09:59.173 [initandlisten]
Mon May 11 13:09:59.173 [initandlisten] ** WARNING: You are running on a NUMA machine.
Mon May 11 13:09:59.173 [initandlisten] ** We suggest launching mongod like this to avoid performance problems:
Mon May 11 13:09:59.173 [initandlisten] ** numactl —interleave=all mongod [other options]
Mon May 11 13:09:59.173 [initandlisten]

So, I tried starting mongo using command; «numactl —interleave=all mongod —fork —logpath —dbpath», but didn’t see any difference in the output!

The text was updated successfully, but these errors were encountered:

Hi Mohammad, try running the same command without the —fork argument and
it will give you a more interpret-able error message.

On Mon, May 11, 2015 at 8:42 AM, Mehrian notifications@github.com wrote:

Dear all
I’m trying to test the branin.py on the cluster (On my laptop every thing
is OK), and I have the following error when I try to start mongo using
command ; «mongod —fork —logpath —dbpath».

ERROR: child process failed, exited with error number 100

I have to mention that, when I type «mongo» on the cluster it says:

MongoDB shell version: 2.4.9
connecting to: test
Server has startup warnings:
Mon May 11 13:09:59.173 [initandlisten]
Mon May 11 13:09:59.173 [initandlisten] ** WARNING: You are running on a
NUMA machine.
Mon May 11 13:09:59.173 [initandlisten] ** We suggest launching mongod
like this to avoid performance problems:
Mon May 11 13:09:59.173 [initandlisten] ** numactl —interleave=all mongod
[other options]
Mon May 11 13:09:59.173 [initandlisten]

So, I tried starting mongo using command; «numactl —interleave=all mongod
—fork —logpath —dbpath», but didn’t see any difference in the output!

—
Reply to this email directly or view it on GitHub
#21.

Hi Jasper
When I tried it without —fork, it seems that Mongo doesn’t start, because when I run the command «python main.py», the output is as follow. I think the problem is somehow related to the cluster. because I ran the branin.py on my laptop without any error! I’m wondering if I have to install additional stuff on the cluster!

Traceback (most recent call last):
File «main.py», line 198, in
from spearmint.utils.database.mongodb import MongoDB
ImportError: No module named spearmint.utils.database.mongodb

Can you show what the error message is when you run mongod without —fork?

On Tue, May 12, 2015 at 3:43 AM, Mehrian notifications@github.com wrote:

Hi Jasper
When I tried it without —fork, it seems that Mongo doesn’t start, because
when I run the command «python main.py», the output is as follow. I think
the problem is somehow related to the cluster. because I ran the branin.py
on my laptop without any error! I’m wondering if I have to install
additional stuff on the cluster!

Traceback (most recent call last):
File «main.py», line 198, in
from spearmint.utils.database.mongodb import MongoDB
ImportError: No module named spearmint.utils.database.mongodb

—
Reply to this email directly or view it on GitHub
#21 (comment).

There is no error when I run it without —fork! The output is like this:

log file [/home/mehrianmohammad/Spearmint-master/examples/simple/—dbpath] exists; copied to temporary file [/home/mehrianmohammad/Spearmint-master/examples/simple/—dbpath.2015-05-12T14-26-16]

Ok, that looks fine. You’ll likely just have to install spearmint with pip
«pip install -e

» or add the spearmint directory
to your pythonpath.

On Tue, May 12, 2015 at 10:26 AM, Mehrian notifications@github.com wrote:

There is no error when I run it without —fork! The output is like this:

log file [/home/mehrianmohammad/Spearmint-master/examples/simple/—dbpath]
exists; copied to temporary file
[/home/mehrianmohammad/Spearmint-master/examples/simple/—dbpath.2015-05-12T14-26-16]

—
Reply to this email directly or view it on GitHub
#21 (comment).

Hi Jasper
On the cluster that I have installed Spearmint package, I am NOT the administrative!
So, Would you please let me know what changes I have to made while installing the package from the beginning to use it as a normal user?
I think lots of my errors are because the fact that I don’t have access to some administrative files.

Also, I install spearmint again! («pip install -e

«), and I have no more that child process error for one day!! and again today I see that error (I think these are all because I’m NOT the admin on the cluster!)

Thanks in advance,
Mohammad

Hi Mehrian, that unfortunately often depends on the exact configuration on
the cluster. However, I’d recommend installing the anaconda python
distribution. They allow you to run it in a virtual environment that
doesn’t require admin privileges.

On Wed, May 27, 2015 at 10:40 AM, Mehrian notifications@github.com wrote:

Hi Jasper
On the cluster that I have installed Spearmint package, I am NOT the
administrative!

So, Would you please let me know what changes I have to made while
installing the package from the beginning to use it as a normal user?
I think lots of my errors are because the fact that I don’t have access to
some administrative files.
Thanks in advance,
Mohammad

—
Reply to this email directly or view it on GitHub
#21 (comment).

Источник

ERROR: child process failed exited with error number 100 #504

I have the FACT 3.2-dev version.
Sometimes during the analysis I noticed that it comes in some points and gets stuck until I close the tool to cancel the analysis in progress. From the debug version log I noticed this:

OSError: [Errno 5] Input / output error

ERROR: child process failed, exited with error number 100

and then this message appears in a loop:
[Unpacking] [DEBUG] throttle down unpacking to reduce memory consumption .

This happens only with the analysis of some firmware, others have been completed correctly. What could be the problem/solution?

The text was updated successfully, but these errors were encountered:

The throttling was built in to reduce issues with limited system resources (especially RAM). If the load of the analysis process is too high, the addition of new files to the unpacking / analysis process gets delayed.
There should be a different reason for the failing child processes. Did you maybe run out of RAM during the analysis? It could be that this only happens during the analysis of larger firmware. If so, you could try to limit the number of worker processes in the main.cfg .

In the attached image the situation of the system at the time of the block. The 3 components are on a single virtual machine. The analysis has been running like this for more than 12 hours, so I think the machine must be restarted now with the loss of the analysis in progress or is there some way to make the analysis restart from where it stopped?

Sadly, resuming an analysis is currently not possible. Some operations are cached in the database but not the actual files that are currently in the analysis or unpacking process. It’s definitely on our agenda for future scheduling improvements. Of course intermediate analysis results up to that point are stored in the database.

I noticed that the errors mentioned in the first post occur if the cwe_checker (mostly) and input vector plugins are present in the analysis. Having 16 cores and 64gb of ram available, could this be due to some unhandled exception in these plugins?

When an analysis is blocked how can the current analysis be canceled? Is there any way other than rebooting the machine?

If I had to do a git pull to update the release with the latest updated files on github (hoping that the problem is solved) the application might not work anymore? should I reinstall everything losing the analyzes already carried out?

Thanks for the attention!

If I had to do a git pull to update the release with the latest updated files on github (hoping that the problem is solved) the application might not work anymore? should I reinstall everything losing the analyzes already carried out?

We try to watch out for backwards compatibility. So normally, this should not be an issue and you should not lose any data or analyses. It is important that you keep your passwords from the main config file if you changed them, because they are needed for authorization with the database. If there were some changes to plugins, etc. it should be enough to rerun the install.py script with parameters -B for backend or -F for the frontend. If it runs on a VM you could also make a snapshot to be safe.

When an analysis is blocked how can the current analysis be canceled? Is there any way other than rebooting the machine?

Sadly, there is currently no other way than shutting down the backend to cancel an analysis. But this is definitely a point on our ToDo list.

I noticed that the errors mentioned in the first post occur if the cwe_checker (mostly) and input vector plugins are present in the analysis. Having 16 cores and 64gb of ram available, could this be due to some unhandled exception in these plugins?

The cwe_checker plugin does not run 100% stably at the moment. Did you per chance find any stack traces, etc. in the backend output that might let us infer what went wrong?

Источник

Mongodb wont start ERROR: child process failed, exited with error number 100

Mongodb: Actual error is “Insufficient free space for journal files“.

Before discussing about the error, I will give you a short information about Mongodb. Mongodb is a free and open source software for platform document-oriented database.

A document-oriented database is a computer program designed for storing, retrieving, and managing document-oriented information. It also known as semi-structured data.

Here I got this error after successfully completing the installation process of MongoDB on a VPS. And finally found a solution. I like to share the steps I did to fix this error.

After complete the installation successfully, the ‘Mongodb’ shows some error with its restart. The error details are pasted below:

Example:

Log file details

Solution

Ist Step: At first, you need to run the follwing command before editing the configuration file(/etc/mongod.conf).

IIInd Step: Change/Add/uncomment the value for the directive ‘nojournal’ in the configuration file(/etc/mongod.conf) to true

IIIrd Step: Save and restart the service:

Some interesting topics on Mongo

• This includes the steps to dump Mongo DB.
• AWS cli command to move to S3 bucket.
• A simple bash script for automation purpose.

• This includes the steps to dump Mongo DB collections.
• AWS cli command to move to S3 bucket.
• A simple bash script for automation purpose.

Post navigation

Arunlal Ashok

10 thoughts on “ Mongodb wont start ERROR: child process failed, exited with error number 100 ”

Thanks for your feedback. 🙂

We have faced the problem like(Starting mongod: about to fork child process, waiting until server is ready for connections.
forked process),so we are followed the step 1 and step 2 like that ,but did not working this command ,so please help me ?

Please do check the log file for Mongodb. Is the error same as before?

We are facing error follwoing this,

Mon Aug 18 10:36:46.976 [initandlisten] MongoDB starting : pid=3547 port=27017 dbpath=/var/lib/mongo 32-bit host=srv01.nayasoft.local
Mon Aug 18 10:36:46.976 [initandlisten]
Mon Aug 18 10:36:46.976 [initandlisten] ** NOTE: This is a 32 bit MongoDB binary.
Mon Aug 18 10:36:46.976 [initandlisten] ** 32 bit builds are limited to less than 2GB of data (or less with –journal).
Mon Aug 18 10:36:46.976 [initandlisten] ** Note that journaling defaults to off for 32 bit and is currently off.
Mon Aug 18 10:36:46.976 [initandlisten] ** See http://dochub.mongodb.org/core/32bit
Mon Aug 18 10:36:46.976 [initandlisten]
Mon Aug 18 10:36:46.976 [initandlisten] db version v2.4.9
Mon Aug 18 10:36:46.976 [initandlisten] git version: 52fe0d21959e32a5bdbecdc62057db386e4e029c
Mon Aug 18 10:36:46.976 [initandlisten] build info: Linux bs-linux32.10gen.cc 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686 BOOST_LIB_VERSION=1_49
Mon Aug 18 10:36:46.976 [initandlisten] allocator: system
Mon Aug 18 10:36:46.976 [initandlisten] options: < config: “/etc/mongod.conf”, dbpath: “/var/lib/mongo”, fork: “true”, logappend: “true”, logpath: “/var/log/mongo/mongod.log”, nojournal: “true”, pidfilepath: “/var/run/mongodb/mongod.pid” >

Works perfect now. Thank you so much.

Thanks for this feedback.

hello sir,
we are facing the errors on setting the replica set to the local server

Im getting same error in windows please i need that tutorial for widows user , if someone can help please comment

Источник

Служба MongoDB не начнется после начальной настройки

Я запускаю Fedora 20 и устанавливаю MongoDB в Руководство по установке Red Hat в официальной документации. Мне удалось запустить демон mongod как услугу без ошибок в первый раз, но когда я выключил машину и вернулся, служба отказалась запускать из-за некоторого сбоя.

В моем журнале, указанном после успешного запуска, я вижу следующее:

Если я попытаюсь запустить mongod или запустить mongod —repair вручную, я получаю это сообщение при ошибке запуска:

Это странно, учитывая, что в моем файле конфигурации в /etc/mongod.conf параметры для пути к базе данных следующие:

Наконец, если я запустил эту команду:

Демон запускается просто отлично. Однако я не могу воспроизвести это поведение без ошибок для запуска службы.

Может ли кто-нибудь сказать мне, что именно не так, и как я могу запустить mongod в качестве службы?

Я получаю это сообщение, если я запустил mongod —config /etc/mongod.conf :

about to fork child process, waiting until server is ready for connections. forked process: 2702 ERROR: child process failed, exited with error number 1

Каталог /var/run/mongodb не существует, поэтому я создал и назначил его пользователю mongod. К сожалению, это не имело большого значения.

My /var/log/mongodb/mongod.log показывает это сообщение:

[initandlisten] exception in initAndListen: 10309 Unable to create/open lock file: /var/lib/mongo/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating

Что работало для меня на Fedora 20: нам нужно создать временную директорию при каждой загрузке и обрабатывать systemd-tmpfiles. Итак, создайте файл /lib/tmpfiles.d/mongodb.conf и поместите в него одну строку:

Кажется, что он справляется с перезагрузкой; если вы не хотите перезапускать сразу, вы можете выполнить это с помощью:

(см. справочные страницы для файлов systemd-tmp)

У меня такая же проблема, я решил ее временно, отключив SELinux, перезагрузил машину, исключил mongod.lock:

Создав файл /var/run/mongodb/mongo.pid(как указано в файле конфигурации /etc/mongod.conf):

и дает 777 разрешений:

Но проблема сохраняется после перезагрузки машины. Папка и файл исчезнут.

Я потратил некоторое время на это, и кажется, что папка pid и права доступа к файлу не работают с демонами по умолчанию.

Самое простое решение, с которым я столкнулся, – отключить файл pid, просто поместив # перед строкой в ​​файле конфигурации.

найдите строку, которая говорит pidfilepath =/var/run/mongodb/mongod.pid и соответствующим образом измените ее.

Если вы запускаете mongod в качестве службы, используя:

Убедитесь, что каталоги, определенные для путей журнала, dbpath и pidfilepath в вашем mongod.conf, существуют и принадлежат mongod: mongod.

У меня была такая же проблема с запуском mongodb 3.0.4 на OpenSuse 13.2, и я обнаружил, что каталог mongod в /var/run отсутствует. Если я создам каталог вручную, он исчезнет после перезагрузки.

Я решил это, добавив следующие строки в мой запуск /etc/init.d/mongod script:

Нам нужно создать расположение temp dir pidfile /var/run/mongodb , которое обрабатывается systemd-tmpfiles. Итак, создайте файл /lib/tmpfiles.d/mongodb.conf как root:

lnx # > sudo su
lnx # > cd/lib/tmpfiles.d
lnx # > echo “d/var/run/mongodb 0755 mongod mongod” > mongodb.conf

Затем перезагрузите или запустите эту команду, чтобы активировать этот каталог temp:

lnx # > sudo systemd-tmpfiles –create mongodb.conf

Запустите службу mongod:

lnx # > sudo systemctl start mongod.service

Библиография: Fedora And Mongodb · l33tsource http://goo.gl/XzgSDd

я встретил ту же проблему, когда я изменяю свой mongod.conf следующим образом и проблема решена.

tips: logpath – это файл журнала, а не папка.

Я просто испытываю подобную проблему на ubuntu. Обнаружены почти все советы ERROR, например

или child process failed, exited with error number 100

или [signalProcessingThread] got signal 2 (Interrupt: 2), will terminate after current cmd ends

Много раз я удаляю Mongodb и пытаюсь установить его снова, но проблема остается…

Наконец, я пришел к такому пути:
Сначала создайте резервную копию данных, затем удалите Mongodb с помощью

Узнайте все файлы, связанные с mongodb:

Удалите их все с помощью “rm” или “rmdir”, включая пакеты в /var/cache/… и everthing.

Источник

I just upgraded to Fedora 28 and now my mongod service doesn’t launch anymore.

One possible solution that would fork in my case would be to be able to downgrade mongodb to 3.4, as the system upgrade moved it to 3.6.

Bellow is a report of an shell session aiming at gathering data on this issue:

▶ sudo systemctl start mongod                     
Job for mongod.service failed because the control process exited with error code.
# systemctl status mongod.service
See "systemctl status mongod.service" and "journalctl -xe" for details.
● mongod.service - High-performance, schema-free document-oriented database
   Loaded: loaded (/usr/lib/systemd/system/mongod.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2018-05-03 16:47:11 CEST; 9min ago
  Process: 5132 ExecStart=/bin/sh -c exec $NUMACTL /usr/bin/mongod $OPTIONS run (code=exited, status=100)

May 03 16:47:10 localhost.localdomain systemd[1]: Starting High-performance, schema-free document-oriented database...
May 03 16:47:10 localhost.localdomain sh[5132]: about to fork child process, waiting until server is ready for connections.
May 03 16:47:10 localhost.localdomain sh[5132]: forked process: 5134
May 03 16:47:11 localhost.localdomain sh[5132]: ERROR: child process failed, exited with error number 100
May 03 16:47:11 localhost.localdomain sh[5132]: To see additional information in this output, start without the "--fork" option.
May 03 16:47:11 localhost.localdomain systemd[1]: ^[[0;1;39m^[[0;1;39mmongod.service: Control process exited, code=exited status=100
May 03 16:47:11 localhost.localdomain systemd[1]: ^[[0;1;39m^[[0;1;39mmongod.service: Failed with result 'exit-code'.
May 03 16:47:11 localhost.localdomain systemd[1]: ^[[0;1;39mFailed to start High-performance, schema-free document-oriented database.

▶ grep path /etc/mongod.conf
  path: /var/log/mongodb/mongod.log
  # Append to logpath instead of over-writing (false by default)
  # Full path to pidfile (if not set, no pidfile is created)
    pathPrefix: /var/run/mongodb


▶ sudo chown mongodb /var/lib/mongodb

▶ sudo mongod --fork --logpath /var/log/mongodb.log
[sudo] Mot de passe de psychoslave : 
about to fork child process, waiting until server is ready for connections.
forked process: 11983
ERROR: child process failed, exited with error number 100
To see additional information in this output, start without the "--fork" option.

▶ sudo mongod --dbpath=/var/lib/mongodb                                                                                       [130/222]
2018-05-03T16:32:19.824+0200 I CONTROL  [initandlisten] MongoDB starting : pid=29148 port=27017 dbpath=/var/lib/mongodb 64-bit host=loc
alhost.localdomain                                                                                                               
2018-05-03T16:32:19.824+0200 I CONTROL  [initandlisten] db version v3.6.3                                                             
2018-05-03T16:32:19.824+0200 I CONTROL  [initandlisten] git version: nogitversion                                                 
2018-05-03T16:32:19.824+0200 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.1.0h-fips  27 Mar 2018                   
2018-05-03T16:32:19.824+0200 I CONTROL  [initandlisten] allocator: tcmalloc
2018-05-03T16:32:19.825+0200 I CONTROL  [initandlisten] modules: none                                                                  
2018-05-03T16:32:19.825+0200 I CONTROL  [initandlisten] build environment:                                                             
2018-05-03T16:32:19.825+0200 I CONTROL  [initandlisten]     distarch: x86_64                         
2018-05-03T16:32:19.825+0200 I CONTROL  [initandlisten]     target_arch: x86_64                                                 
2018-05-03T16:32:19.825+0200 I CONTROL  [initandlisten] options: { storage: { dbPath: "/var/lib/mongodb" } }
2018-05-03T16:32:19.825+0200 I -        [initandlisten] Detected data files in /var/lib/mongodb created by the 'wiredTiger' storage eng
ine, so setting the active storage engine to 'wiredTiger'.                                                                            
2018-05-03T16:32:19.825+0200 I STORAGE  [initandlisten]                                                                                
2018-05-03T16:32:19.825+0200 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTige
r storage engine                                                                                                                       
2018-05-03T16:32:19.825+0200 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem           
2018-05-03T16:32:19.825+0200 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=5444M,session_max=20000,eviction=(thr
eads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manag
er=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),                                                      
2018-05-03T16:32:20.628+0200 I STORAGE  [initandlisten] WiredTiger message [1525357940:628222][29148:0x7fb1dd26fa80], txn-recover: Main
 recovery loop: starting at 648/768                                                                                                   
2018-05-03T16:32:20.698+0200 I STORAGE  [initandlisten] WiredTiger message [1525357940:698440][29148:0x7fb1dd26fa80], txn-recover: Reco
vering log 648 through 649                                                                                                             
2018-05-03T16:32:20.785+0200 I STORAGE  [initandlisten] WiredTiger message [1525357940:785494][29148:0x7fb1dd26fa80], txn-recover: Reco
vering log 649 through 649                                                                                                             
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten]                                                                                 
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.                   
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten] ** WARNING: You are running this process as the root user, which is not recomme
nded.                                                                                                                                  
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten]           
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten] ** WARNING: This server is bound to localhost.
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten] **          Remote systems will be unable to connect to this server.
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten] **          Start the server with --bind_ip <address> to specify which IP
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten] **          addresses it should serve responses from, or with --bind_ip_all to
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten] **          bind to all interfaces. If this behavior is desired, start the
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten] **          server with --bind_ip 127.0.0.1 to disable this warning.
2018-05-03T16:32:21.569+0200 I CONTROL  [initandlisten]
2018-05-03T16:32:21.686+0200 F CONTROL  [initandlisten] ** IMPORTANT: UPGRADE PROBLEM: The data files need to be fully upgraded to vers
ion 3.4 before attempting an upgrade to 3.6; see http://dochub.mongodb.org/core/3.6-upgrade-fcv for more details.
2018-05-03T16:32:21.686+0200 I NETWORK  [initandlisten] shutdown: going to close listening sockets...
2018-05-03T16:32:21.686+0200 I NETWORK  [initandlisten] removing socket file: /tmp/mongodb-27017.sock
2018-05-03T16:32:21.686+0200 I REPL     [initandlisten] shutdown: removing all drop-pending collections...
2018-05-03T16:32:21.686+0200 I REPL     [initandlisten] shutdown: removing checkpointTimestamp collection...
2018-05-03T16:32:21.687+0200 I STORAGE  [initandlisten] WiredTigerKVEngine shutting down
2018-05-03T16:32:22.610+0200 I STORAGE  [initandlisten] WiredTiger message [1525357942:610149][29148:0x7fb1dd26fa80], txn-recover: Main
 recovery loop: starting at 649/4096
2018-05-03T16:32:22.681+0200 I STORAGE  [initandlisten] WiredTiger message [1525357942:681792][29148:0x7fb1dd26fa80], txn-recover: Reco
vering log 649 through 650
2018-05-03T16:32:22.762+0200 I STORAGE  [initandlisten] WiredTiger message [1525357942:762498][29148:0x7fb1dd26fa80], txn-recover: Reco
vering log 650 through 650
2018-05-03T16:32:23.549+0200 I STORAGE  [initandlisten] shutdown: removing fs lock...
2018-05-03T16:32:23.550+0200 I CONTROL  [initandlisten] now exiting
2018-05-03T16:32:23.550+0200 I CONTROL  [initandlisten] shutting down with code:62

And that’s basically where I’m stuck right now, as the documentation on upgrade process assume that one can actually run the server and run a command like

db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )

The obvious idea for downgrading would be to use the package manager to do so, but this won’t work:

▶ sudo dnf downgrade mongodb
Package mongodb of lowest version already installed, cannot downgrade it.
Error: No packages marked for downgrade.

On the other hand, dnf reinstall mongodb seems not enough to establish a working fresh install to explore the 3.6 path.

What should I do to ever downgrade to 3.4 or make the 3.6 version run? A solution which drop the db is fine, this is a development station, I have a backup ready to be imported, although it’s a dump from a mongo 3.4 instance.