|
same just happened in a proxy as well.
|
|
full proxy log of two crashing sessions (and a bit of the next session startup)
server log has been rotated over already.
|
|
potentially useful information - system was running zabbix server, two active proxies and one passive proxy
|
|
Changed priority to critical - could not repeat or find the cause. If this is caused by Zabbix then it does not seem like a new problem.
|
|
Closing as "Cannot Reproduce" - seems that the semaphores are arbitrary removed, no reason was found nor was it reproduced on any other system. Please reopen when additional case to study with LogLevel=4 is acquired.
|
|
something quite similar happened again. 1.8 branch, rev 27659
|
|
Semaphore Limit. On some Linux systems, reaches a system limit on the number of semaphores in the Linux configuration. In this case, you will see a message similar to the following:
sem_lock->semop->op_op: Invalid argument
sem_unlock->semctl: Invalid argument
Invalid argument [22] means:
- The semaphore identifier is invalid.
- The number of semaphores specified is less than 0 or greater than the number in the semaphore set.
- The value for cmd is invalid.
- The value for cmd is IPC_SET, but the value for sem_perm.uid or sem_perm.gid is invalid.
To increase the number of semaphores, run the following command as owner or root:
This file contains 4 numbers defining limits for System V IPC semaphores. These fields are, in order:
- SEMMSL - The maximum semaphores per semaphore set.
- SEMMNS - A system-wide limit on the number of semaphores in all semaphore sets.
- SEMOPM - The maximum number of operations that may be specified in a semop(2) call.
- SEMMNI - A system-wide limit on the maximum number of semaphore identifiers.
This modification takes effect immediately, but is reset at the next reboot. To avoid resetting the limit when rebooting, add the above command to one of your system’s startup scripts by copying the command into a file called mod_sem and then setting up the following links to execute the file each time you restart your system:
Another method (prefered!):
 To use these settings, put the following in sysctl.conf (as root) or use "sysctl -w" to write these settings to sysctl.conf:
