I just installed Zabbix 5.0 LTS (The Latest verion of Zabbix) on RHEL-8 OS. On logging in the Zabbix front end, I gett a message saying "Zabbix server is not working". & bar below says:"Zabbix server not working.Information delayed may not be current".Kindly provide help?
Edit:My server port is 10051.
On entering "service zabbix start", I get output:
Redirecting to /bin/systemctl start zabbix.service
Failed to start zabbix.service:Unit zabbix.service not found.
& on entering "systemctl restart zabbix-server zabbix-agent httpd php-fpm", I get:
Job for zabbix-server.service failed because the control process exited with error code.
See "systemctl status zabbix-server.service" and "journalctl -xe" for details.
Output of "journalctl -xe":
RHEL8 platform-python[5746]: SELinux is preventing zabbix_server from using the dac_override capability.
*** Plugin dac_overrride (91.4 confidence) suggests ************************
If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system
Then turn on full auditing to get path information about the offending file and generate the error again.
Do
Turn on full auditing
#auditctl -w /etc/shadow -p w
Try to recreate AVC.Then execute
#ausearch -m avc -ts recent
If you see PATH record check ownership/permissions on file, and fix it,
otherwise report as a bugzilla
*** Plugin catchall (9.59 confidence) suggests *************************
If you believe that zabbix_server should have the dac_override capability by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
#ausearch -c 'zabbix_server' --raw | audit2allow -M my-zabbixserver
#semodule -X 300 -i my-zabbixserver.pp
RHEL8 dbus-daemon[779]: [system] Activating service name='org.fedoraproject.Setroubleshootd' requested by ':1.40' (uid=0 pid=748 comm="/usr/sbin/sedispatch " label="sytem_u:system_r:auditd_t:s0") (using servicehelper)
On entering "systemctl status zabbix-server.service", I get output:
zabbix-server.service-Zabbix server: Loaded:....
Active:....
Process: 4959 ExecStart=/usr/sbin/zabbix_server -c $CONFILE (code=exited,status=1/FAILURE)
RHEL8 systemd[1]:zabbix-server.service:Control process exited,code=exited status=1
RHEL8 systemd[1]:zabbix-server.service:Failed with result 'exit-code'.
RHEL8 systemd[1]:Failed to start Zabbix Server. What do I do now?
Solved. I had to configure SELinux. Just go to "vim /etc/selinux/config" & change SELinux from "enforcing" to "permissive".After that,reboot the system & then Zabbix server will start working.
You have seen that in this file /var/log/messages content about Zabbix. In this file you see a text like a bellow:
run sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020
Do this command:
#sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020
Then you see a verbose about this problem, to solve this you need to allow Zabbix in the environment. The command audit2allow does this.
link below:
Related
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
nrpe on azure server - nrpe-srvr, user nrpe, executing script /usr/local/naemon/libexec/check_curl_http.php I'll call it script
Desired output after ./script -U www.google.com:
Page OK: HTTP Status Code 200 - 11099 bytest in 0.** seconds | time=0.059 size=11099
I achieve the above output by running the script from root or nrpe
Running sudo -u nrpe ./script -U www.google.com returns:
Error in opening page! Err:Failed to connect to [ipv6 addr] Network is
unreachable
However running su - nrpe -c './script -U www.google.com' works with the desired result.
Naemon reports:
CHECK_NRPE: Socket timeout after 30 secs
Other NRPE checks to the same host are working, so I think it's something to do with user execution of this specific script. I did have a deny from SELinux, but adjusted the context. Removing the context and setting SELinux to permissive yielded the same error. Enabled NRPE Log files, with debugging, but other than Running command it doesn't really reveal much. There is a:
WARNING: my_system() seteuid(0): Operation not permitted
in the logs, but looking at the support documentation that is "Normal" behavior.
I'll post this just in case someone else has this issue, and I'll tag Azure / AWS.
Essentially, cloud providers (mostly) have an internal proxy that is stored in an environment variable http_proxy && https_proxy. NRPE by default doesn't use load environment variables. Now I don't know if there is an option for it (it's mentioned in the docs that there is a bug when using uid instead of username (was using username)) however it's simple enough to call proxy for checks like this.
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 am working with a developer on a VPS and we are getting this Linux error, but he is more familiar with PHP, so we are having some issues clarifying this error.
Can someone please shed some more light?
sudo ssh -i /root/ssh/digitalocean -o StrictHostKeyChecking=no root#162.243.87.18 'service squid restart' 2>&1
Redirecting to /bin/systemctl restart squid.service
Failed to issue method call: Unit squid.service failed to load: No such file or directory.
Most likely, the service is names "squid3" and not "squid", so
service squid restart
should be replaced with
service squid3 restart
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!