systemd stops OrientDB immediately after it starts on Ubuntu 16.04 - orientdb

I'm trying trying to make OrientDB run as a daemon (enabled on start) on Ubuntu 16.04 LTS. The problem is, systemd appears to call stop immediately after I tell it to start. I have this systemd service file exactly as recommended in the OrientDB documentation:
[Unit]
Description=OrientDB Server
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
Type=forking
ExecStart=$ORIENTDB_HOME/bin/orientdb.sh start
ExecStop=$ORIENTDB_HOME/bin/orientdb.sh stop
ExecStatus=$ORIENTDB_HOME/bin/orientdb.sh status
orientdb.log:
.
.` `
, `:.
`,` ,:`
.,. :,,
.,, ,,,
. .,.::::: ```` ::::::::: :::::::::
,` .::,,,,::.,,,,,,`;; .: :::::::::: ::: :::
`,. ::,,,,,,,:.,,.` ` .: ::: ::: ::: :::
,,:,:,,,,,,,,::. ` ` `` .: ::: ::: ::: :::
,,:.,,,,,,,,,: `::, ,, ::,::` : :,::` :::: ::: ::: ::: :::
,:,,,,,,,,,,::,: ,, :. : :: : .: ::: ::: :::::::
:,,,,,,,,,,:,:: ,, : : : : .: ::: ::: :::::::::
` :,,,,,,,,,,:,::, ,, .:::::::: : : .: ::: ::: ::: :::
`,...,,:,,,,,,,,,: .:,. ,, ,, : : .: ::: ::: ::: :::
.,,,,::,,,,,,,: `: , ,, : ` : : .: ::: ::: ::: :::
...,::,,,,::.. `: .,, :, : : : .: ::::::::::: ::: :::
,::::,,,. `: ,, ::::: : : .: ::::::::: ::::::::::
,,:` `,,.
,,, .,`
,,. `, GRAPH DATABASE
`` `.
`` orientdb.com
`
pid file detected, killing process
syslog:
Jul 28 18:56:34 ubuntu systemd[1]: Starting OrientDB Server...
Jul 28 18:56:34 ubuntu orientdb.sh[17487]: Starting OrientDB server daemon...
Jul 28 18:56:34 ubuntu systemd[1]: Created slice User Slice of orientdb.
Jul 28 18:56:34 ubuntu systemd[1]: Starting User Manager for UID 999...
Jul 28 18:56:34 ubuntu systemd[1]: Started Session c5 of user orientdb.
Jul 28 18:56:34 ubuntu systemd[17497]: Reached target Timers.
Jul 28 18:56:34 ubuntu systemd[17497]: Reached target Paths.
Jul 28 18:56:34 ubuntu systemd[17497]: Reached target Sockets.
Jul 28 18:56:34 ubuntu systemd[17497]: Reached target Basic System.
Jul 28 18:56:34 ubuntu systemd[17497]: Reached target Default.
Jul 28 18:56:34 ubuntu systemd[17497]: Startup finished in 23ms.
Jul 28 18:56:34 ubuntu systemd[1]: Started User Manager for UID 999.
Jul 28 18:56:34 ubuntu orientdb.sh[17508]: Stopping OrientDB server daemon...
Jul 28 18:56:34 ubuntu systemd[1]: Started Session c6 of user orientdb.
Jul 28 18:56:34 ubuntu systemd[1]: Started OrientDB Server.
Jul 28 18:56:34 ubuntu systemd[1]: Stopping User Manager for UID 999...
Jul 28 18:56:34 ubuntu systemd[17497]: Reached target Shutdown.
Jul 28 18:56:34 ubuntu systemd[17497]: Starting Exit the Session...
Jul 28 18:56:34 ubuntu systemd[17497]: Stopped target Default.
Jul 28 18:56:34 ubuntu systemd[17497]: Stopped target Basic System.
Jul 28 18:56:34 ubuntu systemd[17497]: Stopped target Timers.
Jul 28 18:56:34 ubuntu systemd[17497]: Stopped target Paths.
Jul 28 18:56:34 ubuntu systemd[17497]: Stopped target Sockets.
Jul 28 18:56:34 ubuntu systemd[17497]: Received SIGRTMIN+24 from PID 17536 (kill).
Jul 28 18:56:34 ubuntu systemd[1]: Stopped User Manager for UID 999.
Jul 28 18:56:34 ubuntu systemd[1]: Removed slice User Slice of orientdb.
Any ideas?


As long as you wrap custom init scripts (orientdb.sh
, server.sh, shutdown.sh) in a systemd service unit, you will have strange and hard to debug issues.
Instead, you should read those scripts, understand how they launch OrientDB and reproduce only what is necessary in a service unit.


I've added a user & group orientdb to the system and used below systemd script (assuming orientdb is installed in /opt/orientdb):
[Unit]
Description=OrientDB Server
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
User=orientdb
Group=orientdb
ExecStart=/opt/orientdb/bin/server.sh
ExecStop=/opt/orientdb/bin/shutdown.sh
ExecReload=/bin/kill -HUP $MAINPID