sysctl can be reloaded via the command "sysctl -p" (-p tells it to load from the standard conf file which is /etc/sysctl.conf).
"sysctl -a | grep kernel.sem" can be used to check that the new values have been loaded. This can also be used after a reboot to check that the values have been permanently saved.
|
|
Shall we close it?
<richlv> we don't know for sure what causes this - maybe zabbix passes invalid value, maybe it starts leaking semaphores, or maybe it indeed happens only when system in general is exhausted.
and even in the latter case it is possible we could detect that and as a minimum print a better message, same as when we run out of config cache etc 
<richlv> also note that the proxies where crashes happen are not heavily loaded - they monitor some 10 hosts with 3-5 items at most with 3 nvps total...
|
|
happened again. 2.0 branch, rev 31271
|
|
and happened again. 2.0 branch, rev 31853, passive proxy
|
|
this might also be related to multiple processes attempting to use the same pidfile. just had an agent crash with :
...or maybe by multiple processes attempting to listen on the same port, or some combination of these
|
|
while seemingly different, maybe ZBX-6606 is related
|
|
happened again. 2.0 branch, r37403
|
|
I had same crash with vanilla 2.2.2 on OpenSuSE. I suspect it is SuSE related issue since we had no reports from users of other distributions.
|
|
these seem to be triggered by running multiple zabbix daemons on the system in cases when these daemons are active and maybe started/stopped more frequently. that is probably less likely to happen during normal system operation.
|
|
just got this (or a very similar) issue on one of my customer's server, it's a 2.0.10 Zabbix Server on a Red Hat (not sure which release). Backend database is Oracle.
They were having some issues with Web scenarios (error: error doing curl_easy_perform: Couldn't resolve host name) for a few days and we were trying to debug them before restarting the server, when during the night, the zabbix server crashed with this messages in the server log file:
followed, a few seconds later, by:
As expected, PID 4505 is an HTTP Poller:
and PID 3279 is the DB Watchdog Process:
So it seems in this case, they run out of system resources (file descriptors, semaphores, ...)
glebs.ivanovskis [24] Too many open files does not line up with the rest of this ticket, so you may be interested in reporting it as a separate issue if it's still happening.
|
|
hmm, "Too many open files" is interesting. it might be related to the way we handle logfiles where each process opens the file individually and if the file is rotated and that process has nothing to write for it for a long time, it still holds open an fd on it. as a result, on a system with lots of processes and files being rotated relatively often we end up with lots of deleted files still being held open and on disk by those processes/fds.
now that is not the case when i observed it as those usually were small instances - but running out of semaphores one way or another could be related.
|
|
had another agent crash like that.
|
|
reproduced
|
|
As to error 43 it seems it means some external entity killed the semaphore during the work flow of Zabbix daemon:
errno.h:
#define EIDRM 43 /* Identifier removed */
|
|
I've got a Zabbix server running on RedHat 7 in AWS, which has run fine without crashing for around 6 months. I updated to the latest kernel and rebooted, and now the server won't run for more than a handful of minutes without crashing like this:
2445:20160202:152910.113 server #18 started [http poller #1]
2451:20160202:152910.115 server #24 started [escalator #1]
2449:20160202:152910.115 server #22 started [history syncer #3]
2452:20160202:152910.115 server #25 started [proxy poller #1]
2450:20160202:152910.116 server #23 started [history syncer #4]
2445:20160202:153010.901 cannot process step "Login" of web scenario "pilot-stream.xxxxxxx.com" on host "Zabbix Server": response code "503" did not match any of the required status codes "200"
2433:20160202:153129.235 Zabbix agent item "system.cpu.util[,softirq]" on host "Pilot-Stream-StreamAnalyzer-i-fb53057a" failed: first network error, wait for 15 seconds
2435:20160202:153144.373 resuming Zabbix agent checks on host "Pilot-Stream-StreamAnalyzer-i-fb53057a": connection restored
zabbix_server [2432]: [file:'dbconfig.c',line:5174] lock failed: [22] Invalid argument
zabbix_server [2427]: [file:'log.c',line:271] lock failed: [22] Invalid argument
zabbix_server [2450]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2447]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2448]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2449]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2431]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2433]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2430]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2434]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2453]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2451]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2445]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2435]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2441]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2452]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2446]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2442]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2429]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2428]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2438]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2444]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2436]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2439]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2440]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
zabbix_server [2437]: [file:'selfmon.c',line:391] lock failed: [22] Invalid argument
I've tried ensuring that the kernel semaphore configuration is adequately configured:
[ec2-user@ip-172-31-3-195 logs]$ sudo sysctl -a | grep kernel.sem
kernel.sem = 512 80000 512 64000
That's made no difference.
Help!
|
|
This seems pretty repeatable: If I'm ssh-ed into the instance where the zabbix_server is running, tailing the log, the server seems to run. Everytime, as soon as I log out of the instance, zabbix_server crashes like this.
|
|
Keeping a nohup tail zabbix_server.log > /dev/null 2>&1 & running seems to be keeping my server alive.
|
|
Michael, could you please specify how exactly you tail the log and how exactly you log out of the instance to make it crash? Does it crash immediately or after some time?
Note that your last command nohup tail zabbix_server.log > /dev/null 2>&1 & does not actually run in the background much, probably due to the missing -f or -F.
|
|
The good news is my zabbix_server managed to run through the night with the above workaround.Yes, the correct command I executed was nohup tail -f zabbix_server.log > /dev/null 2>&1 &. But I suspect that any command which keeps the ssh session open will keep my zabbix_server alive.
The server was compiled from source and is running on an AWS instance. The server had been running 2.4.5 for 6 months reliably. In an effort to try and resolve this, I upgraded the server to 2.4.7. The server version has no effect on the problem. The zabbix_server is started using systemd with a service definition like this:
[Unit]
Description=Zabbix Server
After=syslog.target network.target
[Service]
Type=forking
ExecStart=/home/ec2-user/local/zabbix/sbin/zabbix_server
ExecReload=/home/ec2-user/local/zabbix/sbin/zabbix_server -R config_cache_reload
RemainAfterExit=yes
PIDFile=/home/ec2-user/local/zabbix/logs/zabbix_server.pid
User=ec2-user
[Install]
WantedBy=multi-user.target
As soon as I kill off my background tail process, and exit my interactive ssh session with the instance, the zabbix_server process crashes.
|
|
To be even more clear... If I execute the nohup tail -f ... command, I CAN disconnect my ssh session from the instance and the zabbix_server will continue to execute. If I ssh back into the instance again, kill the tail command, and then exit my ssh session, zabbix_server will crash immediately.
glebs.ivanovskis Your issue seems more related to ZBX-11544.
|
|
Hi,
Why was this removed from 3.0.2rc1? Does it mean that you are not going to fix it in this version? Are you going to fix it anytime soon (like 1-2 months)?
Thank you for information
|
|
I've have 2 test instances of Zabbix running on CentOS 7.2, and I've also noticed that both the Zabbix 2.4.7 and Zabbix 3.0.1 crashes with the same error:
zabbix_agentd also creashes:
After this, the only processes left running are:
zabbix_agentd: listener #1 [waiting for connection]
zabbix_server: trapper #1 [processed data in 0.000355 sec, waiting for connection]
Since this was test, I've not taken much notice to when it started happening. It could possibly be it started happening after upgrade to CentOS 7.2 on December 17.
In my case, it takes a while before it crashes. Not immediately after disconnect, but I start Zabbix using scripts (although without nohup, using "daemon $exec -c $conf").
It crashes every night at about 02:00 - 02:16 (CET). I'll enable debug and upload that if it would be of any help.
|
|
I've now been able to reproduce this on my system - it may not be the same behavior as for others.
This is triggered by a cronjob that connects to the database every day to update partitioning.
I've done some tests, and found that it is not the actual partitioning that provokes this. This simple shell-script triggered by cron crashes Zabbix:
#!/bin/sh
MYSQL="/usr/bin/mysql"
CONF="--defaults-file=$HOME/.my.zabbix.cnf"
SQL="select now();"
/bin/echo $SQL | $MYSQL $CONF
Cron:
If I run the script manually, from command line, there are no issues.
I run the same on RHEL 6, and have no issues there. Also no issues with pre CentOS 7.2.
|
|
Also triggerting this run using "at now" gives the same result.
Strace of main Zabbix process (/opt/zabbix/sbin/zabbix_server -c /opt/zabbix/etc/zabbix_server.conf):
And example of strace of "history syncer #1":
|
|
I got the same error running any command through cron (even "at now" running date).
Looks like the error I am getting could be a Kernel bug. Similar to this: http://www.postgresql.org/message-id/[email protected]
(also on CentOS 7)
According to this error reported with Postgres and cron, the Semaphore was removed.
Ie:
I see server have not been restarted after installing latest kernel, so I will attempt that later today.
Current kernel: 3.10.0-229.1.2.el7.x86_64
Latest installed: 3.10.0-327.10.1.el7.x86_64
|
|
Updating to latest kernel (3.10.0-327.10.1.el7.x86_64) + reboot solved it for me
The error reported originally may be something else than what affected me.
|
|
I have the same problem.
FreeBSD 10.1 RELEASE p35
MySQL56
Apache24
Zabbix 3.0.2
When server started in semaphores list i see one smaphore
But after a few second zabbix server crash with error in log file:
Zabbix Server stopped. Zabbix 3.0.2 (revision 59540).
zabbix_server [20053]: file:'selfmon.c',line:375 lock failed: [22] Invalid argument
How to fix it?
Upd1
Trying to upgrade 10.1 to 10.3 RELEASE. Maby it helps.
|
|
Had seen the similar case when I was using more than one Zabbix server instances on the box.
|
|
I have a fresh install of version 3.2.1 compiled 64bit on Solaris 10. I found the same errors in the log files of both the server and the agent on the same server.
When I start the server, everything is fine, but as soon as I start the agent, the sever log presents the log messages:
I restart the server and as soon as the process is running, the agent does the same thing:
I am running Server/Agent v 3.2.1, MySQL Ver 14.14 Distrib 5.7.16, on Solaris 5.10 Generic_150400-15, T4-2, Zabbix and MySQL compiled with gcc 5.2.0 (from OpenCSW).
On the same server there is another zabbix agent running (on different port and user) version 2.x (i do not know exactly) and i just imported two server definitions from an Zabbix 2.2.5. The agents for the imported servers run on two different Solaris 5.10 Generic_150400-15, T4-2 with version: Zabbix Agent (daemon) v2.2.1 (revision 40808) (09 December 2013) Compilation time: Dec 24 2013 20:08:37
For the imported servers I also have enabled SNMP monitoring (that do not work for now, firewall issues)
|
|
Sorry, my mistake. The error was from the shutdown script that removed semaphores and shared memory after server stopped. If the server does not stop in 10 sec, one kill -term / sec, then a kill -kill follows and semaphores and shared memory remained orphaned and cleaned with ipcrm.
I removed the semaphores cleanup and the error does not appear in the logs anymore. I have another problem with the zabbix server hanging in check_operation_conditions (the sql finishes instantly in MySQL Workbench). I will address this in another thread.
|
|
I have this error after upgrade zabbix-server from version 3.2.1 to 3.2.2 from rpm package on CentOS 7
|
|
Previous comment looks like duplicate of ZBX-11573
|
|
So, anyone who is experiencing this problem, how do you launch Zabbix? I mean from which directory you run a launch command, where is configuration file situated, how many daemons run at the same time, do you launch them with independent configuration files or do you edit one file between launch commands, maybe you generate configuration file on the fly and remove it once daemon has started. More details is better!
|
|
We are facing this problem in our environment.
We install zabbix server, agent and proxy, using the sources.
Every default installation, in the / usr / * directory
Here we use Red Hat Enterprise Rhel 7, 3.10.0-327.4.4.el7.x86_64.
Configuration files all with initial values, no changes.
Contents of the startup script in systemctl
errors in zabbix_server, in zabbix_proxy and zabbix_agent
- zabbix_server.log
- zabbix_proxy.log
- zabbix_agent.log
glebs.ivanovskis Errm... Running zabbix_server with -R but without -c if you started it with -c is not a good idea. Run time control relies on pid of main process stored in pid file and path to pid file is taken from PidFile parameter in configuration file. Without -c Zabbix will search for default configuration file in default path...
|
|
Hummm, thanks for the tip...
but, this conf or parameter can create these errors?
|
|
Maybe. I'm trying to figure it out right now. Configuration file path is involved in generation of the key for semaphore array (this is the first column of ipcs -s output). If the path does not exist or we don't have enough permissions to use it, we generate key from '.' as a backup plan. In this case there should be this error in the log:
Generating keys from '.' isn't really good because we will end up with key conflict and all Zabbix daemons will compete for the same semaphores.
|
|
hummm, but, this parameter, is only in Reload state:
ExecReload = / usr / local / sbin / zabbix_server -R config_cache_reload
Even then, may be generating these errors? Even without reloading services? The Parameter that I should use then, can be:
ExecReload = / usr / local / sbin / zabbix_server -R config_cache_reload -c /usr/local/etc/zabbix_server.conf
Because, the path /usr/local/etc/zabbix_server.conf, is the default path!!! It does not make sense, repeat the path to the configuration file.
|
|
Feedback: I removed parameter -c and the command line reload in the systemctl script, so far, no errors appeared.
The script looks like this:
I can not say that it has completely resolved, but I will monitor if it happens again.
|
|
I think it is a bit bad luck on top of misuse of ftok() from our side that causes the crash.
If you compare the first column (semaphore key) of output of this command:
with the output of
you will see that the only difference is 0x7a in the beginning. This is ASCII code of 'z' and is common for all Zabbix daemons.
If you have multiple Zabbix daemons on one system with configuration files on the same drive and if configuration file inode numbers share 16 lower bits - you are in trouble - your Zabbix daemons will compete for the same semaphore set.
Problem has nothing to do with system-wide limits on semaphore set number and semaphore number in semaphore set mentioned above.
|
|
as far as i recall, most of these were observed during the zabbix training sessions when trainees were starting up 3 zabbix proxies on the same machine - and yes, running them with the wrong -c parameter was very likely to happen at some time.
|
|
Wrong config file usually result in a more obvious error. Bind failure due to port conflict, pid file conflict or something like that. Key conflict may happen even if daemons have separate config files. If you are interested, probability of this happening is given by this formula (assuming random inode numbers):
where N is a number of Zabbix daemons. With N = 2 it is negligible 1/65536 but with N = 10 it comes close to a quite noticeable 0.1%. Plus you need to multiply it by number of students 
|
|
The problem came back again... 
glebs.ivanovskis Can you please check config file inode numbers (for all Zabbix daemons you have on the system) as I described above to prove or disprove my hypothesis?
|
|
ah, thanks a lot for the formula
if that's all the daemons running under the same user (not just daemons of the same type), then it's 5 daemons (3 proxies + agent + server). multiplied by the number of students, by the number of sessions, it indeed does make it quite likely to happen every now and then.
i now recall some users in their prod environments seeing this issue, and they were running 2 or 3 agents on some boxes. i guess restarting agents every now and then makes sure it will happen at some point.
|
|
@Glebs Ivanovskis Can you please check config file inode numbers (for all Zabbix daemons you have on the system) as I described above to prove or disprove my hypothesis?
Sorry for the delay, i have been sick last week, this is the result:
I think you right
have any way to fix this?
glebs.ivanovskis Please show printf ... for zabbix_agentd.conf and zabbix_proxy.conf. So far we can't decide.
|
|
glebs.ivanovskis Thank you, for all your patience and help
here, we have been working in 2 servers
First Server: We have - zabbix_server and zabbix_agent
Second Server, we have only zabbix_proxy
First server:
zabbix_server.conf
zabbix_agentd.conf
Second Server:
|
|
Looks good, no conflicting inode numbers. Don't worry that printf ... matches ipcs ... output, that's how Zabbix works currently. I guess everything is working fine for you now, isn't it?
|
|
No,
in both Servers, in log files, i have this errors:
4039:20170210:101250.615 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4053:20170210:101250.615 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4054:20170210:101250.616 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4055:20170210:101250.617 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4056:20170210:101250.618 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4058:20170210:101250.619 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4057:20170210:101250.619 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4059:20170210:101250.620 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4060:20170210:101250.621 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4062:20170210:101250.621 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4061:20170210:101250.622 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4064:20170210:101250.622 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4063:20170210:101250.623 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4066:20170210:101250.623 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4065:20170210:101250.624 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4068:20170210:101250.624 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4067:20170210:101250.625 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4069:20170210:101250.625 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4070:20170210:101250.626 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4071:20170210:101250.626 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4074:20170210:101250.626 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4072:20170210:101250.627 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4075:20170210:101250.627 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4073:20170210:101250.628 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4076:20170210:101250.628 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4077:20170210:101250.629 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4080:20170210:101250.629 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4078:20170210:101250.630 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4082:20170210:101250.630 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4079:20170210:101250.631 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4083:20170210:101250.631 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4081:20170210:101250.632 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4084:20170210:101250.632 Got signal [signal:15(SIGTERM),sender_pid:1,sender_uid:0,reason:0]. Exiting ...
4039:20170210:101252.623 syncing history data...
4039:20170210:101252.623 syncing history data done
4039:20170210:101252.623 syncing trend data...
4039:20170210:101252.637 syncing trend data done
4039:20170210:101252.637 Zabbix Server stopped. Zabbix 3.2.3 (revision 64610).
glebs.ivanovskis This looks like normal Zabbix termination. No lock failed ... errors?
Théo: Sorry, i Posted wrong log.
|
|
I deleted the whole environment.
I installed everything from scratch, following the official tutorial: https://www.zabbix.com/documentation/3.2/manual/installation/install
I have not changed any server configuration, Red Hat Rhel 7, and even then, the error persists.
I do not know what to do anymore.
Could it be some error related to Rhel 7?
Well I remember installing in another environment, Rhel 6 version 3.2.0 of Zabbix and did not give any such error.
|
|
Dear theocastelo, have you checked config file inodes after re-installation?
Since you mentioned RHEL 6/7, your issue may be more related to ZBX-11544 (see this comment), all depends on how you start Zabbix and when these errors appear in the log.
|
|
glebs.ivanovskis I think this is it.
after changing the REMOVE_IPC parameter, now working fine...
Probably the problem was caused by the application user be the same used for ssh access, when we log off, the error happened.
Thank you so much
|
|
Situation must be much better in 3.4 after implementation of ZBXNEXT-3687. I'll dare to close this issue as Duplicate.
|
Generated at Thu Apr 24 07:12:35 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.
zabbix_proxy_p.log