Error Running Neo4j with Systemd on Arch Linux - neo4j

I've got neo4j installed on my arch linux setup, and am able to start the server manually (sudo neo4j start). However, when I try to start it using systemctl start neo4j, I get
Job for neo4j.service failed. See 'systemctl status neo4j.service' and
'journalctl -xn' for details.
Neither of the suggestions in the error message give anything helpful. I have /usr/lib/systemd/system/neo4j.service:
[Unit]
Description=Neo4j
[Service]
User=root
Type=forking
ExecStart=/usr/bin/neo4j start
ExecStop=/usr/bin/neo4j stop
PIDFile=/run/neo4j/neo4j-service.pid
#LimitNOFILE=40000
[Install]
WantedBy=multi-user.target
I've tried changing the User between neo4j and root, and I originally had LimitNOFILE not commented out, before I tried setting the limits in security/limits.conf (which got rid of the file number error when starting it normally). This setup is mentioned in the AUR, but I just can't get it working. Any help is appreciated!

I have just attempted to set up Neo4j on a fresh Arch VM and this has worked successfully. The steps I followed were:
Boot
Install wget and jdk7-openjdk by running pacman -S wget jdk7-openjdk
Download Neo4j package from the AUR using wget https://aur.archlinux.org/packages/ne/neo4j/neo4j.tar.gz
Unzip package with tar xvf neo4j.tar.gz
Change dir cd neo4j
Build package using makepkg (this downloads Neo4j from dist.neo4j.org)
Install with pacman -U neo4j-2.1.5-1-any.pkg.tar.gz
As per the messages received during installation, create configuration to point at the installed JDK:
mkdir /etc/systemd/system/neo4j.service.d
echo "[Service]" >> /etc/systemd/system/neo4j.service.d/java_home.conf
echo "Environment=JAVA_HOME=/usr/lib/jvm/default" >> /etc/systemd/system/neo4j.service.d/java_home.conf
Start the server with systemctl start neo4j.service
Check the server is running with curl http://localhost:7474/db/data/
If this works, a JSON response will be shown.
As I can't tell exactly the steps you went through to install or what your file system may look like, your best bet will probably be to compare the steps you went through with these above and see where the differences are.
At a guess, I'd recommend looking at your Java installation first to see if the service is having trouble finding the Java runtime. This is certainly the most fiddly part of the whole process.
Note: I used the JDK here but I don't see why the jre7-openjdk package should not work just as well.

Do you try to add this modified line for file /usr/lib/systemd/system/neo4j.service ?
[Unit]
Description=Neo4j
[Service]
User=neo4j
Type=forking
RuntimeDirectory=neo4j
RuntimeDirectoryMode=770
ExecStart=/usr/bin/neo4j start
ExecStop=/usr/bin/neo4j stop
ExecReload=/usr/bin/neo4j restart
RemainAfterExit=no
Restart=on-failure
PIDFile=/run/neo4j/neo4j-service.pid
LimitNOFILE=60000
TimeoutSec=600
[Install]
WantedBy=multi-user.target

Related

Did I overwrite my old version of Jenkins?

My Jenkins is running on CentOS 7 and I was looking to upgrade my Jenkins version 2.277.4 to 2.375.1. I tried using sudo yum update jenkins to update jenkins. I received this message: “Public key for jenkins-2.375.1-1.1.noarch.rpm is not installed”. I read an article telling me to pull the key from online, so I performed these commands:
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo --no-check-certificate
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
sudo yum update jenkins
Afterwards, I haven’t been able to correctly start Jenkins. Obviously, I should have just uploaded the new war file instead of using yum update.
Any time I try Sudo systemctl start jenkins I get this warning.
Warning: jenkins.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.
Any suggestions on fixing this issue? Any way to revert back to the old version?
Thank you ahead of time!
**Edit: I tried reloading the daemon and restarting the service. However, my Jenkins start/restart is timing out even though I’ve set the timer to 10 mins.
Additionally, I installed java-11-openjdk during the upgrade, would that cause issues?

Composer Docker image won't run at all

I'm attempting to learn how to create a Laravel Docker image by following a tutorial on DigitalOcean using WSL. Following the instructions on the Docker Hub page, however, yields an error:
❯ docker run --rm --interactive --tty -v $(pwd):/app composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 94 installs, 0 updates, 0 removals
- Installing voku/portable-ascii (1.4.10): Failed to download voku/portable-ascii from dist: Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
Now trying to download from source
- Installing voku/portable-ascii (1.4.10):
[RuntimeException]
Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...
How can I diagnose what I'm doing wrong?
It turns out that the underlying problem had nothing to do with Docker at all. In fact, Composer was trying to tell me what the problem was all along, but I dismissed it as just a symptom of a deeper issue:
[RuntimeException]
Could not delete /app/vendor/voku/portable-ascii/src/voku/helper:
This message was the crux of it all. I noticed that the directory mentioned, [...]/helper, was empty, so I tried to remove it by hand with rmdir. Instead, I got a No such file or directory error message. I attempted many other was to kill this directory, the entire project directory with rm -rf ~/laravel-app from the home folder, etc. Nothing worked.
Some digging around on the internet suggested that it could be an NTFS corruption if I was running into this issue on Windows. Since I am, indeed, attempting this on WSL (Windows Subsystem for Linux), I gave their suggested fix a try: running chkdsk /F in CMD/PowerShell. A reboot was necessary to complete this task, but after getting everything back up and trying those first few tutorial steps again, I was able to get composer to install the Laravel dependencies without a hitch.
Bottom line: If you run into this sort of issue on WSL, please try running chkdsk /F and reboot. You might just have a similar file system corruption.
We have two possibilities for this error:
1 - You did not execute the command inside the directory :
cd ~/laravel-app
2 - I'm sure there is an internal proxy that is blocking the download of packages.

Listen error: unable to monitor directories for changes

I am getting the following error while running my rails app in Ubuntu server
FATAL: Listen error: unable to monitor directories for changes. Visit
https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers
for info on how to fix this.
I have followed the above GitHub page, but I was unable to write in max_user_watches which were set in 8192 and I want to set that to 524288.
in cat /proc/sys/fs/inotify/max_user_watches the file was in only read mode.I tried to grant write permissions, but I was getting permission denied error even with root access.
Thanks in Advance!!!
1000 is way too small, try with 524288 as explained in the wiki page: https://github.com/guard/listen/blob/master/README.md#increasing-the-amount-of-inotify-watchers
Listen uses inotify by default on Linux to monitor directories for
changes. It's not uncommon to encounter a system limit on the number
of files you can monitor. For example, Ubuntu Lucid's (64bit) inotify
limit is set to 8192.
and
If you are running Debian, RedHat, or another similar Linux
distribution, run the following in a terminal:
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
If you are running ArchLinux, run the following command instead
echo fs.inotify.max_user_watches=524288 | sudo tee /etc/sysctl.d/40-max-user-watches.conf && sudo sysctl --system
Just try to execute this from your console
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Hope this will work for you .
References: click here
For others who may have this issue. I had a VM disconnect which left the previous rails server running. Running below resolved the issue without needing to up the number of watcher.
kill -9 $(lsof -i tcp:3000 -t)
In my case, I just need to turn off the terminal and then start it back again. It works when I try to run rails c command :)
Deleting Gemfile.lock and running 'bundle' in the project directory terminal worked for me.
This error occurred for me as I had a number of ruby processes currently running that I was unaware of. Just need to terminate them and all is good
I had this issue during development while running rake (even with rake -h), and the solution from https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers did not work, neither did killing the running ruby processes, killing the terminal or even restarting the computer.
To avoid this error I did a new and clean clone of my project and then rake was working (maybe git clean -fdx could have worked but I did not try it).
I was running rake version 13.0.3, rails 6.1.1, ruby 2.7.2p137.
Adding to #mayur-shah's answer,
It worked for me after closing the server and console. So, if you are running rails server/console, close that first.

Starting Erlang service at boot time (using Relx for creating release)

I have a server written in Erlang, compiled with Rebar, and I make a release with Relx. Starts nicely with
/root/rel/share3/bin/share3 start
The next step is to start when the server boots.
I have tried different approaches, the last one is using the /etc/init.d/skeleton where I changed the following
NAME=share3
DAEMON=/root/rel/share3/bin/share3
DAEMON_ARGS="$1"
After that, I run update-rc.d, but I have not gotten it too work. (Ubuntu 14.04)
The service runs until the machine reboots, and I need to login and start it again.
For Windows, it is really elegant, since it can create the Windows service.
Ubuntu uses upstart as init system, so you could try something like that:
description "Start my awesome service"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
exec /root/rel/share3/bin/share3
You have to place this script in /etc/init/ directory with '.conf' extension like '/etc/init/share3.coinf'. To start it invoke sudo start share3.
At last, I solved it!
I have told to relx to place the result at /home/mattias/rel. The script from relx is /home/mattias/rel/share3/bin/share3
Replace the row
SCRIPT_DIR="$(dirname "$0")"
by (you need to fix the path /home/mattias/rel)
HOME=/home/mattias
export HOME
SCRIPT_DIR="/home/mattias/rel/share3/bin"
Copy the file to /etc/init.d/share3 using
sudo cp ~/rel/share3/bin/share3 /etc/init.d/
Test that it works using
/etc/init.d/share3 start
and
/etc/init.d/share3 stop
In order to make it start at boot, install sysv-rc-conf
sudo apt-get install sysv-rc-conf
Enable boot at start using
sudo sysv-rc-conf share3 on
and disable
sudo sysv-rc-conf share3 off
Alternatives are welcome.

Nagios return status unknow

I install Nagios on CentOS to monitor some servers, and one of them is a TSM server.
I download a plugin written in bash when i execute it in command line it works.
/usr/lib64/nagios/plugins/check_tsm db -v6
db - database utilization 42%, OK
and the return code of the batch script is 0 ( from the command echo $? )
So the script work fine, and return 0 that mean a OK status in nagios, but the status still unknown, I really don't know why.
And i check logs in nagios, etc. It's not a problem of commands definition in commands.cfg or the declaration of service, because I copy the command that nagios send automatically every 5 min and the command works fine in command line, but still unknow status.
Definition of command:
define command{
command_name check_tsm_v6
command_line /usr/lib64/nagios/plugins/check_tsm $ARG1$ -v6 $ARG2$ $ARG3$
}
Service declaration :
define service{
use generic-service
host_name tsm-test
service_description database utilization
check_command check_tsm_v6!db!85!90
}
And here's the bash script.
One thing that's caught me out in the past with Nagios scripts is user rights. When testing your script directly on the command line be sure to precede it with:
sudo -u nagios
So yours would be:
sudo -u nagios /usr/lib64/nagios/plugins/check_tsm db -v6
This assumes that your nagios instance is being run by the nagios user, which is a fairly safe bet.
Good luck
Brad
Try to use yum install sysstat -y command to download the package.
If it work that will a great. If you are facing still same please upload the complete error which is showing in browser?

Resources