MongoDB, On rPi3B+(Factory ARM): Breaks after starting service

Hello everyone,

First time posting, and fairly new to SUSE, but I’m liking it so far :slight_smile:

So I’m working on a project that requires a local database on the rPi acting as a master for multiple ArdUno’s. The master stores data from the pi’s in it’s local storage. The db needs to run as a service if the Pi ever reboots.

I’ve outlined the problem on the Stack Exchange DB Admin group here:

After following everything on the wiki here:

I just can’t figure out if I’ve done something wrong, if it’s the factory ARM build of openSuse that’s the issue, or something else.

Does anyone in this community have any ideas what might be going wrong?

Thanks in advance!

Hi and welcome to the Forum :slight_smile:
If you switch to root user rather than using sudo how does it go?

When you say Arm Factory, you mean the Tumbleweed repositories or Factory (not advisable)?

My repos in use are (RPi3B);

zypper lr

Repository priorities are without effect. All enabled repositories share the same priority.

# | Alias                                 | Name                                  | Enabled | GPG Check | Refresh
1 | openSUSE-Ports-Tumbleweed-repo-debug  | openSUSE-Ports-Tumbleweed-repo-debug  | No      | ----      | ----   
2 | openSUSE-Ports-Tumbleweed-repo-oss    | openSUSE-Ports-Tumbleweed-repo-oss    | Yes     | (r ) Yes  | Yes    
3 | openSUSE-Ports-Tumbleweed-repo-update | openSUSE-Ports-Tumbleweed-repo-update | Yes     | (r ) Yes  | Yes

Just ran through the howto (ext4 here) and all runs as expected…

No unfortunately root didn’t change anything. Both logging in as root to start the service and running the shell from root.

The ARM factory thing was bad communication on my part. I grabbed my Pi image from here (JeOS):

The factory ARM I mentioned because of this and mistyped:

I have been using the tumble weed repository for mongodb. I’ll try using the factory arm repos but I don’t know if that will work because I’m using the Tumble Weed build of openSuse. Only one way to know for sure though.

I seem to be missing my update repo on my raspberry pi. That could be a difference between the JeOS and if you are using a different one. Will also try adding that repo to see if anything changes at all. You didn’t need to add a repo for mongo or did you just grab the ymp file?

The mongo db packages are available from the standard Tumbleweed repositories, no need to add the development version. Whilst they are the same versions they can be rebuilding against other packages and be out of sync with the rolling release versions…

I would uninstall and disable the repository server:database and run zypper dup to ensure the system is up to date, it should advise you it’s switching back to the openSUSE Tumbleweed versions.

This is what I have, do you have the same?

zypper if mongodb

Repository     : openSUSE-Ports-Tumbleweed-repo-oss                         
Name           : mongodb                                                    
Version        : 3.6.2-4.1                                                  
Arch           : aarch64

Also you are using zypper dup on your system to update, which is the Tumbleweed way?

zypper ref
zypper -vvv dup

The vvv adds some verbosity to see what is happening :wink:

The update repository is for ‘emergency’ releases of individual packages that may be broken, add via;

zypper ar -f -g -n "openSUSE-Ports-Tumbleweed-repo-update" openSUSE-Ports-Tumbleweed-repo-update

This is what I did;

zypper in mongodb

The following 5 NEW packages are going to be installed:
  mongodb mongodb-mongoperf mongodb-mongos mongodb-server mongodb-shell

5 new packages to install.
Overall download size: 37.1 MiB. Already cached: 0 B. After the operation, additional 134.0 MiB will be used.
Continue? [y/n/...? shows all options] (y): 
Retrieving package mongodb-mongoperf-3.6.2-4.1.aarch64                                                                                                    (1/5),  11.8 MiB ( 42.6 MiB unpacked)
(1/5) Installing: mongodb-mongoperf-3.6.2-4.1.aarch64 ...................................................................................................................................[done]

