Error autostarting Linux service after reboot if condition is met: "Path in condition not absolute, ignoring" - linux

I have a service named MyService that needs to auto-start a NodeJS process only if "Configured!" can be found inside of a configuration file. The MyService.service file contains the following in the Service section:
ExecStart=/usr/bin/sh -c "if grep -q 'Configured!' /path/to/configuration/file.conf; then /usr/bin/node /path/to/node/process.js; fi"
However, the problem is that the NodeJS process does not auto-start. In fact, when I look in journalctl, I see the following error message:
Path in condition not absolute, ignoring: "/path/to/configuration/file.conf"
How can I please change ExecStart to successfully auto-start the NodeJS process when the condition has been met? This is very puzzling because when I run the ExecStart command on the command line, it works correctly. Also, the path to the configuration file is an absolute path.
(Also, please note that since this machine is running an old version of systemd, I am not able to use ExecCondition.)

The issue is with double quotes in :
"/path/to/configuration/file.conf"
which makes systemd think it's not a absolute path.

Related

How to add user input when starting a service in systemd

I have a service configured in systemd that runs a binary file and it runs constantly. The problem is that after running this binary file, you have to confirm Terms&Conditions by typing y in the terminal and validating it by click Enter. I cannot run this file through this, because the systemctl status appears to me as failed, because of lack of validation. Does anyone know how I can run this service and automatically accept Terms in terminal?
I figured it out in such a way:
I created .sh file in usr/bin with this content:
#!/usr/bin/bash
yes | /home/marek/webcash/webminer
Then I created config file in systemd with ExecStart: /path/to/file.sh
and now it works - systemd is running correctly, the logs are logging, the answer "yes" was typed only once in binary file when the user prompt appeared.

systemctl enable fails with cryptic error message [duplicate]

