| Summary: | On upgrade from 14, zabbix server and zabbix agent fail to start due to missing dependencies | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | William H. Haller <bill> |
| Component: | zabbix | Assignee: | Dan Horák <dan> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | dan, jeff, jeremie.grauer, nelsonab |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-08-07 15:52:16 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
William H. Haller
2011-06-01 16:48:46 UTC
1.8.5 appears to work fine when compiled from the source from zabbix.com's sourceforge page as both server and agent. zabbix 1.8.5 installs and runs correctly when installed in F-15 What's the output of "rpm -qi zabbix"? The output in bug description looks suspicious. Name : zabbix Version : 1.8.5 Release : 1.fc15 Architecture: x86_64 Install Date: Tue 31 May 2011 03:34:24 PM MDT Group : Applications/Internet Size : 278119 License : GPLv2+ Signature : RSA/SHA256, Thu 21 Apr 2011 11:09:50 AM MDT, Key ID b4ebf579069c8460 Source RPM : zabbix-1.8.5-1.fc15.src.rpm Build Date : Thu 21 Apr 2011 03:03:03 AM MDT Build Host : x86-05.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://www.zabbix.com/ Summary : Open-source monitoring solution for your IT infrastructure Description : ZABBIX is software that monitors numerous parameters of a network and the health and integrity of servers. ZABBIX uses a flexible notification mechanism that allows users to configure e-mail based alerts for virtually any event. This allows a fast reaction to server problems. ZABBIX offers excellent reporting and data visualisation features based on the stored data. This makes ZABBIX ideal for capacity planning. ZABBIX supports both polling and trapping. All ZABBIX reports and statistics, as well as configuration parameters are accessed through a web-based front end. A web-based front end ensures that the status of your network and the health of your servers can be assessed from any location. Properly configured, ZABBIX can play an important role in monitoring IT infrastructure. This is equally true for small organisations with a few servers and for large companies with a multitude of servers. The upgrade was manual - downloaded the RPMs to our local repository, created the repo for FC15, imported the new RPM keys, changed the baseurl for yum to point to the new RPM tree, and did a yum upgrade after removing a small number of packages that yum was complaining about having conflicts. It's the same method I've used for a long time, but I think it does reflect the fedora/last version instead of fedora/current version in a yum list. here's the update history on the server for the zabbix package - assuming it isn't lying, it did do the update. Jan 07 09:31:44 Updated: zabbix-1.8.3-3.fc14.x86_64 Jan 07 10:16:01 Updated: zabbix-server-mysql-1.8.3-3.fc14.x86_64 Jan 07 10:16:04 Updated: zabbix-server-1.8.3-3.fc14.x86_64 Jan 07 10:18:33 Updated: zabbix-web-mysql-1.8.3-3.fc14.noarch Jan 07 10:18:39 Updated: zabbix-web-1.8.3-3.fc14.noarch Jan 07 11:38:25 Updated: zabbix-agent-1.8.3-3.fc14.x86_64 Jan 07 12:54:37 Updated: zabbix-docs-1.8.3-3.fc14.noarch Jan 17 08:07:16 Updated: zabbix-1.8.4-1.fc14.x86_64 Jan 17 08:07:19 Updated: zabbix-server-mysql-1.8.4-1.fc14.x86_64 Jan 17 08:07:24 Updated: zabbix-server-1.8.4-1.fc14.x86_64 Jan 17 08:07:36 Updated: zabbix-web-1.8.4-1.fc14.noarch Jan 17 08:07:38 Updated: zabbix-web-mysql-1.8.4-1.fc14.noarch Jan 17 08:14:25 Updated: zabbix-agent-1.8.4-1.fc14.x86_64 Jan 17 08:18:21 Updated: zabbix-docs-1.8.4-1.fc14.noarch Feb 07 08:03:23 Updated: zabbix-1.8.4-2.fc14.x86_64 Feb 07 08:03:29 Updated: zabbix-server-1.8.4-2.fc14.x86_64 Feb 07 08:03:31 Updated: zabbix-server-mysql-1.8.4-2.fc14.x86_64 Feb 07 08:03:35 Updated: zabbix-agent-1.8.4-2.fc14.x86_64 Feb 07 08:03:42 Updated: zabbix-web-1.8.4-2.fc14.noarch Feb 07 08:03:44 Updated: zabbix-web-mysql-1.8.4-2.fc14.noarch Feb 07 08:03:50 Updated: zabbix-docs-1.8.4-2.fc14.noarch May 09 08:04:06 Updated: zabbix-1.8.5-1.fc14.x86_64 May 09 08:05:07 Updated: zabbix-server-mysql-1.8.5-1.fc14.x86_64 May 09 08:05:11 Updated: zabbix-server-1.8.5-1.fc14.x86_64 May 09 08:05:28 Updated: zabbix-agent-1.8.5-1.fc14.x86_64 May 09 08:05:37 Updated: zabbix-web-mysql-1.8.5-1.fc14.noarch May 09 08:05:45 Updated: zabbix-web-1.8.5-1.fc14.noarch May 09 08:07:42 Updated: zabbix-docs-1.8.5-1.fc14.noarch May 31 15:34:26 Updated: zabbix-1.8.5-1.fc15.x86_64 May 31 17:28:53 Updated: zabbix-web-mysql-1.8.5-1.fc15.noarch May 31 17:29:00 Updated: zabbix-web-1.8.5-1.fc15.noarch May 31 17:31:16 Updated: zabbix-server-mysql-1.8.5-1.fc15.x86_64 May 31 17:31:20 Updated: zabbix-server-1.8.5-1.fc15.x86_64 May 31 18:09:24 Updated: zabbix-agent-1.8.5-1.fc15.x86_64 May 31 19:45:07 Updated: zabbix-docs-1.8.5-1.fc15.noarch : Hm, there must be something else broken on your system, what does "ldd /usr/sbin/zabbix_agentd" "return? You shouldn't be able to install or update zabbix (or any other package) and finish with missing dependencies. Also did you run "yum distribution-synchronization" after the 14->15 update process? Since I'd had to compile from source to get the monitoring going and I specified the expected fedora layout so the init scripts would work, I wasn't able to do an ldd against the original binaries - sorry. I should have thought of that earlier and saved the originals but they weren't working so I didn't see the need. After a yum reinstall zabbix*, the ldd shows the proper libraries and they start. So I guess that something in the same version number (regardless of fc advance) must have thrown some local exception here. I notice that the 14/updates creation times are the same day as the 15/core creation times - could there be some yum test that isn't doing an upgrade if the version and dates match? I don't usually do a distribution-synchronization, but in this case the library versions it was looking for were earlier than the new ones with fc15, so that wouldn't have helped anyway. Ok, there is not much we could still check (another useful check would be "rpm -V zabbix*"), so I will close this as INSUFFICIENT_DATA. Let's see if someone else will see same behaviour. And because I've received also bug #710343, does the F-15 packages work for you? Thanks, and my apologies. The F15 packages do work for us, but our particular zabbix configuration for where we had temporary files caused a requirement to add a /etc/tmpfiles.d entry to create a /var/run/zabbix directory since it's now snuffed as a tmpfs. Other than that it seems to be OK. We are only monitoring a few network channels with it but seems to be doing as well as F14 did. The service start and stop seem to be ok here now. I would say that our symptoms were similar to the other poster though... The service start originally said the services were starting OK, but when you did a ps -elf, they weren't running. It was only when I started the service from the command line that I saw the errors for missing libraries show up - so it may be a similar issue since their comments indicate an upgrade from F14 as well. (In reply to comment #9) > Thanks, and my apologies. > > The F15 packages do work for us, but our particular zabbix configuration for > where we had temporary files caused a requirement to add a /etc/tmpfiles.d > entry to create a /var/run/zabbix directory since it's now snuffed as a tmpfs. > Other than that it seems to be OK. We are only monitoring a few network > channels with it but seems to be doing as well as F14 did. The service start > and stop seem to be ok here now. the tmpfiles.d config file will be present in the next update, I forgot about bug #656726 :-( > I would say that our symptoms were similar to the other poster though... The > service start originally said the services were starting OK, but when you did a > ps -elf, they weren't running. It was only when I started the service from the > command line that I saw the errors for missing libraries show up - so it may be > a similar issue since their comments indicate an upgrade from F14 as well. His issue looks to me as an SELinux issue. Do you run your system in Enforcing or Permissive mode? SELinux is disabled on this box. Hello, I have a similar issue : working zabbix-agent on 2 fedora 14 box and after an upgrade using yum, zabbix-agent refuse to start. The update process was done like this : > rpm --import https://fedoraproject.org/static/069C8460.txt > yum update yum > yum clean all > yum --releasever=15 --disableplugin=presto distro-sync --skip-broken selinux is disabled on both boxes. Some logs : > # systemctl start zabbix-agent.service > # systemctl status zabbix-agent.service > zabbix-agent.service - LSB: Start and stop ZABBIX agent > Loaded: loaded (/etc/rc.d/init.d/zabbix-agent) > Active: active (exited) since Wed, 15 Jun 2011 09:41:32 +0200; 5h 57min ago > Process: 16165 ExecStart=/etc/rc.d/init.d/zabbix-agent start (code=exited, status=0/SUCCESS) > Main PID: 16171 (code=exited, status=255) > CGroup: name=systemd:/system/zabbix-agent.service I tried to run "yum remove zabbix-agent" and then run "yum install zabbix-agent" but nothing changed after re-installation. Zabbix version : > # rpm -qi zabbix-agent > Name : zabbix-agent > Version : 1.8.5 > Release : 1.fc15 > Architecture: x86_64 > Install Date: Wed 15 Jun 2011 09:41:27 AM CEST > Group : Applications/Internet > Size : 531947 > License : GPLv2+ > Signature : RSA/SHA256, Thu 21 Apr 2011 07:17:44 PM CEST, Key ID b4ebf579069c8460 > Source RPM : zabbix-1.8.5-1.fc15.src.rpm > Build Date : Thu 21 Apr 2011 11:03:27 AM CEST > Build Host : x86-05.phx2.fedoraproject.org > Relocations : (not relocatable) > Packager : Fedora Project > Vendor : Fedora Project > URL : http://www.zabbix.com/ > Summary : Zabbix Agent > Description : > The Zabbix client agent, to be installed on monitored systems. ldd for zabbix-agent : > # ldd /usr/sbin/zabbix_agentd > linux-vdso.so.1 => (0x00007fff63dff000) > libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f9ee00ee000) > liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f9edfee0000) > libm.so.6 => /lib64/libm.so.6 (0x00007f9edfc5b000) > libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f9edfa40000) > libc.so.6 => /lib64/libc.so.6 (0x00007f9edf6a7000) > libssl3.so => /usr/lib64/libssl3.so (0x00007f9edf471000) > libsmime3.so => /usr/lib64/libsmime3.so (0x00007f9edf244000) > libnss3.so => /usr/lib64/libnss3.so (0x00007f9edef0c000) > libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f9edecec000) > libplds4.so => /lib64/libplds4.so (0x00007f9edeae9000) > libplc4.so => /lib64/libplc4.so (0x00007f9ede8e5000) > libnspr4.so => /lib64/libnspr4.so (0x00007f9ede6a7000) > libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f9ede48d000) > /lib64/ld-linux-x86-64.so.2 (0x00007f9ee0344000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9ede271000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f9ede06d000) > libz.so.1 => /lib64/libz.so.1 (0x00007f9edde56000) > libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f9eddc1e000) > libfreebl3.so => /lib64/libfreebl3.so (0x00007f9edd9bd000) Please tell me if you need any more information. Minor update on my end - the only issue that we seem to have at this point is a DNS lookup on our database backend fails sometimes. I changed to a direct IP address and the service starts OK. The DNS server it is querying is the localhost which is the master DNS server for the domain. It occasionally fails doing a service zabbix-server start from the command line even when named is running and will do a proper DNS lookup of the specified name from the command line. So I guess I'd suggest checking to make sure it can find the server to report to as a first check. Network is working fine on my end (no dns issue), I tried just in case to put the IP address of the server in place of the fqdn, but it changed nothing. Also maybe I should just open a new bug since my problem is only for zabbix-agent (my zabbix server is compiled from source and running on a Debian Squeeze) ? I just tried the following thing : - Install of a brand new Fedora 14 i686 - Upgrade to Fedora 15 - Installation of zabbix-agent using yum - start zabbix using systemctl => it works fine, so it seems like it's only related to the x64 version of Fedora 15 I will try to find the time to test this on a new Fedora 15 installation since i need one in a virtual machine anyway. It's working now with the update from zabbix-agent-1.8.5-1.fc15.x86_64 to zabbix-agent-1.8.5-3.fc15.x86_64. I guess you can close the bug now... This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |