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
Related
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.
For some reason emacs started to display a warning at whenever my computer starts up. The warning looks like this: https://imgur.com/a/fWz1Nu1. The text-form of the error is:
Warning (initialization): An error occurred while loading '/home/username/.emacs':
error: No such directory found via CDPATH environment variable
To ensure normal operation, you should investigate and remove the cause of the error in your initialization file. Start Emacs with the '--debug-init' option to view a complete error backtrace.
It seems, from the error, emacs is having trouble finding the ~/.emacs config file.
This warning is incorrect, however, since after this emacs normally works fine for me without any error, after this error message at start-up. It is however a mild inconvenience.
If I had to guess why it's happening I would say it might be somehow related to the way my fstab has been set up. It's slightly different from the norm but nothing too unusual. The setup is like this (in human language):
/ is mounted on a normal partition.
/home is mounted on a LUK encrypted partition. (One thing to note is that I have always had my /home encrypted but emacs only started to play up recently)
I also have two external drives that are auto-mounted to run my media server via my workstation (although I don't think this is related to the issue at hand)
Is there anyway that I can prevent emacs from displaying this in the future? I don't have emacs in my System 'Autostart' so I'm not sure why it keeps popping up at every boot.
UPDATE
I decided to look into the log from my last reboot:
$ journalctl -b | grep emacs
..and saw this:
Jul 21 14:30:46 my-PC-name systemd[3000]: Started apps-emacs-6284d6112ffa4ee29646bcb4b3b00b0f.scope.
Jul 21 14:30:54 my-PC-name systemd[3000]: apps-emacs-6284d6112ffa4ee29646bcb4b3b00b0f.scope: Succeeded.
Why would emacs starts itself when it's disabled as per below?
systemctl --user status emacs
● emacs.service - Emacs text editor
Loaded: loaded (/usr/lib/systemd/user/emacs.service; disabled; vendor preset>
Active: inactive (dead)
Docs: info:emacs
man:emacs(1)
https://gnu.org/software/emacs/
My emacs.service file doesn't look different from the default:
$ cat /usr/lib/systemd/user/emacs.service
[Unit]
Description=Emacs text editor
Documentation=info:emacs man:emacs(1) https://gnu.org/software/emacs/
[Service]
Type=simple
ExecStart=/usr/bin/emacs --fg-daemon
ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
Environment=SSH_AUTH_SOCK=%t/keyring/ssh
Restart=on-failure
[Install]
WantedBy=default.target
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
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.
I am attempting to install REDHAWK v1.8.2 on a fresh install of CentOS 6.4 32 bit, but I am unable to get omniNames and omniEvents to start.
sudo /sbin/service omniEvents stop
Stopping CORBA event service: omniEvents
sudo /sbin/service omniNames stop
Stopping omniNames [ OK ]
sudo /sbin/service omniNames start
Starting omniNames [ OK ]
sudo /sbin/service omniEvents start
Starting CORBA event service on port 11169: omniEvents: [25848]: Warning - failed to resolve initial reference 'NameService'. Exception: TRANSIENT
omniEvents.
I tried to verify if omniNames was really running by calling the naming client, but got an error (see below), so it seems omniNames is not successfully starting.
nameclt list
Caught a TRANSIENT exception when trying to validate the type of the
NamingContext. Is the naming service running?
As part of the debugging process, I tried to kill the omniNames process and start it a different way (see below).
sudo killall omniNames
omniNames -start
Wed Nov 13 21:08:08 2013:
Starting omniNames for the first time.
Error: cannot create initial log file '/var/omninames/omninames-orion.log':
No such file or directory
You can set the environment variable OMNINAMES_LOGDIR to specify the
directory where the log files are kept.
I'm not sure why omniNames can't create the log file, because I verified that /var/omninames folder actually exists and even starting omniNames as root yields the same error. Regardless, I set the log directory to my desktop to circumvent the error (see below).
export OMNINAMES_LOGDIR=/home/$USER/Desktop/logs
mkdir -p /home/$USER/Desktop/logs
omniNames -start
Wed Nov 13 21:09:17 2013:
Starting omniNames for the first time.
Wrote initial log file.
Read log file successfully.
Root context is IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000001000000000000005c000000010102000a00000031302e322e382e333500f90a0b0000004e616d6553657276696365000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100
Checkpointing Phase 1: Prepare.
Checkpointing Phase 2: Commit.
Checkpointing completed.
Even though it looks like omniNames successfully started, when I open another terminal window and call the naming client, I get the same error as before (see below).
nameclt list
Caught a TRANSIENT exception when trying to validate the type of the
NamingContext. Is the naming service running?
The only modification I made in the /etc/omniORB.cfg file is to add the lines for InitRef (see below).
InitRef = NameService=corbaname::localhost
InitRef = EventService=corbaloc::localhost:1169/omniEvents
Also, I am not connected to the internet so my version of CentOS has not been updated from the base version, except for the boost libraries as recommended in Appendix J of the manual (http://sourceforge.net/projects/redhawksdr/files/redhawk-doc/1.9.0/REDHAWK_Manual_v1.9.0.pdf/download).
Looks like the issue is in your configuration. You've got the wrong port in your configuration file. It should be port 11169 however you've listed port 1169.
See: http://redhawksdr.github.io/Documentation/mainch2.html#x4-120002.6 for details.
A few other observations and tricks regarding omniOrb in case this was not the issue.
Sometimes omninames/omnievents can get into a bad state. The fix is to delete the log files created by omniNames and omniEvents and restart the services. They are located:
/var/lib/omniEvents/*
/var/omniNames/*
You'll need to be root to delete those files. I always forget where they are located and often do a "locate omni | grep -i log" to remind myself but you must do this as root since they are not visible to standard users.
While it should not matter, I've personally found that using 127.0.0.1 is more reliable than localhost. For some reason, using localhost within a VM in the configuration file has caused me problems in the past. Consider using 127.0.0.1 instead of localhost. This is what the current version of the Redhawk Manual recommends as well.
You mentioned you are using Redhawk v1.8.2. As an FYI, the latest REDHAWK version in the 1.8 series is currently v1.8.5 and 1.9.0 was also recently released.
Hopefully this gets you up and running!