If you run the server and close the window, the server will be closed. Use it with NOHUP (server.sh) and if you close the window it will continue running.
I had the same problem, good luck


I had the same issue with OpenSuse Leap 42.1 and OrientDB 2.2.7.
Roberto's answer solved it. See the issue on GitHub.

Related

MongoDB keeps crashing--is it running out of memory or CPU?

I have an issue where MongoDB keeps crashing on me:
$ sudo cat /var/log/syslog ->
Nov 28 14:06:58 ns557017 systemd[1]: mongod.service: Main process exited, code=killed, status=6/ABRT
Nov 28 14:06:58 ns557017 systemd[1]: mongod.service: Unit entered failed state.
Nov 28 14:06:58 ns557017 systemd[1]: mongod.service: Failed with result 'signal'.
Nov 28 14:06:59 ns557017 systemd[1]: mongod.service: Service hold-off time over, scheduling restart.
Nov 28 14:06:59 ns557017 systemd[1]: Stopped MongoDB Database Server.
I am using Mongo's free monitoring, and it points me towards the CPU being overused:
However if I look at htop, the CPU always seems fine:
How can I deduce what is causing Mongo to crash on me? Thanks

Getting "mongod: command not found". Analysis found that rpm is getting deleted

I am evaluating mongodb Enterprise version. I have it running in a RedHat Linux OS. Things were going good till mongod command stopped working suddenly. Our unix admins replied that rpm is getting deleted.
Here is the information i got from admins Any idea on this?
Oct 23 15:39:20 systemd[1]: [/usr/lib/systemd/system/mongod.service:27] Unknown lvalue 'TasksMax' in section 'Service'
Oct 23 15:39:20 systemd[1]: [/usr/lib/systemd/system/mongod.service:28] Unknown lvalue 'TasksAccounting' in section 'Service'
Oct 23 15:39:20 systemd[1]: Started Flexible Branding Service.
Oct 23 15:39:20 systemd[1]: Starting Flexible Branding Service...
Oct 23 15:39:20 yum[93405]: Erased: mongodb-enterprise-server-3.4.9-1.el7.x86_64
Oct 23 15:39:20 yum[93405]: Erased: 1:net-snmp-5.7.2-28.el7.x86_64
Oct 23 15:39:20 systemd[1]: Reloading.
Oct 23 15:39:20 systemd[1]: Started Flexible Branding Service.
Oct 23 15:39:20 systemd[1]: Starting Flexible Branding Service... "
Appreciate your help.
Thanks,
Harin

The systemd introduced this TasksMax setting in version 226
You need to check your version SYSTEMD
sudo systemd --version or sudo systemctl --version
If you systemd is old that the above you need to update link to update systemd
https://linoxide.com/linux-how-to/install-systemd-centos-redhat/

Try this: Set the SELINUX variable in the /etc/selinux/config file like follows:
SELINUX = disabled
Then restart MongoDB.
regards,

Filebeat Service will not start on RHEL 7