I've created a systemd service file (specifically for svnserve; I'm actually using the example from here https://stackoverflow.com/a/40584047/464087), and when I enable it, typing
sudo systemctl enable svnserve
I get the response
Failed to execute operation: Invalid argument
Running
sudo systemctl status svnserve
yields
● svnserve.service - Subversion protocol daemon
Loaded: loaded (/etc/systemd/system/svnserve.service; enabled; vendor preset: enabled)
Active: inactive (dead)
not giving me any clue about anything being wrong. I can then start the service without any error, and it seems to be running as expected, and after starting systemctl status I still get no clue about anything being wrong:
● svnserve.service - Subversion protocol daemon
Loaded: loaded (/etc/systemd/system/svnserve.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2018-01-09 22:10:14 UTC; 6s ago
Process: 9677 ExecStart=/usr/bin/svnserve $DAEMON_ARGS (code=exited, status=0/SUCCESS)
Main PID: 9678 (svnserve)
Tasks: 1
Memory: 964.0K
CPU: 2ms
CGroup: /system.slice/svnserve.service
└─9678 /usr/bin/svnserve --daemon --pid-file /run/svnserve/svnserve.pid --root /srv/svn/repos --log-file /var/log/svnserve/svnserve.log
So what does this error message mean? And to which level of things is "invalid argument" supposed to apply? An argument to the svnserve command? Some property in the service file? A command line argument to the servicectl command itself?
FWIW this is on a Ubuntu 16.04 LTS server.
If you copy/paste the file from a system with one encoding (e.g. Windows) to another (e.g. linux), there may be issues with the file encoding, or characters being interpreted differently. You can convert the file and re-analyze to see if it is being interpreted correctly.
Run the analyzer
$ sudo systemd-analyze verify yourname.service
/etc/systemd/system/yourname.service:1: Assignment outside of section. Ignoring.
Fix the encoding of the service file, e.g. using vim (answer from here)
$ vim +"set nobomb | set fenc=utf8 | x" yourname.service
Edit the file and remove any strange characters that are now exposed at e.g. the start of the file. e.g. it might have characters like ^[[200~
Save the file and re-enable the service
$ sudo systemctl enable yourname.service
I had a similar case, in my case problem went away after removing the Alias line from the [Install] section. Thanks to Anton in another thread: https://stackoverflow.com/a/34978908/2711456 - alias' name may not be the same as service name.
What I also found is the bug with comments (at least at systemd 219), if you have comment after any code of service file, it will failed to enable it.
So bring comment to new string, or remove it.
I tested and it works for me:
WantedBy=multi-user.target
# runs in init 3 (multi-user mode for linux)
this one will not work:
WantedBy=multi-user.target # runs in init 3 (multi-user mode for linux)
some discussion is here: https://github.com/rabbitmq/rabbitmq-server/issues/1422
I experienced the exactly same thing. Deleting "Alias" works, but actually, alias can have the same name with the service file.
The reason it doesn't work is related to the directory where service file is put.
What systemd enable does is creating an alias in the directory "/etc/systemd/system" and in the target directory which wants this service. If the original service file is already located in "/etc/systemd/system", when systemd tries to enable this service, the alias can't be created.
The solution is putting the service file in directory "/lib/systemd/system/", and it will work.
So, I guess we already have a similar answer. I just want to indicate the reason.
Answer:
cd /etc/systemd/system/multi-user.target.wants/ # it can be other WantedBy item
ls -lA # notice that <your>.service is not a link
rm <your>.service # remove it
And now try:
sudo systemctl enable <your>.service
It should create right link and enable your service.
you try this, i was resolved it:
cd /etc/systemd/system/multi-user.target.wants
ls
find name service error "Failed to execute operation: Invalid argument"
rm -rf yourname.service
cd /etc/systemd/system/
nano yourname.service
edit your content service (maybe your content mistake (checking symboy [, ],...bla..bla)
==> save it
systemctl daemon-reload
systemctl enable yourname.service
good luck!!!
After last line of your /etc/systemd/system/youunit.service file, CR symbol is required.
Check it and remove /etc/systemd/system/multi-user.target.wants/youunit.service.
Then try systemctl enable youunit again.
I my case the problem was that the service was a symlink to another file. systemd-analyze did not find any issue but systemctl enable failed. When I removed the symlink and copied the file, it started to work.
In my case, my /etc/systemd/system/my-service.service was a symlink :S

No lock file found in /usr/local/nagios/var/nagios.lock

I followed the instructions at this link which I found here on EE...http://nagios.sourceforge.net/docs/3_0/quickstart-fedora.html
Well after trying to stop nagios with command service nagios stop and after that to see its status with service nagios status the following message appears: "No lock file found in /usr/local/nagios/var/nagios.lock". How do I resolve it.
Thanks.
This is not a bug. "No lock file found in /usr/local/nagios/var/nagios.lock" means that it isn't running.
If you run an echo $? directly after service nagios status while it isn't running, you'll notice that the exit code is 3.
3 is the correct value return code for that status as documented in the Linux Standard Base.
Some Sources:
https://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html
http://ftp.novell.hu/pub/mirrors/ftp.novell.com/forge/library/SUSE%20Package%20Conventions/spc_init_scripts.html
Just run:
/usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
UPDATE:
The error: "No lock file found in /usr/local/nagios/var/nagios.lock" simply means that nagios is not running.
Running the command above simply starts the nagios daemon and points it to a specific config file. The advantage to running this command manually over systemd is that when you run "service nagios start" this typically calls the /etc/rc.d/init.d/nagios script which contains a line with parametrized environment variables:
$NagiosBin -d $NagiosCfgFile
Because every system is different, not specifying either the bin nor config directories could lead to nagios breaking (stopping) when it tries to start using the default installation directory paths

Write error when trying to run unicorn: directory for pid=/var/www/twimpush/pids/unicorn.pid not writable (ArgumentError)

I've followed the steps in the DigitalOcean guides here and here towards setting up a Sinatra server using nginx and Unicorn. I'm on the second to last step:
start the Unicorn and run it as a daemon using the configuration file:
Make sure that you are inside the application directory
i.e. /my_app
unicorn -c unicorn.rb -D
Running that command, I get the error:
directory for pid=/var/www/twimpush/pids/unicorn.pid not writable
(ArgumentError)
I've tried this as both root, and as a user called deployer, to which I gave write permissions.
When I cloned my git repo, it didn't include the empty pids folder inside my repo. I added it with mkdir pids, in addition to the other required folders mentioned in the first guide, and it worked.

How to run php-fpm as root

I know the risks about running php-fpm as root.
However there are situations where one would need to do it, like appliances,
accessing operating system resources or even for testing purposes.
I have tried to change the user and group of php-fpm.d/www.conf to root
when I restart the php-fpm process it raise an error:
Starting php-fpm: [26-Jun-2014 00:39:07] ERROR: [pool www] please specify user and group other than root
[26-Jun-2014 00:39:07] ERROR: FPM initialization failed
[FAILED]
What should I do. Anyone help?
See:
# php-fpm --help
...
-R, --allow-to-run-as-root
Allow pool to run as root (disabled by default)
Just adding -R (like this ans. suggests) to your command may not work. It depends how your running the command to start php-fpm.
If you're using service php-fpm restart and it's using /etc/init.d instead of systemctl (see here), then you'll have to add -R to the DAEMON_ARGS variable located in the /etc/php/<phpversion>/fpm/php-fpm.conf script. (This variable is used in the do_start() function. See here).
If it's using systemctl then you'll have to edit the script used by systemctl which should be located in /lib/systemd/system/<phpversion>-fpm.service. Append -R to the ExcecStart variable. Then run systemctl daemon-reload and systemctl start php<version>-fpm (See here)
I used the following questions/answers/resources to help me compile this solution.
https://serverfault.com/a/189961
https://serverfault.com/q/788669
https://stackoverflow.com/a/52919706/9530790
https://serverfault.com/a/867334
https://www.geeksforgeeks.org/what-is-init-d-in-linux-service-management/
These 3 steps will fix the error.
Locate php-fpm.service. For me it's /usr/lib/systemd/system/php-fpm.service. If you're not sure where it is, type find / -name php-fpm.service.
Append -R to the ExecStart variable. Eg ExecStart=/usr/sbin/php-fpm --nodaemonize -R.
Restart php-fpm. If systemctl restart php-fpm throws an error, run systemctl daemon-reload.
To anyone else wondering how to make php run as root, you also need to modify /etc/php-fpm.d/www.conf or modify a copy of it. Both user and group need to be changed to root. If you've made a copy of www.conf, you'll also need to modify this line listen = /run/php-fpm/www.sock.
By default, php-fpm is shipped with a "www.conf" that contains, among others, the default www-data user configuration:
[www]
user = www-data
group = www-data
So, you need to create another file, loaded after www.conf, that will overwrite that default config. For example, create a file docker.conf in the same path as your php-fpm's Dockerfile and containing the following:
[www]
user = root
group = root
Then, in your Dockerfile, inject that file in your container with a name that will be loaded after the default www.conf:
COPY ./docker.conf /usr/local/etc/php-fpm.d/zzz-docker.conf
Update 2018
Running it within a container is a possible valid reason to run php-fpm as root. It can be done by passing the -R command line argument to it
Original answer:
However there are situations where one would need to do it, like appliances, accessing operating system resources
You never need to do it. That's it. If you are managing system resources, grant permissions for the php-fpm user to that resources rather than running the whole process as root. If your question would be more specific I could show how to do that in a certain situation.

Resources