systemctl status mongodb.service 
● mongodb.service - High-performance, schema-free document-oriented database
   Loaded: loaded (/usr/lib/systemd/system/mongodb.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

vi /etc/mongodb.conf 
(I set to ipv4 only)

systemctl start mongodb.service

systemctl status mongodb.service
● mongodb.service - High-performance, schema-free document-oriented database
   Loaded: loaded (/usr/lib/systemd/system/mongodb.service; disabled; vendor preset: disabled)
   Active: active (running) since Sun 2019-01-06 04:08:46 UTC; 3s ago
  Process: 1150 ExecStart=/usr/sbin/mongod -f $CONFIG $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 1152 (mongod)
   Memory: 43.2M
   CGroup: /system.slice/mongodb.service
           └─1152 /usr/sbin/mongod -f /etc/mongodb.conf

Jan 06 04:08:45 statler3 systemd[1]: Starting High-performance, schema-free document-oriented database...
Jan 06 04:08:45 statler3 mongod[1150]: about to fork child process, waiting until server is ready for connections.
Jan 06 04:08:45 statler3 mongod[1150]: forked process: 1152
Jan 06 04:08:46 statler3 mongod[1150]: child process started successfully, parent exiting
Jan 06 04:08:46 statler3 systemd[1]: Started High-performance, schema-free document-oriented database.

netstat -plntu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0*               LISTEN      1152/mongod         


MongoDB shell version v3.6.2
connecting to: mongodb://
MongoDB server version: 3.6.2
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see
Questions? Try the support group
2019-01-06T04:09:20.395+0000 E -        [main] Error loading history file: FileOpenFailed: Unable to fopen() file /root/.dbshell: No such file or directory
> use admin
switched to db admin
> db.createUser({user:"admin", pwd:"admin123", roles:{role:"root", db:"admin"}]})
Successfully added user: {
    "user" : "admin",
    "roles" : 
            "role" : "root",
            "db" : "admin"
> exit

systemctl restart mongodb.service

systemctl status mongodb.service

● mongodb.service - High-performance, schema-free document-oriented database
   Loaded: loaded (/usr/lib/systemd/system/mongodb.service; disabled; vendor preset: disabled)
   Active: active (running) since Sun 2019-01-06 04:10:31 UTC; 3s ago
  Process: 1192 ExecStart=/usr/sbin/mongod -f $CONFIG $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 1194 (mongod)
   Memory: 142.6M
   CGroup: /system.slice/mongodb.service
           └─1194 /usr/sbin/mongod -f /etc/mongodb.conf

Jan 06 04:10:24 statler3 systemd[1]: Starting High-performance, schema-free document-oriented database...
Jan 06 04:10:24 statler3 mongod[1192]: about to fork child process, waiting until server is ready for connections.
Jan 06 04:10:24 statler3 mongod[1192]: forked process: 1194
Jan 06 04:10:30 statler3 mongod[1192]: child process started successfully, parent exiting
Jan 06 04:10:31 statler3 systemd[1]: Started High-performance, schema-free document-oriented database.

mongo -u admin -p admin123 --authenticationDatabase admin

MongoDB shell version v3.6.2
connecting to: mongodb://
MongoDB server version: 3.6.2
Server has startup warnings: 
2019-01-06T04:10:24.563+0000 I STORAGE  [initandlisten] 
2019-01-06T04:10:24.563+0000 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-01-06T04:10:24.563+0000 I STORAGE  [initandlisten] **          See
2019-01-06T04:10:30.877+0000 I CONTROL  [initandlisten] 
2019-01-06T04:10:30.877+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2019-01-06T04:10:30.877+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2019-01-06T04:10:30.877+0000 I CONTROL  [initandlisten] 
> exit

Yep, I had identical output from

zypper if mongodb

I just tried a fresh install of the JeOS image I linked in the OP.

In order:

  • I first assigned a new root passwd from the default 'linux" passwd.
  • I then checked my repo list and still only had 2, minus the update repo. Is that normal for a fresh install? Regardless I added the repo you linked, ran zypper ref, then zypper dup.
  • Then created a new user, ‘adduser newUser’, and assigned a passwd with ‘sudo passwd newUser’
  • Created a folder for the newUser in the home directory (does locate the user properly with cd ‘~’) & changed ownership of the home folder with, as the newUser ‘sudo chown -hR newUser /home/newUser’.

Now I began to follow what you did exactly in terminal.

My /etc/mongodb.conf file looks like this

# mongod.conf

# for documentation of all options, see:

# Where and how to store data.
  dbPath: /var/lib/mongodb
    enabled: true
#  engine:
#  mmapv1:
#  wiredTiger:

# Where and how to log messages.
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log
  logRotate: reopen

# What type of connections to allow.
  port: 27017
  ipv6: true

# How to manage mongod.
  fork: true

# Full path to pidfile (if not set, no pidfile is created)
  pidFilePath: /var/run/mongodb/

# Security settings.
  authorization: enabled




## Enterprise-Only Options:



When I tried to run systemctl start mongodb I got this:

Failed to start mongodb.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files
See system logs and 'systemctl status mongodb.service' for details.

So I ran it as sudo (I’m logged in as the newUser. Should I be in root?) without an issue and checked the status, to which it was running. After finishing exactly what you did I successfully ran show dbs as the admin user. So I ultimately think that it was my login attempt at the end of the wiki guide following creating the admin. Something about my syntax was wrong.

Thank you for your help in getting this working!

May I ask some a couple final parting questions?

  1. I should be good now since I’m just running the service, but I’d like to know why running mongod gets me this:
2019-01-06T19:10:03.154+0000 I CONTROL  [initandlisten] MongoDB starting : pid=1356 port=27017 dbpath=/data/db 64-bit host=localhost
2019-01-06T19:10:03.155+0000 I CONTROL  [initandlisten] db version v3.6.2
2019-01-06T19:10:03.155+0000 I CONTROL  [initandlisten] git version: 489d177dbd0f0420a8ca04d39fd78d0a2c539420
2019-01-06T19:10:03.155+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.1.0h-fips  27 Mar 2018
2019-01-06T19:10:03.155+0000 I CONTROL  [initandlisten] allocator: tcmalloc
2019-01-06T19:10:03.155+0000 I CONTROL  [initandlisten] modules: none
2019-01-06T19:10:03.155+0000 I CONTROL  [initandlisten] build environment:
2019-01-06T19:10:03.155+0000 I CONTROL  [initandlisten]     distarch: aarch64
2019-01-06T19:10:03.155+0000 I CONTROL  [initandlisten]     target_arch: aarch64
2019-01-06T19:10:03.155+0000 I CONTROL  [initandlisten] options: {}
2019-01-06T19:10:03.204+0000 I STORAGE  [initandlisten] exception in initAndListen: NonExistentPath: Data directory /data/db not found., terminating
2019-01-06T19:10:03.205+0000 I CONTROL  [initandlisten] now exiting
2019-01-06T19:10:03.205+0000 I CONTROL  [initandlisten] shutting down with code:100

I solved this previously before doing a fresh install of the JeOS by manually creating the /data/db directory. Why is this needed? My config file as show above is pointing data to the proper /var/lib/mongodb directory.

  1. Why does the wiki not add admin to the roles array when you do? Could that have been causing the login issues previously?

Even though it seems that it was likely just the syntax of the admin loggin, thanks for all your help!

Hmm, so did you restart the service and check the logs again? Does the directory /var/lib/mongodb exist? For me, that was the default location, wonder if the other version installed caused some confusion… does /data/db directory exist, if so would stop the service remove the /data/db directory and start the service.

Although I don’t ordinarily run MongoDB, skimming the SDB is an easy read… It doesn’t describe anything different than what you’d have to know and set up in practically any other modern RDBMS (eg MySQL, MSSQL, etc).

I don’t know for sure, but the red highlighted entries in the above quote might be your data path problem. The question is whether you manually edited files or those settings are default and incorrect.

From what you’ve described,

  1. Although you can manually set up Users and User Groups manually from the command line as you did, you might find that doing that in YaST can be easier, you can have the usual benefits of a graphical interface by easily listing and enabling User Groups you can assign, make various settings and not overlook anything.

  2. Unless you assign (and possibly create a special Group), only the System User root will have the rights to access, maintain and create in MongoDB in the beginning… And as described in the SDB the first thing you should do is create the MongoDB Admin User (ie root within MongoDB). Note that however it’s officially called, “Admin” and other accounts created in the MongoDB application are more than how a “role” is defined, it really is a whole new User but runs only within the MongoDB app. Using that Admin User, you can then create other Mongo Users and either administer databases directly or authorize other Users to access their own databases. And as you’ve discovered, ordinary System users do not have access to perform system actions like start/stop/enable a service. Only as root or elevating using sudo can you do extraordinary actions like system administration tasks.

  3. Are you asking whether Admin should be automatically granted rights to all databases? Maybe not. Probably not. But, of course it’s a good idea for one superuser to exist to back up in case something happens to your primary method of access. Admin should have full access to the overall MongoDB app, but could conceivably not have access to specific databases(Would have to study MongoDB closely to verify exactly this question).

I don’t see that you’re running “zypper dup” often, and especially after you’ve first installed. It should be done to ensure your system is updated with latest patches/fixes/enhancements.