I have a trouble/problem with my Filebeat installation.
When I try it to start with "service filebeat start", it says "Starting Filebeat". After "service filebeat status" I get 4 PIDs (until here everything looks "normal"):
[root#(Server) run]# service filebeat status
Filebeat is running with pid: 30650 30657 30658 30659
But after checking the PID, we see that it is not running:
[root#(Server) run]# ps -ef | grep 30650
root 30665 31360 0 16:27 pts/0 00:00:00 grep --color=auto 30650
Trying to start it with systemctl doesn't help:
[root#(Server) run]# systemctl start filebeat
Job for filebeat.service failed because a configured resource limit was exceeded. See "systemctl status filebeat.service" and "journalctl -xe" for details.
Status says:
[root#Server run]# systemctl status filebeat
● filebeat.service - LSB: start and stop filebeat
Loaded: loaded (/etc/rc.d/init.d/filebeat; bad; vendor preset: disabled)
Active: failed (Result: resources) since Tue 2017-09-26 16:30:33 CEST; 1min 41s ago
Docs: man:systemd-sysv-generator(8)
Process: 32118 ExecStart=/etc/rc.d/init.d/filebeat start (code=exited, status=0/SUCCESS)
Sep 26 16:30:33 Server... systemd[1]: Starting LSB: start and stop filebeat...
Sep 26 16:30:33 Server... filebeat[32118]: Starting Filebeat
Sep 26 16:30:33 Server... su[32119]: (to user) root on none
Sep 26 16:30:33 Server... systemd[1]: PID file /var/run/filebeat.pid not readable (yet?) after start.
Sep 26 16:30:33 Server... systemd[1]: Failed to start LSB: start and stop filebeat.
Sep 26 16:30:33 Server... systemd[1]: Unit filebeat.service entered failed state.
Sep 26 16:30:33 Server... systemd[1]: filebeat.service failed.
Does somebody has any idea?
Regards

Problem was "chown permissions". I installed filebeat not as root and the "data" directory had root user & group ownership. After changing that, it runs and starts automatically after boot.
Regards

systemd: recover from systemctl hang

I have a custom systemd ".service" file, like this one:
[Unit]
Description=MyStuff
After=syslog.target
After=network.target
After=local-fs.target
After=remote-fs.target
[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/local/MyStuff/start
ExecReload=/bin/kill $MAINPID && /usr/bin/cat /var/run/MyStuff.pid | /usr/bin/xargs --no-run-if-empty /bin/kill
ExecStop=/bin/kill $MAINPID && /usr/bin/cat /var/run/MyStuff.pid | /usr/bin/xargs --no-run-if-empty /bin/kill
ExecStartPost=/usr/local/MyStuff/after_start.sh
PIDFile=/var/run/MyStuff.pid
#RemainAfterExit=yes
TimeoutSec=300
Restart=always
RestartSec=10
[Install]
WantedBy=multi-user.target
It worked fine until minutes ago. A systemctl stop MyStuff hung this way:
[root#Live-1 ffmpeg]# systemctl status WowzaStreamingEngine
● MyStuff.service - MyStuff
Loaded: loaded (/usr/lib/systemd/system/MyStuff.service; enabled; vendor preset: disabled)
Active: deactivating (final-sigkill) (Result: timeout) since vie 2017-07-28 11:12:23 -03; 23min ago
Main PID: 25149
CGroup: /system.slice/MyStuff.service
jul 28 11:12:23 Live-1 kill[10382]: kill: cannot find process "/usr/bin/cat"
jul 28 11:12:23 Live-1 kill[10382]: kill: cannot find process "/var/run/MyStuff.pid"
jul 28 11:12:23 Live-1 kill[10382]: kill: cannot find process "|"
jul 28 11:12:23 Live-1 kill[10382]: kill: cannot find process "/usr/bin/xargs"
jul 28 11:12:23 Live-1 kill[10382]: kill: cannot find process "--no-run-if-empty"
jul 28 11:12:23 Live-1 kill[10382]: kill: cannot find process "/bin/kill"
jul 28 11:12:23 Live-1 systemd[1]: MyStuff.service: control process exited, code=exited status=1
jul 28 11:17:24 Live-1 systemd[1]: MyStuff.service stop-sigterm timed out. Killing.
jul 28 11:22:24 Live-1 systemd[1]: MyStuff.service still around after SIGKILL. Ignoring.
jul 28 11:31:22 Live-1 systemd[1]: MyStuff.service stop-final-sigterm timed out. Killing.
I know there are errors reported there. That is not the problem; I'm not asking about those errors. The problem is: systemd/systemctl hangs in that state, and i'm unable to do start/stop/restart actions because all of them stays waiting forever.
What i need to know is a way around that state. This time I just rebooted the server, because it was development environment. But i can't just deal this way on production.
So: when systemd/systemctl hangs this way, what can I do in order to recover my service from this state without rebooting the server?
Thanks in advance.

Could not start RStudio Server 0.99.893-x86_64

I installed it a Centos 7 box.
R studio server service could not start.
I run the command
systemctl status rstudio-server.service
and it showed:
● rstudio-server.service - RStudio Server
Loaded: loaded (/etc/systemd/system/rstudio-server.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Thu 2016-01-28 20:18:20 ICT; 1min 6s ago
Process: 48820 ExecStart=/usr/lib/rstudio-server/bin/rserver (code=exited, status=203/EXEC)
Jan 28 20:18:20 localhost.localdomain systemd[1]: rstudio-server.service: control process exited, code=exited s...=203
Jan 28 20:18:20 localhost.localdomain systemd[1]: Failed to start RStudio Server.
Jan 28 20:18:20 localhost.localdomain systemd[1]: Unit rstudio-server.service entered failed state.
Jan 28 20:18:20 localhost.localdomain systemd[1]: rstudio-server.service failed.
Jan 28 20:18:20 localhost.localdomain systemd[1]: rstudio-server.service holdoff time over, scheduling restart.
Jan 28 20:18:20 localhost.localdomain systemd[1]: start request repeated too quickly for rstudio-server.service
Jan 28 20:18:20 localhost.localdomain systemd[1]: Failed to start RStudio Server.
Jan 28 20:18:20 localhost.localdomain systemd[1]: Unit rstudio-server.service entered failed state.
Jan 28 20:18:20 localhost.localdomain systemd[1]: rstudio-server.service failed.
I installed and run an old version (rstudio-server-0.99.491-1.x86_64) on the same box without any problem.
How could I fix the issues?

Although you asked this question 3 years ago, I think it's still necessary to share my solution to this problem.
I encounter this problem after I updated R.
The reason why you can not restart rstudio-server is that the PORT 8787 was been using by previous rserver. After knowing this, the solution is easy.
First, check the pid that was using PORT 8787
sudo netstat -anp | grep 8787
tcp 0 0 0.0.0.0:8787 0.0.0.0:* LISTEN pid/rserver
Second, kill this pid (use your pid)
sudo kill -9 pid
Third, restart rstudio-server or reinstall resutio server package