[ZBXNEXT-6406] Do not require Host Interface for External / Simple Checks Created: 2020 Dec 17 Updated: 2024 Apr 10 Resolved: 2022 Oct 06 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | None |
Fix Version/s: | 6.4.0alpha1, 6.4 (plan) |
Type: | Change Request | Priority: | Major |
Reporter: | Frank | Assignee: | Antons Sincovs |
Resolution: | Fixed | Votes: | 7 |
Labels: | externalchecks, externalscripts | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Attachments: | Screen Recording 2022-07-04 at 13.14.10.mp4 host-info-1.png host-info.png host-item-level.png host-level.png item-level-1.png item-level.png pic1.png ✅ ACC_ Optional interfaces for server-originated checks - v1.0.pdf | ||||||||||||||||||||||||
Issue Links: |
|
||||||||||||||||||||||||
Sub-Tasks: |
|
||||||||||||||||||||||||
Team: | Team C | ||||||||||||||||||||||||
Team: | Team C | ||||||||||||||||||||||||
Sprint: | Sprint 89 (Jun 2022), Sprint 90 (Jul 2022), Sprint 91 (Aug 2022) | ||||||||||||||||||||||||
Story Points: | 4 |
Description |
In It would be nice if these checks no longer require a Host Interface, which is already the case for other non-agent checks like "HTTP Agent".
|
Comments |
Comment by Yurii Polenok [ 2021 Nov 03 ] |
We are also forced to create dummy interfaces for hosts with only one "External check" item. |
Comment by Pimmetje [ 2022 Jun 18 ] |
Maybe it's also good to think about having a item were the data is gathered by another host.
For example. If u have a UPS with USB and IP. It would be nice to display the items gathered by a host where the USB is connected on the UPS host. This makes it more transparent for the user to find the needed data. |
Comment by Konstantins Prutkovs [ 2022 Jul 25 ] |
kprutkovs implemented in feature/ZBXNEXT-6406-6.1 |
Comment by Konstantins Prutkovs [ 2022 Aug 08 ] |
Released
|
Comment by Konstantins Prutkovs [ 2022 Aug 08 ] |
Documentation changed:
|
Comment by Dave Mommers [ 2022 Sep 20 ] |
I had an issue today, probably caused by this function. When I detached and then re-attached the "Template Module ICMP Ping" template the 3 items come back as "not supported" stating "Ping item must have target or host interface specified". When looking at the item at host level there is indeed no interface present
I can't change the value of "host interface". But, when I look at the host, an interface is present!
So it seems it ignores the already present interfaces on host level.
*Edit Running on Zabbix version 6.4 alpha 1 |
Comment by Alekz [ 2022 Oct 02 ] |
Yes, I have the same problem on both 6.4alpha1 and 6.4.0beta1. |
Comment by Rostislav Palivoda [ 2022 Oct 04 ] |
Disabled interface fixed in |
[ZBXNEXT-4761] Zabbix Item Type External Check wraps each argument in quotation marks, which breaks PowerShell Core Created: 2018 Aug 10 Updated: 2018 Sep 27 |
|
Status: | Open |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Change Request | Priority: | Major |
Reporter: | Marco Hofmann | Assignee: | Zabbix Support Team |
Resolution: | Unresolved | Votes: | 0 |
Labels: | externalchecks, items, powershell, scripts | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
Debian 9 Stretch amd64 |
Description |
Due to the new possibilites Microsoft offers the Linux community, I installed Microsoft PowerShell and Vmware PowerCLI on Debian. I want Zabbix Proxy to query VMware vCenter via External check. I created a ps1 script which accepts several copmmand line arguments. Zabbix wraps each argument in quotation marks, but PowerShell can't interpret arguments in quotation marks.
Steps to reproduce:
Result: zabbix_proxy.log:
13741:20180809:094425.082 In get_value() key:'vmware.vm.snapshot.count.ps1[-Server {HOST.CONN},-User {$USERNAME},-Password '{$PASSWORD}',-VM {#VM.NAME}]' 13741:20180809:094425.082 In get_value_external() key:'vmware.vm.snapshot.count.ps1[-Server 10.23.0.200,-User [email protected],-Password 'XXX',-VM server.domain.local]' 13741:20180809:094425.083 In zbx_popen() command:'/usr/lib/zabbix/externalscripts/vmware.vm.snapshot.count.ps1 "-Server 10.23.0.200" "-User [email protected]" "-Password 'XXX'" "-VM server.domain.local"'
Zabbix puts quotation marks around any argument: vmware.vm.snapshot.count.ps1 "-Server 10.23.0.200" "-User [email protected]" "-Password 'XXX'" "-VM server.domain.local"' These arguments won't get parsed in the script.
Expected: The String should be created as following: vmware.vm.snapshot.count.ps1 -Server 10.23.0.200 -User [email protected] -Password 'XXX' -VM server.domain.local I need Zabbix to let the Admin choose, if the arguments are put in quotation marks or not.
I solved it, by calling a Linux Bash Script first, which accepts five arguments and parses the arguments to the powershell script without quotation marks:
/usr/lib/zabbix/externalscripts/vmware.ps.wrapper.sh:
#!/bin/bash /usr/bin/pwsh -File /usr/lib/zabbix/externalscripts/$1 -Server $2 -User $3 -Password $4 -VM $5
|
Comments |
Comment by Edgar Akhmetshin [ 2018 Aug 10 ] |
Hello, Marco Thank you for contacting Zabbix. Beginning with version 2.0.0, quotation marks are used for all arguments of the external checks. You can process arguments with quotes using the capabilities of a powershell script. Looks like a ZBXNEXT request. Please note that ZBX is a Bug Tracker, no indication of a bug here. |
Comment by Marco Hofmann [ 2018 Sep 27 ] |
Thank you very much, for moving my Request into the right Tracker! – "You can process arguments with quotes using the capabilities of a powershell script." I'm a PowerShell beginner, as far as I found out, arguments in quotes won't get parsed into the script, but if I'm wrong I would gladly correct myself. The Bash Wrapper script to strip the quotation marks down is overhead, but works very well! |
[ZBXNEXT-3006] A cache to provide multiple metrics of a single custom function Created: 2015 Oct 09 Updated: 2024 Apr 10 Resolved: 2017 Aug 30 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Agent (G), Proxy (P), Server (S) |
Affects Version/s: | 2.2.10 |
Fix Version/s: | 3.4.1rc1, 3.4 (plan), 4.0.0alpha1 |
Type: | New Feature Request | Priority: | Minor |
Reporter: | Marc | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 10 |
Labels: | bulk, cache, externalchecks, loadablemodule, performance, userparameters | ||
Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
Attachments: | broken-change-per-second.png zbx_export_hosts.xml zbxnext-3006.patch | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sub-Tasks: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Team: | Team C | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Team: | Team C | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sprint: | Sprint 2, Sprint 4, Sprint 5, Sprint 6, Sprint 7, Sprint 8, Sprint 9, Sprint 10, Sprint 11, Sprint 12, Sprint 13, Sprint 14, Sprint 15 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Story Points: | 24 |
Description |
Custom functions (items) based on External check, User parameter or loadable module often parse output or content of commands resp. files that include information for lots of metrics. Thanks to parameter support in items keys a single function can be used to extract the value of a particular metric only. In best case a loadable module function is used to access a pseudo file.
UserParameter=openvz.ubc[*],/usr/bin/sudo /usr/bin/tac /proc/user_beancounters | awk '/$1/{print $(NF-5+$2);exit}'
The previous User parameter extracts one of five possible values for one of 20 possible resources from OpenVZ's User Beancounters table When being interested in every available metric this means 100 User parameter calls each obtaining the very same information per OpenVZ container - and there may be hundreds of containers per physical host. This ticket is about providing a way to improve this by caching all potential information in memory, so that (dynamic provided) custom functions can then extract data from this regularly updated cache. What I currently think of is introducing a new cache, lets say Bulk Parameter Cache, which may be populated by Bulk parameters. BulkUserParameter=openvz.ubc,1,sudo tac /proc/user_beancounters | awk ... What means the agent executes the deposited command every minute and memorizes the output in the designated cache.
# sudo tac /proc/user_beancounters | awk '$1=="uid"{for(i=4;i>=0;i--)h[i]=$(7-i);next}$6~/./{r=$(NF-5);for(i=0;i<5;i++)printf("openvz.ubc[%s,%s] %d\n",r,h[i],$(NF-i))}'
openvz.ubc[kmemsize,failcnt] 0
openvz.ubc[kmemsize,limit] 1217787766
openvz.ubc[kmemsize,barrier] 1217604266
openvz.ubc[kmemsize,maxheld] 793927680
openvz.ubc[kmemsize,held] 764308562
openvz.ubc[lockedpages,failcnt] 0
openvz.ubc[lockedpages,limit] 1368
openvz.ubc[lockedpages,barrier] 1368
openvz.ubc[lockedpages,maxheld] 123
--- SNIP --- SNAP --- SNIP --- SNAP ---
On each cache updated new keys get appended, existing key values get updated and missing keys get removed from the cache. Ideally each in cache existing key becomes dynamically a valid item key available to passive as well as to active agent checks returning the current key value on demand. By this the expensive part is significant reduced to one call per minimum desired item update interval. Of course this should not be limited to Bulk user parameters but be also supported for Bulk external checks or for use in loadable modules. PS: OpenVZ has been chosen as example just because of being easy to parse. |
Comments |
Comment by Marc [ 2015 Oct 09 ] |
Because the item key openvz.ubc is already provided by the BulkUserParameter definition, there is of course no need to include the item key part in the Bulk User parameter's output:
# sudo tac /proc/user_beancounters | awk '$1=="uid"{for(i=4;i>=0;i--)h[i]=$(7-i);next}$6~/./{r=$(NF-5);for(i=0;i<5;i++)printf("[%s,%s] %d\n",r,h[i],$(NF-i))}'
[kmemsize,failcnt] 0
[kmemsize,limit] 1217787766
[kmemsize,barrier] 1217604266
--- SNIP --- SNAP --- SNIP --- SNAP ---
On the other hand could it be desired to provide different item keys by one Bulk parameter. So it could also be kept in the output but left out int the definition: BulkUserParameter=1,sudo tac /proc/user_beancounters | awk ... |
Comment by Strahinja Kustudic [ 2015 Oct 10 ] |
This is similar to what I suggested in this comment in issue I thought about it from the last time I replied to the issue above and here is an idea how I would implement this. I wouldn't even create a special zabbix_agent.conf parameter like BulkUserParameter, but just use the existing one UserParameter and only add a new type of item in the UI called Zabbix Agent Bulk. This item type would define the user parameter which will be called on the agent to return multiple items. This item type would have everything as regular items, but in it you would need to define item keys which will be returned. The only thing I'm not sure is if this bulk item should also return a value for itself, if it fails to execute, or something. |
Comment by Marc [ 2015 Oct 10 ] |
it may appear similar but it's different. This request is neither about providing additional context information alongside an item's value (status, criticity, etc.) nor is it about returning separate values or key=value for a single item. A Zabbix item is atomic and that's a very good design decision in my opinion - performance wise and in terms of processability too. The motivation of this request is to significant improve performance and efficiency in cases where lots of valuable information can be provided by a single custom call. From my experience when extending Zabbix one has rarely complete distinct custom items. In Most cases one accesses a single interface that provides plenty of valuable information one likely wants to obtain by dedicated items: Database metrics -> pgsql, sqlite3, db_stat, sqlplus, mysql,... To name only some of them. All of these commands may provide lots of information for separate Zabbix items in one run. Instead of calling them again and again for each custom item, this ticket requests a way to call them only once and provide their output in a cache for potential Item calls in the future. In fact the proper formatted output gets parsed to fill the cache. Because this request does not affect any design principle of Zabbix, there is also no need to touch the Web frontend nor the way things get handled. It's a change at the very beginning of the process chain. |
Comment by Strahinja Kustudic [ 2015 Oct 10 ] |
I'm not sure I exactly understand how you suggestion works, but let me try to understand it. You would basically create an item in the UI which will call the openvz.ubc BulkUserParameter and that item will update the cache for all those items on the agent. Then you would create items in the UI which will have item keys like those which the BulkUserParameter updates in the agent cache, so if the server requests values for those items, the agent would send the data from the cache, without running any queries. If that is the case, you are right, nothing would need to be changed the UI, but it would still be a little complicated to answer how are those items being updated, unless you know how the script works. Also what will the openvz.ubc item return to the server, since it has to return something, it cannot only update cache by echo-ing items/values? |
Comment by Marc [ 2015 Oct 10 ] |
Well, I've got several scenarios for a possible implementation in mind. This is the one I currently favor for Bulk user parameter : --- SNIP zabbix_agentd.conf --- # BulkUserParameter=<key>,<interval>,<command> BulkUserParameter=openvz.ubc,1,sudo tac /proc/user_beancounters | awk ... --- SNAP zabbix_agentd.conf --- Configuration of BulkUserParameter is considered on Zabbix agent (re)start only. The configured <key> becomes a supported item key. [kmemsize,failcnt] 0 [kmemsize,limit] 1217787766 [kmemsize,barrier] 1217604266 --- SNIP --- SNAP --- SNIP --- SNAP --- The corresponding cache representation could then look like this: openvz.ubc[kmemsize,failcnt] 0 openvz.ubc[kmemsize,limit] 1217787766 openvz.ubc[kmemsize,barrier] 1217604266 --- SNIP --- SNAP --- SNIP --- SNAP --- When the Zabbix agent gets a request for the item key openvz.ubc[kmemsize,limit], then it knows that openvz.ubc[*] is a Bulk user parameter, searches in the Bulk Parameter Cache for the related cache entry and returns the corresponding value. In this case 1217787766. By this the actual custom command (Bulk User parameter) gets automatically executed once per minute and keeps current values for 100 different Items in memory (in this example). Which item values finally get send/returned to the Zabbix server/proxy in which interval, is decided on Zabbix frontend, resp. by Zabbix server in dependency which items had been created. Another benefit is that one can decide/change on Zabbix frontend the interval for each such item. The latter is by the way one of the reasons why I don't like to use zabbix_sender instead. When bulk sending item values by Zabbix sender, then all metrics get send to Zabbix server/proxy, regardless if they are configured or not. Further the update intervals are not individually changeable in Zabbix frontend but are the same to all items. |
Comment by Marc [ 2015 Nov 14 ] |
Similar idea but makes use of memcached: Edit: Special thanks to steki for dropping a comment that made me find that |
Comment by Max [ 2016 Sep 20 ] |
Hello everybody, I think this issue is very important and concerns not only UserParameters, but all item types (simple checks, external checks, ssh checks, log monitoring, database monitoring etc). However, for SNMP checks it is implemented in BulkSNMP. My suggestion is to split definitions: ITEMS and CHECKS. Items is a monitoring parameter, check is a collection method. Multiple items can be assigned to one check by string id or by order number in the check output with delimiters (depending on the check type). In conclusion. |
Comment by dimir [ 2017 Mar 07 ] |
Related issue: |
Comment by Max [ 2017 Mar 07 ] |
dimir, |
Comment by dimir [ 2017 Mar 07 ] |
I would disagree. I understand that this issue is bit different but to me the idea is the same: one check results in multiple values for other items. Item pre-processing is the first step to that, so to me these issues are related. |
Comment by Rostislav Palivoda [ 2017 Jun 07 ] |
Please take care of server side testing - wiper |
Comment by Vjaceslavs Bogdanovs [ 2017 Jun 08 ] |
Server side is ready for testing in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-3006 |
Comment by Andris Zeila [ 2017 Jun 12 ] |
(3) [I] Monitoring of the new processes must be added to the default Zabbix templates (zabbix[process,<process>,avg,busy] items with corresponding triggers. vjaceslavs Added monitoring to templates. RESOLVED in r69199 wiper CLOSED |
Comment by Vjaceslavs Bogdanovs [ 2017 Jun 12 ] |
(4) [S] preprocessor_link_delta_items can be called with unitialized item configuration if item is not "preprocessable". vjaceslavs RESOLVED in r69198, r69241 wiper CLOSED |
Comment by Andris Zeila [ 2017 Jun 13 ] |
(5) [S] Naming improvements:
vjaceslavs RESOLVED in r69241 wiper CLOSED |
Comment by Andris Zeila [ 2017 Jun 14 ] |
(6) [S] item.dependent_items vector update is done by clearing and rebuilding the dependent item vector for all items. This will not work with the configuration sync changes in trunk. Only the changed rows will be passed to DCsync_items(). There are few options:
The (1) is more optimal for partial configuration cache updates, but (2) is much easier to implement. vjaceslavs RESOLVED in r69628 wiper CLOSED |
Comment by Vjaceslavs Bogdanovs [ 2017 Jun 15 ] |
(7) [S] Additional check was missing for LLD items that are not discovered anymore (items without lld_row should not be linked with parent as they will not be updated). wiper CLOSED |
Comment by Andris Zeila [ 2017 Jun 16 ] |
(10) [S] More naming improvements: A 'dep' abbreviation is used when processing trigger dependencies. Vectors/arrays storing identifiers usually have ids suffix. And commonly the number of something has suffix _num. So dep_itemids in ZBX_DC_ITEM structure and dep_itemids_num, dep_itemids in DC_ITEM structure would be better match to existing names. vjaceslavs RESOLVED in r69310 wiper CLOSED |
Comment by Andris Zeila [ 2017 Jun 19 ] |
(11) [S] Fixed dependent item copying when linking templates. Also minor code improvement, please review. vjaceslavs Thanks! CLOSED |
Comment by Andris Zeila [ 2017 Jul 03 ] |
(12) [S] Fixed possible memory leaks/corruption when setting the calculated value/error to agent result. Also cleaned up uninitalized memory errors reported by valgrind (might have been false positive though). Please review. vjaceslavs Thanks! Reviewed and CLOSED |
Comment by Andris Zeila [ 2017 Jul 03 ] |
(13) [S] Value type is used for type hinting during string to numeric conversions in trunk. While currently value type is not used by preprocessor it will be easier to merge if it was added to the manager->worker request package. vjaceslavs RESOLVED in r69852 as a part or merge wiper CLOSED |
Comment by Andris Zeila [ 2017 Jul 05 ] |
(14) [S] Another 'todo' when merging trunk - new preprocessing options were added to trunk. The location of item_preproc.c file was changed - you will probably need to merge the changes manually. vjaceslavs RESOLVED in r69852 as a part or merge wiper CLOSED |
Comment by Andris Zeila [ 2017 Jul 05 ] |
(15) [F] The dependent item graphs consists of dots without lines. I understand this is because delay period for dependent items is 0. For dependent items we will have to take the master's delay period (in worst case scenario we will need to travel dependent item chain to the 'root' item). Moved to frontend task CLOSED |
Comment by Andris Zeila [ 2017 Jul 05 ] |
Server side is tested, however due to the differences with trunk some things will have to be retested after merge. |
Comment by Andris Zeila [ 2017 Jul 06 ] |
(16) [S] Fixed few merge issues, please review r69865 vjaceslavs Thanks! Reviewed and added some minor fixes in r69869. RESOLVED wiper CLOSED |
Comment by Andris Zeila [ 2017 Jul 06 ] |
(17) [S] In DCsync_items() the ids vector is used only to update dependent items in master items. My suggestion would be to use ptr vector where only new dependent items or dependent items with changed master items would be added. vjaceslavs RESOLVED in r69868 wiper CLOSED |
Comment by Andris Zeila [ 2017 Jul 07 ] |
Server side (trunk merge) tested. |
Comment by Dimitri Bellini [ 2017 Jul 12 ] |
Hi Andris, |
Comment by Andris Zeila [ 2017 Jul 24 ] |
Dimitri, it's marked for 3.4 in Fix Version/s (you should be able to see it above). However It doesn't seem to be merged in trunk yet. |
Comment by Dimitri Bellini [ 2017 Jul 24 ] |
Hi Andris, |
Comment by Andris Zeila [ 2017 Jul 24 ] |
Shortly - it allows to create items with another item as data source and using preprocessing options to extract required value. I'd suggest to wait for documentation. |
Comment by Dimitri Bellini [ 2017 Jul 24 ] |
I understood the concept but as you suggest i will wait documentation, thanks very much! |
Comment by Andris Zeila [ 2017 Jul 27 ] |
(23) [S] As preprocessing is done before values are stored into history cache the ZBX_FLAG_ITEM_FIELDS_PREPROC flag can be removed when getting items from configuration cache in dbcache.c:DCmass_update_items() function. vjaceslavs Changed to ZBX_FLAG_ITEM_FIELDS_DEFAULT. RESOLVED in r70675 wiper CLOSED |
Comment by Andris Zeila [ 2017 Aug 01 ] |
(24) [S] At some point in the trunk we added step number to the preprocessing step failure message, something like Item preprocessing step #1 failed: <message>. vjaceslavs RESOLVED in r71044 wiper CLOSED |
Comment by Vladislavs Sokurenko [ 2017 Aug 01 ] |
(27) [I] Proxy does not compile make[3]: *** No rule to make target '../../src/zabbix_server/preprocessor/libpreprocessor.a', needed by 'zabbix_proxy'. Stop. make[2]: *** [Makefile:673: install-recursive] Error 1 make[1]: *** [Makefile:471: install-recursive] Error 1 make: *** [Makefile:477: install-recursive] Error 1 |
Comment by Marc [ 2017 Aug 03 ] |
Gents, please, please with sugar on top, re-consider sharing specs with the community from the very beginning. This is just yet another example of missing the point, which could have been easily identified, if acting more open and transparent. While the current implementation is possibly a nice feature, it has less to do with the demand behind Anyway, I appreciate your commitment! |
Comment by Andris Zeila [ 2017 Aug 03 ] |
As I understand the Eichhoernchen project it implements workaround for:
This feature besides moving item preprocessing to separate processes, itroduces dependent items, allowing to use an item as data source for other items, so basically returning multiple metrics from an item. |
Comment by Marc [ 2017 Aug 03 ] |
As I understood the current implementation, a master item updates all dependent items at the time of the master items update. If we keep the terminology, then this feature request was actually about a master item that may update dependent items with individual update intervals. In the origin request the master item update interval would give the minimum usable update interval of dependent items. A smaller update interval of dependent items would be possible, but would of course not lead to a greater detail. But a larger update interval allows to lead to less item values and easier processing (rendering graphs, 3rd party API use cases, etc.) This can make a huge difference when indeed going up to 999 items for thousands of hosts. The Eichhoernchen project instead was even attempting to make this smart. Smart in the sense that the master data gets updated in dependency of dependent items. that's to say, update the master data only, if the the data does not exist yet, or a dependent items is about to be updated, where the item's update interval is smaller than the age of the master data. The current implementation is rather similar to repetitive sending data for multiple items in a bulk by Zabbix sender, than to a cache that allows individual items, incl. individual item update intervals. While I've to admit that the issue description didn't pointed out that individual update interval fact explicitly (to me it was an obvious fact of using a cache as described), it has been at least mentioned in the comments. Having been able to follow the spec from the very beginning, could have helped to clarify that this is not addressing the actual need, resp. is a yet cool but different ZBXNEXT. |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Aug 03 ] |
I think we can improve to make everybody happy, see |
Comment by Dimitri Bellini [ 2017 Aug 03 ] |
Hi Glebs, |
Comment by Andris Zeila [ 2017 Aug 08 ] |
Released in:
|
[ZBXNEXT-2904] Option to securely pass sensitive arguments to External check and User parameter Created: 2015 Aug 15 Updated: 2021 Apr 08 |
|
Status: | Open |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Agent (G), Proxy (P), Server (S) |
Affects Version/s: | 2.2.10 |
Fix Version/s: | None |
Type: | New Feature Request | Priority: | Major |
Reporter: | Marc | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 1 |
Labels: | externalchecks, security, userparameters | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
Command line arguments or environment variables can easily be exposed via the /proc file system. Since Now I wonder whether it is feasible to improve External check and User parameter functionality to be usable for such cases too - to get sensitive data passed more securely. The only way I currently can think of is by optionally passing data to stdin of the custom command. I've no clue whether it should rather be configurable in a fixed format with two variables only (username and password) or a free form field supporting line breaks. The first allows to use existing form fields. The latter provides maximum flexibility for instance to adapt a format that is already supported by a given custom command. I know, without something like |
Comments |
Comment by Justin Addams [ 2021 Apr 08 ] |
If I understand correctly, this is still an issue experienced even when using the new secure macros? |
[ZBXNEXT-2656] Allow the use of {host:key.func(param)} macros in item key parameters Created: 2014 Dec 31 Updated: 2017 Nov 27 |
|
Status: | Open |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Frontend (F), Server (S) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | New Feature Request | Priority: | Minor |
Reporter: | Raymond Kuiper | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 1 |
Labels: | externalchecks, macro, macros, userparameters | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
In some cases the calculated items do not allow enough flexibility to work with item values. For instance, working with text values (search/replace, string count, count matching lines, etc.) is not possible and doing more complex statistical analysis (trending) or conversions is also not possible (mapping retrieved location data to geolocation for instance). This could all be easily solved with external script items, userparameter items or loadable module items, but we would need a way to pass the item values we want to work with to these items. Allowing the use of these macros in the key parameters will allow us to do so. |
Comments |
Comment by Javier Barroso [ 2017 Nov 27 ] |
A common case at our environment, at least for zabbix agent and zabbix trapper items would be: hostname=srv0x Would be useful to have the possibility of extract "x" number for use in keys Thanks ! |
[ZBXNEXT-2178] Add the ability to use {host:key.func()} on External Checks Created: 2014 Feb 28 Updated: 2014 Mar 16 Resolved: 2014 Mar 16 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Server (S) |
Affects Version/s: | 2.2.2 |
Fix Version/s: | None |
Type: | Change Request | Priority: | Minor |
Reporter: | Andres Abelardo Villarroel Acosta | Assignee: | Unassigned |
Resolution: | Duplicate | Votes: | 0 |
Labels: | externalchecks, macro, server | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
Red Hat Enterprise Linux Server release 6.5 (Santiago) with repo.zabbix.com |
Issue Links: |
|
Description |
Can be useful to use {host:key.func()}on External Checks, to modify gathered items with external programs or scripts or get another type of information based on item results. |
Comments |
Comment by Oleksii Zagorskyi [ 2014 Mar 05 ] |
Somehow similar to Do you agree ? |
Comment by Andres Abelardo Villarroel Acosta [ 2014 Mar 05 ] |
Yes! Ultimately one can accomplish the same task with |
Comment by richlv [ 2014 Mar 16 ] |
closing as a duplicate of |
[ZBXNEXT-2110] Empty string is valid return value Created: 2014 Jan 13 Updated: 2015 Mar 13 Resolved: 2015 Mar 13 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Server (S) |
Affects Version/s: | 2.0.10 |
Fix Version/s: | None |
Type: | Change Request | Priority: | Minor |
Reporter: | Rob Northen | Assignee: | Unassigned |
Resolution: | Duplicate | Votes: | 0 |
Labels: | externalchecks, patch | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
Hi, I'm looking for a patch which was applied during I'm looking for a way to revert it back for my setup. Thank You very much. |
Comments |
Comment by Oleksii Zagorskyi [ 2014 Jan 14 ] |
Hmm, it doesn't look like a feature request. You can see changes when they were merged to trunk branch https://www.zabbix.org/websvn/wsvn/zabbix.com?op=comp&compare[]=%2F@19733&compare[]=%2F@19734 CLOSED. |
Comment by Rob Northen [ 2014 Jan 16 ] |
Hi Oleksiy, Thank You for commit location. If anyone is interested I've made simple patch for v2.0.9. --- src/zabbix_server/poller/checks_external.c 2013-10-08 13:27:46.000000000 +0200 +++ src/zabbix_server/poller/checks_external.c 2014-01-15 08:16:45.978693607 +0100 @@ -94,7 +94,7 @@ int get_value_external(DC_ITEM *item, AG { zbx_rtrim(buf, ZBX_WHITESPACE); - if (SUCCEED == set_result_type(result, item->value_type, item->data_type, buf)) + if ((SUCCEED == set_result_type(result, item->value_type, item->data_type, buf)) && ('\0' != *buf)) ret = SUCCEED; zbx_free(buf); It will bring Zabbix 1.8 behaviour back. External scripts won't accept empty strings as return value any more. Regards, |
Comment by Rob Northen [ 2014 Nov 21 ] |
Ok, here goes feature request. Please add "./configure" option or "zabbix_server.conf" configuration variable to Zabbix which will define interpretation of empty strings as return values. Thank You |
Comment by richlv [ 2015 Mar 13 ] |
closing as a duplicate of ZBXNEXT-540 |
[ZBXNEXT-2098] Creation of loadable modules using script languages/subagent mechanism Created: 2014 Jan 06 Updated: 2024 Apr 10 |
|
Status: | Elaborating |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Agent (G), Proxy (P), Server (S) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | New Feature Request | Priority: | Major |
Reporter: | Marc Schoechlin | Assignee: | Vadim Ipatov |
Resolution: | Unresolved | Votes: | 7 |
Labels: | externalchecks, loadablemodule | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Team: | Team A |
Team: | Team A |
Sprint: | Sprint 14, Sprint 15, Sprint 16, Sprint 17, Sprint 18, Sprint 19, Sprint 20, Sprint 21, Sprint 22, Sprint 23 |
Description |
I really welcome the possibility to create loadable modules for zabbix - this might make solutions like https://github.com/digitalmediacenter/mysql_extend obsolete Typically sysadmins are good in writing code with script languages - therefore it would be great to integrate new monitoring functionality by using script languages. MySQL_Extend is a good example - a external check which invokes the mysql commandline hundred times needs a lot of resources at the database server and It might be great if zabbix would embed a python, ruby, perl or php interpreter to for implementation of custom modules. From my point of view this is smarter, because:
|
Comments |
Comment by richlv [ 2014 Jun 30 ] |
not quite that, but ruby support implemented as a loadable module : https://github.com/BlueSkyDetector/mruby_module_for_zabbix_agent |
Comment by Marc [ 2017 Jul 21 ] |
In the sense of richlv's comment, these two are possibly worth to mention as well: |
Comment by Marc Schoechlin [ 2017 Oct 27 ] |
Its nice to have the mruby module - python might be my fist choice I still think that the invocation of a subprocess would be a really good thing (i described the reasons above) and would boost the capabilities of zabbix dramatically. |
[ZBXNEXT-1897] Return unknown (unsupported) value by external checker using non-zero exit code Created: 2013 Sep 09 Updated: 2015 Mar 13 Resolved: 2015 Mar 13 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Server (S) |
Affects Version/s: | 2.0.8 |
Fix Version/s: | None |
Type: | New Feature Request | Priority: | Minor |
Reporter: | Pavel | Assignee: | Unassigned |
Resolution: | Duplicate | Votes: | 1 |
Labels: | exitcodes, externalchecks, userparameters | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
Sometimes external checker cannot get item value - host unavailable or something like this. |
Comments |
Comment by richlv [ 2013 Sep 10 ] |
similar to ZBXNEXT-152 |
Comment by richlv [ 2014 Apr 12 ] |
|
Comment by richlv [ 2015 Mar 13 ] |
closing as a duplicate of ZBXNEXT-540 |
[ZBXNEXT-1676] increasing "busy zabbix poller processes" because it uses a lot of external check Created: 2013 Mar 21 Updated: 2013 Mar 21 Resolved: 2013 Mar 21 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Server (S) |
Affects Version/s: | 2.0.5 |
Fix Version/s: | None |
Type: | Change Request | Priority: | Major |
Reporter: | Tintus Ardi | Assignee: | Unassigned |
Resolution: | Won't fix | Votes: | 0 |
Labels: | externalchecks, pollers, scripts | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
Using Debian OS etch 64bit, Pentium(R) Dual-Core CPU E5700 @ 3.00GHz, 3GB RAM, |
Description |
I've seen from the documentation if "external check" can only be executed by the zabbix server. It really helped me to monitor several items that do require special handling by using a particular script. But when I use a lot of items with "external check", "busy zabbix poller processes" on my machine to be up so high. Is the "external check" can be run on agent? Maybe someone can help me to resolve this issue. Thanks. |
Comments |
Comment by richlv [ 2013 Mar 21 ] |
please use zabbix forums, irc and other channels for community support. |
[ZBXNEXT-1380] Zabbix server should check the return code of media scripts Created: 2012 Aug 26 Updated: 2024 Apr 10 Resolved: 2017 Feb 17 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Agent (G), Server (S) |
Affects Version/s: | 2.0.2 |
Fix Version/s: | 3.4.0alpha1, 3.4 (plan) |
Type: | Change Request | Priority: | Minor |
Reporter: | rrr | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 15 |
Labels: | alertscript, externalchecks, media, operations, remotecommands, returncode, scripts, userparameters | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | failed-command-and-alert.png message_for_executed_on_agent.png nohost.png reverted.png same_command.png | ||||||||||||||||||||||||||||||||||||||||
Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
Team: | Team A | ||||||||||||||||||||||||||||||||||||||||
Team: | Team A | ||||||||||||||||||||||||||||||||||||||||
Sprint: | Sprint 1 | ||||||||||||||||||||||||||||||||||||||||
Story Points: | 1 |
Description |
It would be nice if zabbix server check the return code of media scripts to ensure that the recipient received the message. |
Comments |
Comment by Raymond Kuiper [ 2012 Oct 15 ] |
+1 |
Comment by sergio cricca [ 2012 Oct 15 ] |
+1 |
Comment by Raymond Kuiper [ 2012 Oct 15 ] |
Please also cast a vote! |
Comment by richlv [ 2012 Oct 15 ] |
seriously guys, "+1" comments are not helpful. they actually only clutter the issues, result in useless notifications and i'm considering some mass cleanup (read - deletion) of such comments :/ issue voting feature is in the upper right corner. it's also described in bug reporting guidelines at https://zabbix.org/wiki/Docs/bug_reporting_guidelines#Reporting_an_issue |
Comment by Marc [ 2013 Sep 10 ] |
similar to |
Comment by Timofey [ 2016 Aug 16 ] |
Hi guys, i find workaround (bad but works) |
Comment by Raymond Kuiper [ 2016 Nov 10 ] |
How is this still a problem with modern versions of Zabbix? |
Comment by Raymond Kuiper [ 2016 Nov 10 ] |
@Timofey, thanks for the 'workaround' btw. Setting 'sleep 120' before every exit at least makes Zabbix see the message as failed. |
Comment by Stefan Radman [ 2016 Nov 10 ] |
Can someone update the affected versions, update the priority and get this feature request assigned? |
Comment by Raymond Kuiper [ 2016 Nov 10 ] |
I would also argue that if a non-zero exit code is received, any stderr script output should be shown as the error message (perhaps truncated) in the frontend. |
Comment by richlv [ 2016 Nov 10 ] |
stefan.radman, if you have a support agreement with the zabbix company, you might want to raise this topic through your contact person there. |
Comment by Stefan Radman [ 2016 Nov 10 ] |
got your point. We have a support agreement and I might raise it there. Thanks |
Comment by Oleksii Zagorskyi [ 2016 Nov 10 ] |
The timeout for alerter is hardcoded to 40 seconds (as I recall), so sleeping alert scripts on failure could cause alerter processed to be too busy (I saw that a few times on different installations because of simply slow alert script). |
Comment by Stefan Radman [ 2016 Nov 10 ] |
I raised an issue through support and it got assigned. |
Comment by Oleksii Zagorskyi [ 2016 Nov 13 ] |
It would be also nice if SDTERR of alert script would be stored as error message (in alerts), similarly as we log errors for "Email" media type. I use the this dummy script as alert media (and remmote command, below):
# cat /etc/zabbix/alertscripts/test.pl
#!/usr/bin/perl
#use warnings;
use strict;
print "done\n";
sdfg sf
# /etc/zabbix/alertscripts/test.pl done Can't locate object method "sdfg" via package "sf" (perhaps you forgot to load "sf"?) at /etc/zabbix/alertscripts/test.pl line 6. # /etc/zabbix/alertscripts/test.pl 1>/dev/null Can't locate object method "sdfg" via package "sf" (perhaps you forgot to load "sf"?) at /etc/zabbix/alertscripts/test.pl line 6. # /etc/zabbix/alertscripts/test.pl 2>/dev/null done 20676:20161113:162315.421 __zbx_zbx_setproctitle() title:'alerter [sending alerts]' 20676:20161113:162315.421 query [txnlev:0] [select a.alertid,a.mediatypeid,a.sendto,a.subject,a.message,a.status,mt.mediatypeid,mt.type,mt.description,mt.smtp_server,mt.smtp_helo,mt.smtp_email,mt.exec_path,mt.gsm_modem,mt.username,mt.passwd,mt.smtp_port,mt.smtp_security,mt.smtp_verify_peer,mt.smtp_verify_host,mt.smtp_authentication,mt.exec_params,a.retries from alerts a,media_type mt where a.mediatypeid=mt.mediatypeid and a.status=0 and a.alerttype=0 order by a.alertid] 20676:20161113:162315.422 In execute_action(): alertid [130] mediatype [0] 20676:20161113:162315.422 In send_email() smtp_server:'mail.zabbix.com' smtp_port:25 smtp_security:0 smtp_authentication:0 20676:20161113:162320.773 End of send_email():SUCCEED 20676:20161113:162320.773 End of execute_action():SUCCEED 20676:20161113:162320.773 alert ID [130] was sent successfully 20676:20161113:162320.773 query without transaction detected 20676:20161113:162320.773 query [txnlev:0] [update alerts set status=1,error='' where alertid=130] 20676:20161113:162320.774 In execute_action(): alertid [131] mediatype [1] 20676:20161113:162320.774 In zbx_popen() command:'/etc/zabbix/alertscripts/test.pl' 20676:20161113:162320.775 End of zbx_popen():9 20838:20161113:162320.776 zbx_popen(): executing script 20676:20161113:162320.779 In zbx_waitpid() 20676:20161113:162320.779 zbx_waitpid() exited, status:255 20676:20161113:162320.779 End of zbx_waitpid():20838 20676:20161113:162320.779 test.pl output: Can't locate object method "sdfg" via package "sf" (perhaps you forgot to load "sf"?) at /etc/zabbix/alertscripts/test.pl line 4. done 20676:20161113:162320.779 End of execute_action():SUCCEED 20676:20161113:162320.779 alert ID [131] was sent successfully 20676:20161113:162320.779 query without transaction detected 20676:20161113:162320.779 query [txnlev:0] [update alerts set status=1,error='' where alertid=131] 20676:20161113:162320.780 __zbx_zbx_setproctitle() title:'alerter [sent alerts: 2 success, 0 fail in 5.358552 sec, idle 5 sec]' And for consistency .... remote command (performed by escalator, not alerter) should be taken into account too, because they even do not log the STDERR to server log, which is not very nice. 20689:20161113:162306.866 Conditions match our event. Execute operation. 20689:20161113:162306.866 In execute_commands() 20689:20161113:162306.866 query [txnlev:1] [select distinct h.hostid,h.host,o.type,o.scriptid,o.execute_on,o.port,o.authtype,o.username,o.password,o.publickey,o.privatekey,o.command,h.tls_connect,h.ipmi_authtype,h.ipmi_privilege,h.ipmi_username,h.ipmi_password from opcommand o,opcommand_grp og,hosts_groups hg,hosts h where o.operationid=og.operationid and og.groupid=hg.groupid and hg.hostid=h.hostid and o.operationid=17 and h.status=0 union select distinct h.hostid,h.host,o.type,o.scriptid,o.execute_on,o.port,o.authtype,o.username,o.password,o.publickey,o.privatekey,o.command,h.tls_connect,h.ipmi_authtype,h.ipmi_privilege,h.ipmi_username,h.ipmi_password from opcommand o,opcommand_hst oh,hosts h where o.operationid=oh.operationid and oh.hostid=h.hostid and o.operationid=17 and h.status=0 union select distinct 0,null,o.type,o.scriptid,o.execute_on,o.port,o.authtype,o.username,o.password,o.publickey,o.privatekey,o.command,1,0,2,null,null from opcommand o,opcommand_hst oh where o.operationid=oh.operationid and o.operationid=17 and oh.hostid is null] 20689:20161113:162306.868 In substitute_simple_macros() data:'/etc/zabbix/alertscripts/test.pl' 20689:20161113:162306.868 In zbx_execute_script() 20689:20161113:162306.868 In zbx_popen() command:'/etc/zabbix/alertscripts/test.pl' 20689:20161113:162306.870 End of zbx_popen():9 20827:20161113:162306.870 zbx_popen(): executing script 20689:20161113:162306.878 In zbx_waitpid() 20689:20161113:162306.878 zbx_waitpid() exited, status:255 20689:20161113:162306.878 End of zbx_waitpid():20827 20689:20161113:162306.878 End of zbx_execute_script():SUCCEED 20689:20161113:162306.878 In add_command_alert() 20689:20161113:162306.878 End of add_command_alert() 20689:20161113:162306.878 In DCget_nextid() table:'alerts' num:1 20689:20161113:162306.878 End of DCget_nextid() table:'alerts' [128:128] 20689:20161113:162306.878 query [txnlev:1] [insert into alerts (alertid,actionid,eventid,clock,message,status,error,esc_step,alerttype) values (128,3,1498,1479046986,':/etc/zabbix/alertscripts/test.pl',1,'',1,1);] 20689:20161113:162306.879 End of execute_commands() ... 20689:20161113:162306.879 Conditions match our event. Execute operation. 20689:20161113:162306.879 In execute_commands() 20689:20161113:162306.879 query [txnlev:1] [select distinct h.hostid,h.host,o.type,o.scriptid,o.execute_on,o.port,o.authtype,o.username,o.password,o.publickey,o.privatekey,o.command,h.tls_connect,h.ipmi_authtype,h.ipmi_privilege,h.ipmi_username,h.ipmi_password from opcommand o,opcommand_grp og,hosts_groups hg,hosts h where o.operationid=og.operationid and og.groupid=hg.groupid and hg.hostid=h.hostid and o.operationid=18 and h.status=0 union select distinct h.hostid,h.host,o.type,o.scriptid,o.execute_on,o.port,o.authtype,o.username,o.password,o.publickey,o.privatekey,o.command,h.tls_connect,h.ipmi_authtype,h.ipmi_privilege,h.ipmi_username,h.ipmi_password from opcommand o,opcommand_hst oh,hosts h where o.operationid=oh.operationid and oh.hostid=h.hostid and o.operationid=18 and h.status=0 union select distinct 0,null,o.type,o.scriptid,o.execute_on,o.port,o.authtype,o.username,o.password,o.publickey,o.privatekey,o.command,1,0,2,null,null from opcommand o,opcommand_hst oh where o.operationid=oh.operationid and o.operationid=18 and oh.hostid is null] 20689:20161113:162306.881 In substitute_simple_macros() data:'someeeeee' 20689:20161113:162306.881 In zbx_execute_script() 20689:20161113:162306.882 In zbx_popen() command:'someeeeee' 20689:20161113:162306.883 End of zbx_popen():9 20829:20161113:162306.883 zbx_popen(): executing script 20689:20161113:162306.885 In zbx_waitpid() 20689:20161113:162306.885 zbx_waitpid() exited, status:127 20689:20161113:162306.885 End of zbx_waitpid():20829 20689:20161113:162306.885 End of zbx_execute_script():SUCCEED 20689:20161113:162306.885 In add_command_alert() 20689:20161113:162306.885 End of add_command_alert() 20689:20161113:162306.885 In DCget_nextid() table:'alerts' num:1 20689:20161113:162306.885 End of DCget_nextid() table:'alerts' [129:129] 20689:20161113:162306.885 query [txnlev:1] [insert into alerts (alertid,actionid,eventid,clock,message,status,error,esc_step,alerttype) values (129,3,1498,1479046986,':someeeeee',1,'',1,1);] 20689:20161113:162306.886 End of execute_commands() How does it look like currently in 3.0.5 frontend, falsely saying they were ok: |
Comment by richlv [ 2016 Nov 13 ] |
remote commands might be much harder - server does not wait for the command to be executed. it just sends the command to the agent and gets back '1' (see system.run[nowait,<command>]) |
Comment by Oleksii Zagorskyi [ 2016 Nov 14 ] |
Rich, for commands executed on agent side - that's correct and you are right. I don't consider such case here.
|
Comment by Alexei Vladishev [ 2016 Dec 05 ] |
I hope it will be implemented in Zabbix 3.4, it's in the roadmap. |
Comment by Volker Fröhlich [ 2016 Dec 05 ] |
Can you please publish this roadmap, maybe here? |
Comment by Oleksii Zagorskyi [ 2016 Dec 08 ] |
Thinking about, for example, an alert script, used to sent SMSs through a sms-gateway in the Internet, where connections to the gateway randomly could be failed before timeout ... Just a question - Zabbix uses ALERT_MAX_RETRIES=3 to send alerts. Also, thinking about the 40 seconds hardcoded timeout to be configurable ... |
Comment by Stefan Radman [ 2016 Dec 08 ] |
No, I don't think it makes sense to retry when the script returns an error code, with one possible exception being exit code 75: $ grep -A3 TEMPFAIL /usr/include/sysexits.h * EX_TEMPFAIL -- temporary failure, indicating something that * is not really an error. In sendmail, this means * that a mailer (e.g.) could not create a connection, * and the request should be reattempted later. -- #define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */ #define EX_PROTOCOL 76 /* remote error in protocol */ #define EX_NOPERM 77 /* permission denied */ #define EX_CONFIG 78 /* configuration error */ See also: https://tools.ietf.org/html/rfc3463#section-2 $ grep EAGAIN /usr/include/asm-generic/errno-base.h #define EAGAIN 11 /* Try again */ Configurable timeout (and possibly retries) would definitely be an asset. |
Comment by Vjaceslavs Bogdanovs [ 2017 Jan 02 ] |
Ready for testing in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-1380 |
Comment by Vladislavs Sokurenko [ 2017 Jan 03 ] |
(1) [PSA] Memory leak. output is only freed on SUCCEED, otherwise address is lost and memory is not freed. if (SUCCEED == (rc = zbx_execute_script(&host, &script, NULL, &output, error, sizeof(error)))) { zabbix_log(LOG_LEVEL_DEBUG, "%s output:\n%s", script.command, error); zbx_free(output); } While it is also allocated on not SUCCEED.
if (SUCCEED != ret && NULL != result)
*result = zbx_strdup(*result, "");
vjaceslavs RESOLVED in r64863 vso CLOSED, please review small style fixes in r64868 |
Comment by Vladislavs Sokurenko [ 2017 Jan 03 ] |
(2) [PSA] Unused variable added. if (SUCCEED == (rc = zbx_execute_script(&host, &script, NULL, &output, error, sizeof(error)))) { zabbix_log(LOG_LEVEL_DEBUG, "%s output:\n%s", script.command, error); zbx_free(output); } vjaceslavs RESOLVED in r64863 vso CLOSED |
Comment by Vladislavs Sokurenko [ 2017 Jan 03 ] |
(3) Log is not formatted to zabbix style and misleading. It says printing output while output variable is not printed, instead it prints error variable, and furthermore log is only executed on SUCCEED so there should be no error to print.
zabbix_log(LOG_LEVEL_DEBUG, "%s output:\n%s", script.command, error);
Example logs: zabbix_log(LOG_LEVEL_DEBUG, "In %s() host:'%s' hostid:%d", __function_name, host, hostid); zabbix_log(LOG_LEVEL_DEBUG, "get value from agent result: '%s'", s.buffer); vjaceslavs There was an error in code (2) - should be "output" (not an "error"). And log "style" was taken from alerter.c (126) to make consistent output so can't agree with "there are no such logs in zabbix". Should I change existing log style in alerter as well? vso CLOSED, (2) fixes it, it's fine for long data. |
Comment by Vladislavs Sokurenko [ 2017 Jan 03 ] |
(4) When exec function return error, frontend still display success. The exec() functions return only if an error has occurred, but we set success on error. zabbix_log(LOG_LEVEL_DEBUG, "%s(): executing script", __function_name); execl("/bin/sh", "sh", "-c", command, NULL); /* execl() returns only when an error occurs */ zabbix_log(LOG_LEVEL_WARNING, "execl() failed for [%s]: %s", command, zbx_strerror(errno)); exit(EXIT_SUCCESS); vjaceslavs RESOLVED in r64870. vso CLOSED, now process exited with code: 1 is displayed. |
Comment by Vladislavs Sokurenko [ 2017 Jan 03 ] |
(5) If child did not terminate normally, still SUCCESS is returned. The code below means if the child terminated normally and exit status is not success then fail. But what if child did not terminate normally ? It shall also be failure. else if (WIFEXITED(status) && EXIT_SUCCESS != WEXITSTATUS(status)) { ... } else ret = SUCCEED; vjaceslavs There are multiple options when this kind of "false positive" result can occur: I suggest to add extra status code "UNKNOWN" for situations where script execution status is unknown (so we don't have "Done" in frontend). vjaceslavs Even more, on unix-like systems, command is being executed from shell and even if signal occurs it is handled by shell and exit code is set to non-zero so this is a really specific case when shell crashes. vjaceslavs It was decided to consider signaled state as a failure without altering the retry logic. RESOLVED in r65091 vso CLOSED |
Comment by Vladislavs Sokurenko [ 2017 Jan 04 ] |
(6) Script on zabbix_agent gets killed before it finish execution, if it executes longer than "Timeout" which is 3 by default and max 30 seconds. Previously: system.run[,nowait] Meaning that users can have very long running scripts without being afraid that they will get timed out and killed. Now: Expected: Actual: This is blocker. I suggest that such use cases need to be clearly defined in specification and solution discussed and approved. Why this is happening ? if (SUCCEED == (rc = zbx_execute_script(&host, &script, NULL, &output, error, sizeof(error)))) zabbix_log(LOG_LEVEL_DEBUG, "%s output:\n%s", script.command, output); And in function zbx_execute_script_on_agent() it is used to change "nowait" to "wait item.key = zbx_dsprintf(item.key, "system.run[%s,%s]", param, NULL == result ? "nowait" : "wait"); vjaceslavs There are no other options if we need to get output for log. So the only options are to drop the log to allow users to execute long running scripts or to check result code, but limit execution time. I am not sure if we can consider that there is no need for exit code check in this case. I agree that behavior changes for multiple cases, but it is not really a blocker as user can create background scripts for cases like that (if it is an intended behavior). Documentation for scripts does not provide information about this kind of behavior (execute on agent = async without limits, execute on server = limited by a timeout) so as far as I understand, I would say that current solution unifies solutions for server and agent. Similar situation is with system.run item that will now start to check exit code and can become unsupported because of that. vso Here is link from documentation Remote commands on Zabbix agent are executed without timeout I don't see any problems in checking result code on custom alertscript that is executed on server though. vjaceslavs I added extra description about such cases in specification. We could also implement async remote command execution to bypass this timeout limit but it is not an easy fix so it should be evaluated. vso Thanks ! Lets wait for approval. vjaceslavs It was decided to ignore return code of commands executed on agent and to introduce new action status - "RAN" that means "Executed, but not checked". RESOLVED in r65091 vso CLOSED, though exact messages that need to be displayed are to be confirmed, but it will be minor change. |
Comment by Vjaceslavs Bogdanovs [ 2017 Jan 13 ] |
(7) Custom script (remote command in action -> operation) can be executed multiple times on server if Target list contains multiple records of current host. Steps to reproduce: Action operation will be executed twice. vjaceslavs RESOLVED in r65091 vso REOPENED. Fix must be reverted, it's frontend bug and this fix is not the way it can be handled, I suggest to make separate bug report. sql [select distinct h.hostid,h.host,h.tls_connect from functions f,items i,hosts h where f.itemid=i.itemid and i.hostid=h.hostid and h.status=0 and f.triggerid=13558] 4341:20170116:153222.315 End of get_dynamic_hostid():SUCCEED As well as bunch of other code for checking host duplicates etc.. All this is done to fill host parameter which in the end is not used by server anyway, and it can't be used because no command is executed on any host, it's executed on server. case ZBX_SCRIPT_EXECUTE_ON_AGENT: ret = zbx_execute_script_on_agent(host, script->command, result, error, max_error_len); break; case ZBX_SCRIPT_EXECUTE_ON_SERVER: ret = zbx_execute(script->command, result, error, max_error_len, CONFIG_TRAPPER_TIMEOUT); break; vjaceslavs Documentation states that "A command on a host is executed only once, even if the host matches more than once (e.g. from several host groups; individually and from a host group)" How we treat this problem as a frontend bug? vso CLOSED, Lets create separate ticket for that. |
Comment by Vjaceslavs Bogdanovs [ 2017 Jan 13 ] |
(8) Custom script (remote command in action -> operation) executed on server is shown without host in Reports -> Action log This causes output like that (command starts with ":" as host is missing): vjaceslavs RESOLVED in r65091 vso REOPENED for the same reason as (7) command is not executed on host so this message is not appropriate actually, that's why there was blank. vjaceslavs Command is not executed on host, but it is executed "within host context" and all host related macros will expand to specified host. So we can't say that setting target host for execution on server doesn't change anything. vso Please correct me if I am wrong. vjaceslavs Assuming macro expanding is correct there should be no option to specify targets for scripts executed on server as those values will never be used. So problem is present anyway and we should only find out the scope of the problem. vso CLOSED, Lets create separate ticket for that. |
Comment by Vladislavs Sokurenko [ 2017 Jan 17 ] |
(9) Error message is never displayed to the user for a custom script operation in actions. Expected: Actual: Furthermore this means that buffer is set to NULL so no error messages will be red from custom script. This means that in simple scenario where script could not be found, there will be no error message indicating exactly that. vjaceslavs Added script output collection for all script executions so output can be present if error happens. RESOLVED in r65125 vso REOPENED, Double free corruption is one of the issues introduced but only occurs at specific scenarios. *** Error in `./sbin/zabbix_agentd: listener #1 [processing request]': double free or corruption (top): 0x00000000023122a0 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7fd94fdc0725] /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7fd94fdc8f4a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fd94fdccabc] ./sbin/zabbix_agentd: listener #1 [processing request](EXECUTE_STR+0x89)[0x422479] ./sbin/zabbix_agentd: listener #1 [processing request](process+0x31c)[0x4171cc] ./sbin/zabbix_agentd: listener #1 [processing request](listener_thread+0x19d)[0x413aed] ./sbin/zabbix_agentd: listener #1 [processing request](zbx_thread_start+0x45)[0x42b135] ./sbin/zabbix_agentd: listener #1 [processing request](MAIN_ZABBIX_ENTRY+0x223)[0x416373] ./sbin/zabbix_agentd: listener #1 [processing request](daemon_start+0x1c3)[0x42be53] ./sbin/zabbix_agentd: listener #1 [processing request](main+0xb0)[0x40be20] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fd94fd69830] ./sbin/zabbix_agentd: listener #1 [processing request](_start+0x29)[0x40bf29] ======= Memory map: ======== 00400000-00456000 r-xp 00000000 08:02 13763939 /home/vso/zabbix_eclipse_dev/ZBXNEXT-1380/sbin/zabbix_agentd 00655000-00656000 r--p 00055000 08:02 13763939 /home/vso/zabbix_eclipse_dev/ZBXNEXT-1380/sbin/zabbix_agentd 00656000-00658000 rw-p 00056000 08:02 13763939 /home/vso/zabbix_eclipse_dev/ZBXNEXT-1380/sbin/zabbix_agentd 00658000-0065d000 rw-p 00000000 00:00 0 022ef000-02330000 rw-p 00000000 00:00 0 [heap] 7fd944000000-7fd944021000 rw-p 00000000 00:00 0 7fd944021000-7fd948000000 ---p 00000000 00:00 0 7fd94b4ed000-7fd94b503000 r-xp 00000000 08:02 4460969 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd94b503000-7fd94b702000 ---p 00016000 08:02 4460969 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd94b702000-7fd94b703000 rw-p 00015000 08:02 4460969 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fd94b703000-7fd94b70c000 r-xp 00000000 08:02 4460941 /lib/x86_64-linux-gnu/libcrypt-2.23.so 7fd94b70c000-7fd94b90b000 ---p 00009000 08:02 4460941 /lib/x86_64-linux-gnu/libcrypt-2.23.so 7fd94b90b000-7fd94b90c000 r--p 00008000 08:02 4460941 /lib/x86_64-linux-gnu/libcrypt-2.23.so 7fd94b90c000-7fd94b90d000 rw-p 00009000 08:02 4460941 /lib/x86_64-linux-gnu/libcrypt-2.23.so 7fd94b90d000-7fd94b93b000 rw-p 00000000 00:00 0 7fd94b93b000-7fd94ba0a000 r-xp 00000000 08:02 14165018 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 7fd94ba0a000-7fd94bc0a000 ---p 000cf000 08:02 14165018 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 7fd94bc0a000-7fd94bc0d000 r--p 000cf000 08:02 14165018 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 7fd94bc0d000-7fd94bc0f000 rw-p 000d2000 08:02 14165018 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6 7fd94bc0f000-7fd94bc10000 rw-p 00000000 00:00 0 7fd94bc10000-7fd94bc56000 r-xp 00000000 08:02 14164557 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 7fd94bc56000-7fd94be56000 ---p 00046000 08:02 14164557 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 7fd94be56000-7fd94be58000 r--p 00046000 08:02 14164557 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 7fd94be58000-7fd94be5a000 rw-p 00048000 08:02 14164557 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0 7fd94be5a000-7fd94be5b000 rw-p 00000000 00:00 0 7fd94be5b000-7fd94be69000 r-xp 00000000 08:02 14164539 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 7fd94be69000-7fd94c068000 ---p 0000e000 08:02 14164539 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 7fd94c068000-7fd94c069000 r--p 0000d000 08:02 14164539 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 7fd94c069000-7fd94c06a000 rw-p 0000e000 08:02 14164539 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0 7fd94c06a000-7fd94c091000 r-xp 00000000 08:02 14165183 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 7fd94c091000-7fd94c291000 ---p 00027000 08:02 14165183 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 7fd94c291000-7fd94c292000 r--p 00027000 08:02 14165183 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 7fd94c292000-7fd94c293000 rw-p 00028000 08:02 14165183 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0 7fd94c293000-7fd94c2a8000 r-xp 00000000 08:02 14164936 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0 7fd94c2a8000-7fd94c4a7000 ---p 00015000 08:02 14164936 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0 7fd94c4a7000-7fd94c4a8000 r--p 00014000 08:02 14164936 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0 7fd94c4a8000-7fd94c4a9000 rw-p 00015000 08:02 14164936 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0 7fd94c4a9000-7fd94c4d9000 r-xp 00000000 08:02 14164537 /usr/lib/x86_64-linux-gnu/libhcrypto.so.4.1.0 7fd94c4d9000-7fd94c6d9000 ---p 00030000 08:02 14164537 /usr/lib/x86_64-linux-gnu/libhcrypto.so.4.1.0 7fd94c6d9000-7fd94c6da000 r--p 00030000 08:02 14164537 /usr/lib/x86_64-linux-gnu/libhcrypto.so.4.1.0 7fd94c6da000-7fd94c6db000 rw-p 00031000 08:02 14164537 /usr/lib/x86_64-linux-gnu/libhcrypto.so.4.1.0 7fd94c6db000-7fd94c6dc000 rw-p 00000000 00:00 0 7fd94c6dc000-7fd94c77b000 r-xp 00000000 08:02 14163981 /usr/lib/x86_64-linux-gnu/libasn1.so.8.0.0 7fd94c77b000-7fd94c97a000 ---p 0009f000 08:02 14163981 /usr/lib/x86_64-linux-gnu/libasn1.so.8.0.0 7fd94c97a000-7fd94c97b000 r--p 0009e000 08:02 14163981 /usr/lib/x86_64-linux-gnu/libasn1.so.8.0.0 7fd94c97b000-7fd94c97e000 rw-p 0009f000 08:02 14163981 /usr/lib/x86_64-linux-gnu/libasn1.so.8.0.0 7fd94c97e000-7fd94ca02000 r-xp 00000000 08:02 14164633 /usr/lib/x86_64-linux-gnu/libkrb5.so.26.0.0 7fd94ca02000-7fd94cc01000 ---p 00084000 08:02 14164633 /usr/lib/x86_64-linux-gnu/libkrb5.so.26.0.0 7fd94cc01000-7fd94cc04000 r--p 00083000 08:02 14164633 /usr/lib/x86_64-linux-gnu/libkrb5.so.26.0.0 7fd94cc04000-7fd94cc07000 rw-p 00086000 08:02 14164633 /usr/lib/x86_64-linux-gnu/libkrb5.so.26.0.0 7fd94cc07000-7fd94cc08000 rw-p 00000000 00:00 0 7fd94cc08000-7fd94cc10000 r-xp 00000000 08:02 14164541 /usr/lib/x86_64-linux-gnu/libheimntlm.so.0.1.0 7fd94cc10000-7fd94ce0f000 ---p 00008000 08:02 14164541 /usr/lib/x86_64-linux-gnu/libheimntlm.so.0.1.0 7fd94ce0f000-7fd94ce10000 r--p 00007000 08:02 14164541 /usr/lib/x86_64-linux-gnu/libheimntlm.so.0.1.0 7fd94ce10000-7fd94ce11000 rw-p 00008000 08:02 14164541 /usr/lib/x86_64-linux-gnu/libheimntlm.so.0.1.0 7fd94ce11000-7fd94ce14000 r-xp 00000000 08:02 4460992 /lib/x86_64-linux-gnu/libkeyutils.so.1.5 7fd94ce14000-7fd94d013000 ---p 00003000 08:02 4460992 /lib/x86_64-linux-gnu/libkeyutils.so.1.5 7fd94d013000-7fd94d014000 r--p 00002000 08:02 4460992 /lib/x86_64-linux-gnu/libkeyutils.so.1.5 7fd94d014000-7fd94d015000 rw-p 00003000 08:02 4460992 /lib/x86_64-linux-gnu/libkeyutils.so.1.5 7fd94d015000-7fd94d01c000 r-xp 00000000 08:02 14164274 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 7fd94d01c000-7fd94d21b000 ---p 00007000 08:02 14164274 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 7fd94d21b000-7fd94d21c000 r--p 00006000 08:02 14164274 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 7fd94d21c000-7fd94d21d000 rw-p 00007000 08:02 14164274 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4 7fd94d21d000-7fd94d25a000 r-xp 00000000 08:02 14164462 /usr/lib/x86_64-linux-gnu/libgssapi.so.3.0.0 7fd94d25a000-7fd94d45a000 ---p 0003d000 08:02 14164462 /usr/lib/x86_64-linux-gnu/libgssapi.so.3.0.0 7fd94d45a000-7fd94d45b000 r--p 0003d000 08:02 14164462 /usr/lib/x86_64-linux-gnu/libgssapi.so.3.0.0 7fd94d45b000-7fd94d45d000 rw-p 0003e000 08:02 14164462 /usr/lib/x86_64-linux-gnu/libgssapi.so.3.0.0 7fd94d45d000-7fd94d45e000 rw-p 00000000 00:00 0 7fd94d45e000-7fd94d477000 r-xp 00000000 08:02 14164963 /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25 7fd94d477000-7fd94d677000 ---p 00019000 08:02 14164963 /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25 7fd94d677000-7fd94d678000 r--p 00019000 08:02 14164963 /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25 7fd94d678000-7fd94d679000 rw-p 0001a000 08:02 14164963 /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25 7fd94d679000-7fd94d683000 r-xp 00000000 08:02 14164637 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1 7fd94d683000-7fd94d882000 ---p 0000a000 08:02 14164637 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1 7fd94d882000-7fd94d883000 r--p 00009000 08:02 14164637 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1 7fd94d883000-7fd94d884000 rw-p 0000a000 08:02 14164637 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1 7fd94d884000-7fd94d887000 r-xp 00000000 08:02 4460940 /lib/x86_64-linux-gnu/libcom_err.so.2.1 7fd94d887000-7fd94da86000 ---p 00003000 08:02 4460940 /lib/x86_64-linux-gnu/libcom_err.so.2.1 7fd94da86000-7fd94da87000 r--p 00002000 08:02 4460940 /lib/x86_64-linux-gnu/libcom_err.so.2.1 7fd94da87000-7fd94da88000 rw-p 00003000 08:02 4460940 /lib/x86_64-linux-gnu/libcom_err.so.2.1 7fd94da88000-7fd94dab4000 r-xp 00000000 08:02 14164629 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1 7fd94dab4000-7fd94dcb3000 ---p 0002c000 08:02 14164629 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1 7fd94dcb3000-7fd94dcb5000 r--p 0002b000 08:02 14164629 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1 7fd94dcb5000-7fd94dcb6000 rw-p 0002d000 08:02 14164629 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1 7fd94dcb6000-7fd94dcb7000 rw-p 00000000 00:00 0 7fd94dcb7000-7fd94dd7a000 r-xp 00000000 08:02 14164635 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3 7fd94dd7a000-7fd94df7a000 ---p 000c3000 08:02 14164635 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3 7fd94df7a000-7fd94df87000 r--p 000c3000 08:02 14164635 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3 7fd94df87000-7fd94df89000 rw-p 000d0000 08:02 14164635 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3 7fd94df89000-7fd94df9a000 r-xp 00000000 08:02 14165035 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1 7fd94df9a000-7fd94e19a000 ---p 00011000 08:02 14165035 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1 7fd94e19a000-7fd94e19b000 r--p 00011000 08:02 14165035 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1 7fd94e19b000-7fd94e19c000 rw-p 00012000 08:02 14165035 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1 7fd94e19c000-7fd94e1f5000 r-xp 00000000 08:02 14155987 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.1.0 7fd94e1f5000-7fd94e3f4000 ---p 00059000 08:02 14155987 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.1.0 7fd94e3f4000-7fd94e3fe000 r--p 00058000 08:02 14155987 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.1.0 7fd94e3fe000-7fd94e400000 rw-p 00062000 08:02 14155987 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.1.0 7fd94e400000-7fd94e47f000 r-xp 00000000 08:02 14164407 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7fd94e47f000-7fd94e67e000 ---p 0007f000 08:02 14164407 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7fd94e67e000-7fd94e67f000 r--p 0007e000 08:02 14164407 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7fd94e67f000-7fd94e680000 rw-p 0007f000 08:02 14164407 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7fd94e680000-7fd94e6b2000 r-xp 00000000 08:02 14164543 /usr/lib/x86_64-linux-gnu/libhogweed.so.4.2 7fd94e6b2000-7fd94e8b1000 ---p 00032000 08:02 14164543 /usr/lib/x86_64-linux-gnu/libhogweed.so.4.2 7fd94e8b1000-7fd94e8b2000 r--p 00031000 08:02 14164543 /usr/lib/x86_64-linux-gnu/libhogweed.so.4.2 7fd94e8b2000-7fd94e8b3000 rw-p 00032000 08:02 14164543 /usr/lib/x86_64-linux-gnu/libhogweed.so.4.2 7fd94e8b3000-7fd94e8cb000 r-xp 00000000 08:02 4461077 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fd94e8cb000-7fd94eaca000 ---p 00018000 08:02 4461077 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fd94eaca000-7fd94eacb000 r--p 00017000 08:02 4461077 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fd94eacb000-7fd94eacc000 rw-p 00018000 08:02 4461077 /lib/x86_64-linux-gnu/libpthread-2.23.so 7fd94eacc000-7fd94ead0000 rw-p 00000000 00:00 0 7fd94ead0000-7fd94eae9000 r-xp 00000000 08:02 4461122 /lib/x86_64-linux-gnu/libz.so.1.2.8 7fd94eae9000-7fd94ece8000 ---p 00019000 08:02 4461122 /lib/x86_64-linux-gnu/libz.so.1.2.8 7fd94ece8000-7fd94ece9000 r--p 00018000 08:02 4461122 /lib/x86_64-linux-gnu/libz.so.1.2.8 7fd94ece9000-7fd94ecea000 rw-p 00019000 08:02 4461122 /lib/x86_64-linux-gnu/libz.so.1.2.8 7fd94ecea000-7fd94ed37000 r-xp 00000000 08:02 14164648 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5 7fd94ed37000-7fd94ef36000 ---p 0004d000 08:02 14164648 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5 7fd94ef36000-7fd94ef38000 r--p 0004c000 08:02 14164648 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5 7fd94ef38000-7fd94ef39000 rw-p 0004e000 08:02 14164648 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5 7fd94ef39000-7fd94ef3b000 rw-p 00000000 00:00 0 7fd94ef3b000-7fd94ef48000 r-xp 00000000 08:02 14164643 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5 7fd94ef48000-7fd94f148000 ---p 0000d000 08:02 14164643 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5 7fd94f148000-7fd94f149000 r--p 0000d000 08:02 14164643 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5 7fd94f149000-7fd94f14a000 rw-p 0000e000 08:02 14164643 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5 7fd94f14a000-7fd94f191000 r-xp 00000000 08:02 14164464 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2 7fd94f191000-7fd94f390000 ---p 00047000 08:02 14164464 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2 7fd94f390000-7fd94f392000 r--p 00046000 08:02 14164464 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2 7fd94f392000-7fd94f394000 rw-p 00048000 08:02 14164464 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2 7fd94f394000-7fd94f4b7000 r-xp 00000000 08:02 14164425 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.6.2 7fd94f4b7000-7fd94f6b6000 ---p 00123000 08:02 14164425 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.6.2 7fd94f6b6000-7fd94f6c1000 r--p 00122000 08:02 14164425 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.6.2 7fd94f6c1000-7fd94f6c3000 rw-p 0012d000 08:02 14164425 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.6.2 7fd94f6c3000-7fd94f6c4000 rw-p 00000000 00:00 0 7fd94f6c4000-7fd94f6f8000 r-xp 00000000 08:02 14164753 /usr/lib/x86_64-linux-gnu/libnettle.so.6.2 7fd94f6f8000-7fd94f8f7000 ---p 00034000 08:02 14164753 /usr/lib/x86_64-linux-gnu/libnettle.so.6.2 7fd94f8f7000-7fd94f8f9000 r--p 00033000 08:02 14164753 /usr/lib/x86_64-linux-gnu/libnettle.so.6.2 7fd94f8f9000-7fd94f8fa000 rw-p 00035000 08:02 14164753 /usr/lib/x86_64-linux-gnu/libnettle.so.6.2 7fd94f8fa000-7fd94f915000 r-xp 00000000 08:02 14164944 /usr/lib/x86_64-linux-gnu/librtmp.so.1 7fd94f915000-7fd94fb14000 ---p 0001b000 08:02 14164944 /usr/lib/x86_64-linux-gnu/librtmp.so.1 7fd94fb14000-7fd94fb15000 r--p 0001a000 08:02 14164944 /usr/lib/x86_64-linux-gnu/librtmp.so.1 7fd94fb15000-7fd94fb16000 rw-p 0001b000 08:02 14164944 /usr/lib/x86_64-linux-gnu/librtmp.so.1 7fd94fb16000-7fd94fb47000 r-xp 00000000 08:02 14156253 /usr/lib/x86_64-linux-gnu/libidn.so.11.6.15 7fd94fb47000-7fd94fd47000 ---p 00031000 08:02 14156253 /usr/lib/x86_64-linux-gnu/libidn.so.11.6.15 7fd94fd47000-7fd94fd48000 r--p 00031000 08:02 14156253 /usr/lib/x86_64-linux-gnu/libidn.so.11.6.15 7fd94fd48000-7fd94fd49000 rw-p 00032000 08:02 14156253 /usr/lib/x86_64-linux-gnu/libidn.so.11.6.15 7fd94fd49000-7fd94ff09000 r-xp 00000000 08:02 4460931 /lib/x86_64-linux-gnu/libc-2.23.so 7fd94ff09000-7fd950108000 ---p 001c0000 08:02 4460931 /lib/x86_64-linux-gnu/libc-2.23.so 7fd950108000-7fd95010c000 r--p 001bf000 08:02 4460931 /lib/x86_64-linux-gnu/libc-2.23.so 7fd95010c000-7fd95010e000 rw-p 001c3000 08:02 4460931 /lib/x86_64-linux-gnu/libc-2.23.so 7fd95010e000-7fd950112000 rw-p 00000000 00:00 0 7fd950112000-7fd950129000 r-xp 00000000 08:02 4461083 /lib/x86_64-linux-gnu/libresolv-2.23.so 7fd950129000-7fd950329000 ---p 00017000 08:02 4461083 /lib/x86_64-linux-gnu/libresolv-2.23.so 7fd950329000-7fd95032a000 r--p 00017000 08:02 4461083 /lib/x86_64-linux-gnu/libresolv-2.23.so 7fd95032a000-7fd95032b000 rw-p 00018000 08:02 4461083 /lib/x86_64-linux-gnu/libresolv-2.23.so 7fd95032b000-7fd95032d000 rw-p 00000000 00:00 0 7fd95032d000-7fd950330000 r-xp 00000000 08:02 4460955 /lib/x86_64-linux-gnu/libdl-2.23.so 7fd950330000-7fd95052f000 ---p 00003000 08:02 4460955 /lib/x86_64-linux-gnu/libdl-2.23.so 7fd95052f000-7fd950530000 r--p 00002000 08:02 4460955 /lib/x86_64-linux-gnu/libdl-2.23.so 7fd950530000-7fd950531000 rw-p 00003000 08:02 4460955 /lib/x86_64-linux-gnu/libdl-2.23.so 7fd950531000-7fd95059a000 r-xp 00000000 08:02 14166919 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.4.0 7fd95059a000-7fd95079a000 ---p 00069000 08:02 14166919 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.4.0 7fd95079a000-7fd95079d000 r--p 00069000 08:02 14166919 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.4.0 7fd95079d000-7fd95079e000 rw-p 0006c000 08:02 14166919 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.4.0 7fd95079e000-7fd9507c4000 r-xp 00000000 08:02 4460903 /lib/x86_64-linux-gnu/ld-2.23.so 7fd9508f1000-7fd950992000 rw-s 00000000 00:05 35684393 /SYSV6c020209 (deleted) 7fd950992000-7fd9509a3000 rw-p 00000000 00:00 0 7fd9509c0000-7fd9509c1000 rw-p 00000000 00:00 0 7fd9509c1000-7fd9509c3000 rw-p 00000000 00:00 0 7fd9509c3000-7fd9509c4000 r--p 00025000 08:02 4460903 /lib/x86_64-linux-gnu/ld-2.23.so 7fd9509c4000-7fd9509c5000 rw-p 00026000 08:02 4460903 /lib/x86_64-linux-gnu/ld-2.23.so 7fd9509c5000-7fd9509c6000 rw-p 00000000 00:00 0 7ffdceab2000-7ffdcead3000 rw-p 00000000 00:00 0 [stack] 7ffdceb43000-7ffdceb45000 r--p 00000000 00:00 0 [vvar] 7ffdceb45000-7ffdceb47000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] 23302:20170117:115534.330 One child process died (PID:23305,exitcode/signal:6). Exiting ... zabbix_agentd [23302]: Error waiting for process with PID 23305: [10] No child processes 23302:20170117:115534.330 Zabbix Agent stopped. Zabbix 3.3.0 (revision {ZABBIX_REVISION}). vjaceslavs Sorry, I missed the fact that zbx_free alters the value of the pointer. All bugs produced are not intended (even if it seems so), but thanks for advice to make code without bugs. As for simplicity, this solution is the simplest way to get output when errors occur. RESOLVED in r65131. vso REOPENED, there is memory leak if zbx_execute is called multiple times with same pointer. ==27414== 131,072 bytes in 1 blocks are definitely lost in loss record 25 of 26 ==27414== at 0x4C2FD5F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==27414== by 0x4317FA: zbx_realloc2 (misc.c:499) ==27414== by 0x4353FF: zbx_strncpy_alloc (str.c:312) ==27414== by 0x43ECA5: zbx_execute (execute.c:426) ==27414== by 0x41E9EE: SYSTEM_SW_PACKAGES (software.c:226) ==27414== by 0x4171CB: process (sysinfo.c:641) ==27414== by 0x413AEC: process_listener (listener.c:58) ==27414== by 0x413AEC: listener_thread (listener.c:145) ==27414== by 0x42B184: zbx_thread_start (threads.c:128) ==27414== by 0x416372: MAIN_ZABBIX_ENTRY (zabbix_agentd.c:966) ==27414== by 0x42BEA2: daemon_start (daemon.c:392) ==27414== by 0x40BE1F: main (zabbix_agentd.c:1203) vjaceslavs Restored previous logic when free is applied to the param value. RESOLVED in r65132 vso CLOSED with small style fixes in r65133 |
Comment by Vladislavs Sokurenko [ 2017 Jan 17 ] |
(10) IPMI will no be possible to execute on server if not current server target is specified. if (ZBX_SCRIPT_EXECUTE_ON_SERVER != script.execute_on) { host.tls_connect = (unsigned char)atoi(row[12]); #ifdef HAVE_OPENIPMI host.ipmi_authtype = (signed char)atoi(row[13]); host.ipmi_privilege = (unsigned char)atoi(row[14]); strscpy(host.ipmi_username, row[15]); strscpy(host.ipmi_password, row[16]); #endif #if defined(HAVE_POLARSSL) || defined(HAVE_GNUTLS) || defined(HAVE_OPENSSL) strscpy(host.tls_issuer, row[13 + ZBX_IPMI_FIELDS_NUM]); strscpy(host.tls_subject, row[14 + ZBX_IPMI_FIELDS_NUM]); strscpy(host.tls_psk_identity, row[15 + ZBX_IPMI_FIELDS_NUM]); strscpy(host.tls_psk, row[16 + ZBX_IPMI_FIELDS_NUM]); #endif vjaceslavs Check is valid. script.execute_on is initialized only for custom script. vso CLOSED, yes you are right. |
Comment by Vladislavs Sokurenko [ 2017 Jan 17 ] |
(11) [F][S] Appropriate message for scripts executed on agent shall be added. Currently message is "Ran": Decision shall be made on how it must look. vso It was decided: vjaceslavs Reverted to single status for execution with or without checks RESOLVED in r65163 vso CLOSED, with small style fix in r65165 |
Comment by Vladislavs Sokurenko [ 2017 Jan 19 ] |
(12) zbx_execute release previously allocated resources only in the end, while not using those, this is not very effective. Before Now: vjaceslavs RESOLVED in r65175 vso CLOSED |
Comment by Vladislavs Sokurenko [ 2017 Jan 19 ] |
Successfully tested |
Comment by Vladislavs Sokurenko [ 2017 Jan 19 ] |
(13) [D] This need to be very well documented, especially in upgrade notes. vso CLOSED as it was done under (15) |
Comment by Vjaceslavs Bogdanovs [ 2017 Jan 19 ] |
Available in pre-3.3.0 (trunk) r65179. |
Comment by Vladislavs Sokurenko [ 2017 Jan 19 ] |
(14) [S] Errors that show up in frontend must start with a capital letter and end with period. vjaceslavs Should we change all existing errors (introduced in and before this solution) and output of the scripts to this format? If so, there are multiple ways to do it: Should error messages like zbx_waitpid() failed: X be rewritten so they explain what happen in the way users can understand or should they remain the same? Any combination of those is possible, so decision should be made before implementing. vso Only static messages that were introduced, everything else is out of scope of this task. vjaceslavs Maybe I am missing difference on how critical some errors are and why unable to create process [X]: X is critical, but Process terminated unexpectedly. is somehow ok, but |
Comment by Vladimir Silin (Inactive) [ 2017 Jan 24 ] |
(15) [D] Documented in the following documentation pages for version 3.4: vso Isn't "Due to command/script exit code check introduction in Zabbix 3.4 commands and scripts can be executed multiple times if exit code is different from 0" Also for media script it would be good to use such example with exit 0 added. And to mention that exit value other than 0 would mean error. #!/bin/bash to=$1 subject=$2 body=$3 cat <<EOF | mail -s "$subject" "$to" $body EOF exit 0 VSI Thanks for the comment! <dimir> Wouldn't it be better to actually spout error if that occurs:
vso yes I think you are right about $? It's better working example as exit status of last command will be returned. exit 0 just says that user must explicitly define exit code. Maybe original example should stay as no exit is same as exit $? vjaceslavs Thats why I was confused about changes made to existing example. If we want to show how to use exit to define exit code then we could make second example like that: #!/bin/bash if [ -f "/var/messages/target" ]; then # some logic goes here else exit 1 #exit with an error fi VSI Removed "exit 0" entry from the example and mentioned exit code checking basics in the note on Custom alertscripts page. I'd prefer not to complicate description with several examples, especially with additional logic. vjaceslavs I agree that this is a very specific case. I gave this example just to show the idea on how exit X could be used "in real life", but I think that we can leave things simple and stay with the existing example. vso REOPENED, There are some info missing in upgrade notes and what's new, all pages from (16) should be mentioned. This below leaves question, "can be executed" it shall be well define what will happen and how many times and if it's feature or known issue.
It should be confirmed but from code looks like max retries is 3 times, delay in between is 30 seconds, I could not find it documented anywhere. VSI The main idea is to warn users about the fact of possibility of such behavior after upgrade in case of non-0 exit code. I don't see the point to introduce users in upgrade notes with parameters of a mechanism which cannot be configured. Perhaps it should be documented, but elsewhere. Also these parameters are not actually a result or a dependency of the change introduced in this issue, but their effect is, which is mentioned. vso Yes I agree, still REOPENED, upgrade notes have been updated under (16) and looks OK. However what's new does not mention what has been added to (16) in documentation. For example here https://www.zabbix.com/documentation/3.4/manual/web_interface/frontend_sections/administration/scripts?rev=1478764129&do=diff external check items are mentioned in upgrade notes but not it what's new, etc.. I think all new features should be in what's new, please go through (16) pages and double check Also this below should be deleted from what's new because it's nothing for user to care about.
And it's not only place where return code has been added, for example in net.tcp.listen and some other places, probably best to mention that some items that launch commands could also become unsupported. ( if needed, I can provide a list ) VSI What's new updated with:
vso
While what's new
VSI What's new fixed and phrased as vso CLOSED |
Comment by Vladislavs Sokurenko [ 2017 Feb 14 ] |
(16) [D] No mention about return code in:
https://www.zabbix.com/documentation/3.4/manual/config/notifications/media/script VSI Exit code checking and links to whole Command execution page added in:
vso CLOSED |
Comment by richlv [ 2017 Mar 27 ] |
will this also save the failure output somewhere - server logfile, for example ? if yes, that would solve ZBXNEXT-1284 |
Comment by Vjaceslavs Bogdanovs [ 2017 Mar 29 ] |
Error output of command execution is available in frontend and in server log file (LOG_LEVEL_WARNING). |
Comment by richlv [ 2017 Mar 29 ] |
vjaceslavs, that sounds really neat, thank you. |
Comment by dimir [ 2017 Mar 30 ] |
Sub-issues still open: (13) |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Oct 13 ] |
Looks like it caused |
[ZBXNEXT-952] Update of documentation 4.19.10 External checks Created: 2011 Sep 08 Updated: 2012 Apr 10 Resolved: 2012 Apr 10 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Documentation (D) |
Affects Version/s: | 1.8.8 |
Fix Version/s: | None |
Type: | Change Request | Priority: | Trivial |
Reporter: | Marcel Hecko | Assignee: | Alexei Vladishev |
Resolution: | Fixed | Votes: | 0 |
Labels: | externalchecks, items | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
4.19.10 External checks - documentation |
Issue Links: |
|
Description |
Mention the fact in documentation, that external check item type does not accept more than one line of STDOUT - no matter whether Character or Text is being used. |
Comments |
Comment by Rudolfs Kreicbergs [ 2011 Sep 08 ] |
This will be done under |
Comment by Marcel Hecko [ 2011 Sep 08 ] |
I am not sure that tis is the same issue though. This is not about input parameters, but about output of the external script. |
Comment by richlv [ 2011 Sep 09 ] |
it's not strictly the same thing, but it was done in the linked issue. |
Comment by richlv [ 2012 Apr 10 ] |
reopen to change label |
[ZBXNEXT-540] ZBX_NOTSUPPORTED from external scripts Created: 2010 Oct 21 Updated: 2018 Feb 07 |
|
Status: | Open |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Agent (G) |
Affects Version/s: | 1.8.4 |
Fix Version/s: | None |
Type: | New Feature Request | Priority: | Major |
Reporter: | Marcel Hecko | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 6 |
Labels: | documentation, exitcodes, externalchecks, notsupported | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
The zabbix agent native interface provides information whether the key is being supported or not outputting ZBX_NOTSUPOPRTED string to the zabbix server, which then reacts to the information and temporarily disables the key check for that particular host. This funcionality does not seem to be implemented for external checks - keys calling external scripts in externalscripts directory. This is a very nice to have feature. We do have Oracle, Weblogic and LUSTRE fs monitoring implemented in Zabbix, however we would really appreciate to have this feature enabled in zabbix server. |
Comments |
Comment by Aleksandrs Saveljevs [ 2010 Oct 22 ] |
As a workaround, you can make the script output nothing - in that case the external check will be treated as not supported. |
Comment by Marcel Hecko [ 2010 Oct 22 ] |
Great indeed! There is a secion in Zabbix documentation thought, that script should NEVER output nothing. This might be changed as this is a very important information In my case this solves the issue, however ZBX_UNSUPPORTED output recognition would be a benefit in zabbix monitoring infrastructure consistency. Thanks for a great work! |
Comment by Alexei Vladishev [ 2012 Oct 11 ] |
I believe it should be documented and closed. |
Comment by richlv [ 2014 Mar 13 ] |
for the record, external checks and userparams now may return empty values so this workaround probably will not help anymore |
Comment by richlv [ 2015 Mar 13 ] |
a patch suggestion at |
Comment by Filipp Sudanov (Inactive) [ 2015 Mar 13 ] |
Similar for user parameters: ZBXNEXT-152 |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Nov 09 ] |
Exit code check was implemented in This piece of information may be of some interest for watchers. |
[ZBXNEXT-99] support text for externalchecks Created: 2009 Oct 07 Updated: 2011 Sep 09 Resolved: 2011 Sep 09 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | None |
Fix Version/s: | 1.9.6 (beta) |
Type: | New Feature Request | Priority: | Major |
Reporter: | Thomas Mueller | Assignee: | Alexei Vladishev |
Resolution: | Fixed | Votes: | 0 |
Labels: | externalchecks | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
by now only 1 line is supported for external checks. Please allow also multiline-text (log,text type). |
Comments |
Comment by richlv [ 2011 Sep 09 ] |
this is fixed as |
[ZBX-20844] External check times out when Zabbix server is stopped. Created: 2022 Apr 05 Updated: 2024 Apr 10 Resolved: 2022 Apr 21 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | 4.0.39, 5.0.22, 6.0.3, 6.2.0alpha1 |
Fix Version/s: | 4.0.40rc1, 5.0.23rc1, 6.0.4rc1, 6.2.0alpha1, 6.2 (plan) |
Type: | Problem report | Priority: | Trivial |
Reporter: | Kazuo Ito | Assignee: | Vladislavs Sokurenko |
Resolution: | Fixed | Votes: | 0 |
Labels: | externalchecks, signal | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
||||
Team: | Team A | ||||
Team: | Team A | ||||
Sprint: | Sprint 87 (Apr 2022) | ||||
Story Points: | 1 |
Description |
It seems that the read function receives a signal interrupt and is flowing to the timeout route. Steps to reproduce:
Result: 4455:20220405:114213.569 Got signal [signal:15(SIGTERM),sender_pid:4569,sender_uid:0,reason:0]. Exiting ... 4455:20220405:114213.569 zbx_on_exit() called 4467:20220405:114213.569 End of zbx_ipc_service_recv():2 4467:20220405:114213.569 __zbx_zbx_setproctitle() title:'preprocessing manager #1 [terminated]' 4473:20220405:114213.576 __zbx_zbx_setproctitle() title:'timer #1 [terminated]' 4478:20220405:114213.577 __zbx_zbx_setproctitle() title:'history syncer #1 [processed 0 values, 0 triggers in 0.000201 sec, syncing history]' 4478:20220405:114213.577 syncing history data in progress... 4478:20220405:114213.577 syncing history data done 4478:20220405:114213.577 In zbx_sync_history_cache() history_num:0 4478:20220405:114213.577 End of zbx_sync_history_cache() 4478:20220405:114213.577 __zbx_zbx_setproctitle() title:'history syncer #1 [processed 0 values, 0 triggers in 0.000376 sec, idle 1 sec]' 4479:20220405:114213.588 __zbx_zbx_setproctitle() title:'history syncer #2 [processed 0 values, 0 triggers in 0.000197 sec, syncing history]' 4479:20220405:114213.588 In zbx_sync_history_cache() history_num:0 4479:20220405:114213.588 End of zbx_sync_history_cache() 4479:20220405:114213.589 __zbx_zbx_setproctitle() title:'history syncer #2 [processed 0 values, 0 triggers in 0.000296 sec, idle 1 sec]' 4480:20220405:114213.601 __zbx_zbx_setproctitle() title:'history syncer #3 [processed 0 values, 0 triggers in 0.000193 sec, syncing history]' 4480:20220405:114213.601 In zbx_sync_history_cache() history_num:0 4480:20220405:114213.601 End of zbx_sync_history_cache() 4480:20220405:114213.601 __zbx_zbx_setproctitle() title:'history syncer #3 [processed 0 values, 0 triggers in 0.000416 sec, idle 1 sec]' 4481:20220405:114213.611 __zbx_zbx_setproctitle() title:'history syncer #4 [processed 0 values, 0 triggers in 0.000209 sec, syncing history]' 4481:20220405:114213.611 In zbx_sync_history_cache() history_num:0 4481:20220405:114213.611 End of zbx_sync_history_cache() 4481:20220405:114213.611 __zbx_zbx_setproctitle() title:'history syncer #4 [processed 0 values, 0 triggers in 0.000303 sec, idle 1 sec]' 4483:20220405:114213.623 __zbx_zbx_setproctitle() title:'snmp trapper #1 [terminated]' 4492:20220405:114213.624 __zbx_zbx_setproctitle() title:'self-monitoring #1 [terminated]' 4497:20220405:114213.624 In zbx_waitpid() 4516:20220405:114213.625 __zbx_zbx_setproctitle() title:'trapper #1 [terminated]' 4517:20220405:114213.625 __zbx_zbx_setproctitle() title:'trapper #2 [terminated]' 4520:20220405:114213.626 __zbx_zbx_setproctitle() title:'trapper #3 [terminated]' 4521:20220405:114213.626 __zbx_zbx_setproctitle() title:'trapper #4 [terminated]' 4522:20220405:114213.626 __zbx_zbx_setproctitle() title:'trapper #5 [terminated]' 4497:20220405:114213.628 zbx_waitpid() killed by signal 15 4497:20220405:114213.628 End of zbx_waitpid():4560 4497:20220405:114213.628 Failed to execute command "/usr/lib/zabbix/externalscripts/test02.sh 'Zabbix server'": Timeout while executing a shell script. 4497:20220405:114213.628 End of get_value_external():NOTSUPPORTED 4497:20220405:114213.628 Item [Zabbix server:test02.sh[{HOST.HOST}]] error: Timeout while executing a shell script. 4497:20220405:114213.628 End of get_value():NOTSUPPORTED 4497:20220405:114213.629 In zbx_activate_item_host() hostid:10084 itemid:28869 type:10 4497:20220405:114213.629 End of zbx_activate_item_host() 4497:20220405:114213.629 In zbx_preprocess_item_value() 4497:20220405:114213.629 End of zbx_preprocess_item_value() 4497:20220405:114213.629 In zbx_ipc_socket_write() 4497:20220405:114213.629 End of zbx_ipc_socket_write():SUCCEED 4497:20220405:114213.629 End of get_values():1 4497:20220405:114213.629 __zbx_zbx_setproctitle() title:'poller #2 [got 1 values in 4.073290 sec, idle 5 sec]' 4455:20220405:114213.734 In DBconnect() flag:1 4455:20220405:114213.739 End of DBconnect():0 4455:20220405:114213.739 In free_database_cache() 4455:20220405:114213.739 In DCsync_all() 4455:20220405:114213.740 In sync_history_cache_full() history_num:0 4455:20220405:114213.740 End of sync_history_cache_full() 4455:20220405:114213.740 In DCsync_trends() trends_num:0 4455:20220405:114213.740 syncing trend data... 4455:20220405:114213.740 query [txnlev:1] [begin;] 4455:20220405:114213.740 query [txnlev:1] [commit;] 4455:20220405:114213.741 syncing trend data done 4455:20220405:114213.741 End of DCsync_trends() 4455:20220405:114213.741 End of DCsync_all() 4455:20220405:114213.741 End of free_database_cache() 4455:20220405:114213.741 In free_configuration_cache() 4455:20220405:114213.741 End of free_configuration_cache() 4455:20220405:114213.741 In zbx_vc_destroy() 4455:20220405:114213.741 End of zbx_vc_destroy() 4455:20220405:114213.742 In free_selfmon_collector() collector:0x7fe0520c8000 4455:20220405:114213.742 End of free_selfmon_collector() 4455:20220405:114213.742 In zbx_unload_modules() 4455:20220405:114213.742 End of zbx_unload_modules() 4455:20220405:114213.742 Zabbix Server stopped. Zabbix 4.0.39 (revision 2e19ee1c57). |
Comments |
Comment by Vladislavs Sokurenko [ 2022 Apr 21 ] |
Fixed in:
|
[ZBX-12963] Unable to pass $ sign to external check Created: 2017 Oct 30 Updated: 2024 Apr 10 Resolved: 2018 Nov 02 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Frontend (F), Proxy (P), Server (S) |
Affects Version/s: | None |
Fix Version/s: | 4.2 (plan) |
Type: | Problem report | Priority: | Minor |
Reporter: | Vitaly Zhuravlev | Assignee: | Martins Valkovskis |
Resolution: | Fixed | Votes: | 0 |
Labels: | externalchecks | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
||||||||
Team: | Team D | ||||||||
Team: | Team D | ||||||||
Sprint: | Sprint 23, Sprint 24, Sprint 46, Nov 2018 | ||||||||
Story Points: | 1 |
Description |
Unable to pass argument to external check containing literal $ since everything is wrapped in double quotes. Escaping $ doesn't work also since sequence \${code} would become
svn blame svn://svn.zabbix.com/trunk/src/zabbix_server/poller/checks_external.c 49450 wiper param_esc = zbx_dyn_escape_string(param, "\"\\"); 49450 wiper zbx_snprintf_alloc(&cmd, &cmd_alloc, &cmd_offset, " \"%s\"", param_esc); Steps to reproduce: script.sh[login,passwor$d] and file script.sh #!/bin/bash echo $1 $2 Result: login passwor Expected: login passwor$d Suggested zabbix key -> command script.sh[login,passwor$d] -> script.sh 'login' 'passwor$d' script.sh['login','passwor$d'] -> script.sh 'login' 'passwor$d' script.sh["login","passwor$d"] -> script.sh "login" "passwor$d" |
Comments |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Oct 30 ] |
wiper isn't guilty, this logic is since palivoda Do you agree with suggested solution? - glebs.ivanovskis glebs.ivanovskis I have no idea how to fix this without breaking backwards compatibility. |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Nov 01 ] |
This problem partially stems from the fact that we have very permissive item key parameter syntax and poorly thought-through quoting/escaping rules. This does not allow us to introduce "parameter preprocessing options" for escaping shell special characters, ignoring macros, etc. If item key parameters required all strings to be quoted and allowed only numeric values to be unquoted solution for this problem could look like: script.sh[escape_shell_spec_chars("login"), escape_shell_spec_chars("passwor$d")] |
Comment by Sergejs Paskevics [ 2017 Dec 13 ] |
Resolved in svn://svn.zabbix.com/branches/dev/ZBX-12963 |
Comment by Sergejs Paskevics [ 2018 Jan 03 ] |
Implemented in 4.0.0alpha2 (trunk) in r76522. |
Comment by richlv [ 2018 Feb 12 ] |
(1) the what's new entry at https://zabbix.com/documentation/4.0/manual/introduction/whatsnew400 says :
three potential issues here :
it might be worth also changing "wrapped to" to "wrapped in", and maybe changing "sign" to more common "character" or "symbol". martins-v Thanks, richlv for the useful suggestions. The wording has been updated. RESOLVED sasha CLOSED |
[ZBX-12476] PHP UserParameter hangs under PHP-5.3.3 but not PHP >= 5.4 Created: 2017 Aug 05 Updated: 2017 Aug 07 Resolved: 2017 Aug 06 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Agent (G), Proxy (P), Server (S) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Problem report | Priority: | Major |
Reporter: | Jim Dutton | Assignee: | Unassigned |
Resolution: | Won't fix | Votes: | 0 |
Labels: | externalchecks, userparameters | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
CentOS-6.9, three hosts: RHEL-7.3, one host |
Description |
Using simple PHP script as UserParameter, UserParameter=local.php.test,php -f /var/tmp/stdout.tester.php <?php date_default_timezone_set("America/Chicago"); $count=fwrite(STDOUT,strftime("%c")); exit; ?> the test (zabbix_agentd -t local.php.test) hangs under PHP-5.3.3 but works with PHP >=5.4. Significant tail-end portion of strace Zabbix-2.1.18/2.4.8, PHP-5.3.3 alarm(3) = 0 pipe([3, 4]) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6ce1aeda90) = 3215 close(4) = 0 read(3, 0x7ffc3cf7f210, 4095) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_STOPPED, si_pid=3215, si_status=SIGTTOU, si_utime=0, si_stime=0} --- read(3, 0x7ffc3cf7f210, 4095) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL, si_value={int=22, ptr=0x16}} --- rt_sigreturn() = -1 EINTR (Interrupted system call) close(3) = 0 kill(4294964081, SIGTERM) = 0 wait4(3215, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTTOU}], WSTOPPED|WCONTINUED, NULL) = 3215 wait4(3215, ^CProcess 3214 detached <detached ...> [root@newzabbix tmp]# zabbix_agentd [3214]: Warning: Got signal [signal:2(SIGINT),sender_pid:0,sender_uid:0,reason:128]. Exiting ... zabbix_agentd [3214]: Zabbix Agent stopped. Zabbix 2.2.18 (revision 67443). Process hangs and has to be manually terminated (crtl-c). strace of success under Zabbix-2.4.8, PHP >= 5.4 alarm(3) = 0 pipe([3, 4]) = 0 write(1, "local.php.test "..., 45local.php.test ) = 45 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f112fb18a90) = 3708 close(4) = 0 read(3, "Sat Aug 5 00:00:10 2017", 4095) = 24 read(3, "", 4095) = 0 close(3) = 0 wait4(3708, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED|WCONTINUED, NULL) = 3708 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3708, si_status=0, si_utime=0, si_stime=0} --- alarm(0) = 3 write(1, " [t|Sat Aug 5 00:00:10 2017]\n", 30 [t|Sat Aug 5 00:00:10 2017] ) = 30 exit_group(0) = ? +++ exited with 0 +++ |
Comments |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Aug 05 ] |
If you simply run your script from command line, does it work as it should on all PHP versions? |
Comment by Jim Dutton [ 2017 Aug 05 ] |
Yes - execution of the PHP UserParameter script works just fine from the command line as a PHP invocation. The following document fragment for one of my SourceForge projects notes this issue: ========================= 1. install PHP >= 5.4 2. don't use PHP based UserParameter scripts (eg; stick to (Unix) shell scripts) 3. use a “sneaky proxy” by putting the PHP UserParameter script under Apache (HTTPD) with built-in PHP support and using curl to invoke the PHP UserParameter script and successfully process it, such as 1. UserParameter=hw.disk.discovery,/usr/bin/curl --raw --silent http://localhost/zabbix-php/<script filename> = = = = = = = = = = = = = = = = = Apache configuration used: Alias /zabbix-php "/var/www/html/zabbix-php" Two simple PHP scripts to use for testing (“stdout.tester.php”, ”stdout.tester2.php”) <?php <?php Sample result (“local.php.test” => “stdout.tester.php”): zabbix_get -s 127.0.0.1 -k local.php.test ========================= NOTE: this issue with PHP-5.3.3 does not appear to affect the Zabbix "front-end" (web pages). Only the "child process" environment that is created/used for UserParameter scripts. |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Aug 05 ] |
When Zabbix hangs with PHP-5.3.3 is there any hanging or zombie processes related to your script? Zabbix receives SIGCHLD while doing read() meaning that script terminated, but read() does not unblock meaning that file descriptor Zabbix is reading from wasn't closed by all processes having it open. Then finally read() is interrupted by SIGALRM, Zabbix tries to kill() child and blocks in waitpid(). Maybe it's a sort of misbehaviour on PHP side, but Zabbix should definitely be robust enough to handle it. waitpid() must be executed within timeout. |
Comment by Jim Dutton [ 2017 Aug 06 ] |
No zombie processes found. List of running agentd tasks: zabbix 2490 1 0 15:46 ? 00:00:00 /usr/local/sbin/zabbix_agentd zabbix 2491 2490 0 15:46 ? 00:00:01 /usr/local/sbin/zabbix_agentd: collecto r [idle 1 sec] zabbix 2492 2490 0 15:46 ? 00:00:00 /usr/local/sbin/zabbix_agentd: listener #1 [waiting for connection] zabbix 2493 2490 0 15:46 ? 00:00:00 /usr/local/sbin/zabbix_agentd: listener #2 [waiting for connection] zabbix 2494 2490 0 15:46 ? 00:00:00 /usr/local/sbin/zabbix_agentd: listener #3 [waiting for connection] zabbix 2495 2490 0 15:46 ? 00:00:01 /usr/local/sbin/zabbix_agentd: active c hecks #1 [idle 1 sec] postfix 3460 1964 0 17:21 ? 00:00:00 pickup -l -t fifo -u root 3512 2405 0 17:29 pts/1 00:00:00 vi zabbix_agentd.conf root 3523 2403 0 17:30 pts/0 00:00:00 zabbix_agentd -t local.php.test root 3524 3523 0 17:30 pts/0 00:00:00 /usr/bin/php -f /var/tmp/stdout.tester. php ===================================== top (partial) output top - 17:49:58 up 2:09, 4 users, load average: 0.08, 0.07, 0.02 Tasks: 163 total, 1 running, 161 sleeping, 1 stopped, 0 zombie Cpu(s): 0.7%us, 0.4%sy, 0.0%ni, 98.5%id, 0.4%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 1020052k total, 895756k used, 124296k free, 50088k buffers Swap: 2064380k total, 8k used, 2064372k free, 237096k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7 root 20 0 0 0 0 S 1.8 0.0 0:02.79 events/0 2366 root 20 0 292m 13m 9912 S 1.8 1.3 0:00.97 gnome-terminal 2491 zabbix 20 0 78620 1096 592 S 1.8 0.1 0:01.93 zabbix_agentd 3997 root 20 0 17072 1140 828 R 1.8 0.1 0:00.04 top 1 root 20 0 21388 1556 1236 S 0.0 0.2 0:00.75 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 4 root 20 0 0 0 0 S 0.0 0.0 0:00.33 ksoftirqd/0 5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 stopper/0 6 root RT 0 0 0 0 S 0.0 0.0 0:00.04 watchdog/0 ===================================== Terminal output from "stalled" agent task [root@centos62b ~]# zabbix_agentd -t local.php.test local.php.test [cursor] Other agentd tasks are periodically running |
Comment by Jim Dutton [ 2017 Aug 06 ] |
Hung agentd task finally times out zabbix_agentd -t local.php.test local.php.test [m|ZBX_NOTSUPPORTED] [Timeout while executing a shell script.] |
Comment by Jim Dutton [ 2017 Aug 06 ] |
Running the same script with the same version of Zabbix on the same client machine BUT |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Aug 06 ] |
Hm, if Zabbix times out, then everything on Zabbix side works as expected, doesn't it? I would recommend to look for solution of PHP problem on our forum or IRC channel. Maybe it's even more PHP-related, then Zabbix-related. Or a weird selinux issue... Closing as Won't Fix. |
Comment by Jim Dutton [ 2017 Aug 07 ] |
I have already established two resolutions: a) upgrade php to >= v5.4, b) run php UserParameter scripts under Apache (HTTPD), via "curl", using its php module to execute the PHP UserParameter script(s). What would really be helpful for all is to update Zabbix Manual UserParameter sections to indicate the possibility of problems/issues if the PHP invoked by zabbix_agentd is version 5.3.3 and recommending installing PHP >= v5.4. This would allow other Zabbix implementers to make an informative decision about using PHP for Zabbix UserParameter scripts. It would also expand the scope of "external programs" possibly used with/by Zabbix. |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Aug 07 ] |
I'm not sure there is a suitable place in official Zabbix documentation (and the use case seems a bit too specific, we try to keep docs short and focused) but you are welcome to share your findings on zabbix.org |
[ZBX-9701] Special character $ doesn't pass in external check parameter Created: 2015 Jul 13 Updated: 2017 Oct 24 Resolved: 2017 Oct 24 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | 2.4.1 |
Fix Version/s: | None |
Type: | Problem report | Priority: | Trivial |
Reporter: | Dmitry Gorobets | Assignee: | Unassigned |
Resolution: | Duplicate | Votes: | 3 |
Labels: | escaping, externalchecks | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
Zabbix doesn't pass character $ in external check parameter, example: quartz_scheduler_check1.py["-n","cluster-app1","-j","ReceiveMailTask$4","-t","c2c23f92-e4a5-4ed4-8dce-8fb1b55e198b"], result - ['-n', 'cluster-app1', '-j', 'ReceiveMailTask', '-t', 'c2c23f92-e4a5-4ed4-8dce-8fb1b55e198b'] If add backslash() to escape: quartz_scheduler_check1.py["-n","cluster-app1","-j","ReceiveMailTask\$4","-t","c2c23f92-e4a5-4ed4-8dce-8fb1b55e198b"] We'll get ['-n', 'cluster-app1', '-j', 'ReceiveMailTask\\', '-t', 'c2c23f92-e4a5-4ed4-8dce-8fb1b55e198b'] |
Comments |
Comment by Aleksandrs Saveljevs [ 2015 Jul 13 ] |
The "$" character is passed, but external checks are executed through the shell and so "$" is treated as the beginning of a shell variable. It should probably be solved in a way similar to |
Comment by Dmitry Gorobets [ 2015 Jul 13 ] |
I tried to solve problem with single quotes, but it didn't help. |
Comment by Aleksandrs Saveljevs [ 2015 Jul 13 ] |
Above I meant that the server should single-quote the arguments instead of double-quoting them at src/zabbix_server/poller/checks_external.c, function get_value_external(). In other words, you are correct that there is a bug in Zabbix. |
Comment by Dmitry Gorobets [ 2015 Jul 13 ] |
Zabbix version 2.4.1 (revision 49643) |
Comment by Dmitry Gorobets [ 2015 Jul 15 ] |
Bug can be fixed by editing line 88 at src/zabbix_server/poller/checks_external.c checks_external.c
zbx_snprintf_alloc(&cmd, &cmd_alloc, &cmd_offset, " \"%s\"", param_esc);
to checks_external.c
zbx_snprintf_alloc(&cmd, &cmd_alloc, &cmd_offset, " '%s'", param_esc);
|
Comment by Aleksandrs Saveljevs [ 2015 Jul 16 ] |
Just a note that the patch above does solve the reporter's case, but will generally make things much worse: external items with parameters containing double quotes, backslashes and especially single quotes will no longer work. |
Comment by Tom M. [ 2015 Oct 19 ] |
The same issue is present in the 2.2 release (as seen on zabbix-server-2.2.10-1.el6.x86_64). |
Comment by Glebs Ivanovskis (Inactive) [ 2017 Oct 24 ] |
Closing as Duplicate of |
[ZBX-9433] Proxy - External checks documentation clarification Created: 2015 Mar 25 Updated: 2017 May 30 Resolved: 2015 Apr 23 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Documentation (D) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Incident report | Priority: | Minor |
Reporter: | Chris Christensen | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Labels: | externalchecks | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
On the External checks documentation page: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/external There is a warning:
What does this actually mean? Why will overuse decrease performance? |
Comments |
Comment by Martins Valkovskis [ 2015 Apr 08 ] |
Explained in more detail now: https://www.zabbix.com/documentation/2.2/manual/config/items/itemtypes/external RESOLVED. sasha CLOSED |
[ZBX-9095] Ruby script sometimes fails as External check Created: 2014 Dec 01 Updated: 2017 May 30 Resolved: 2014 Dec 20 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | 2.2.7, 2.4.2 |
Fix Version/s: | None |
Type: | Incident report | Priority: | Blocker |
Reporter: | Alexey Pustovalov | Assignee: | Unassigned |
Resolution: | Won't fix | Votes: | 0 |
Labels: | externalchecks, scripts | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
Ruby script as external script. |
Description |
Sometimes Ruby script fails because of FD = 0 (stdin) is closed by Zabbix server/proxy before script execution. The problem is described in https://redmine.ruby-lang.org/issues/5723 issue: [BUG] rb_update_max_fd: invalid fd (0) given. ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux] -- Control frame information ----------------------------------------------- c:0001 p:---- s:0002 b:0002 l:000001 d:000001 TOP -- C level backtrace information ------------------------------------------- -e [0x8173762] -e [0x81b7de8] -e(rb_bug+0x35) [0x81b7e85] -e [0x8073427] -e [0x8079be0] -e [0x806da5a] -e(ruby_init+0x97) [0x805b317] -e [0x8058887] /lib/libc.so.6(__libc_start_main+0xdc) [0x3cedec] -e [0x8058781] -- Other runtime information ----------------------------------------------- 0: can't convert false into String (TypeError) The trace above is stored as item value. Zabbix closed FD = 0 to decrease usage of files and avoid situations when max opened files option are reached. I suppose we need to document that Zabbix can use huge amount of opened FDs (files). |
Comments |
Comment by Igors Homjakovs (Inactive) [ 2014 Dec 16 ] |
At startup Zabbix server closes STDIN and then redirects it to /dev/null: const char default_file[] = "/dev/null"; close(STDIN_FILENO); open(default_file, O_RDONLY); /* stdin, normally fd==0 */ The file descriptor you are mentioning (FD = 0), is closed by "close(fd[0]);" when external script is being executed. However, this descriptor is the read end of a pipe and it is not related to STDIN. Therefore, it this situation there is no fault with Zabbix. In https://redmine.ruby-lang.org/issues/5723 it is mentioned that this is a known Ruby issue for which the work-around has been added in the new Ruby version. |
Comment by Alexander Vladishev [ 2014 Dec 20 ] |
I close the issue. |
[ZBX-6894] Server/Proxy behavior for stucked external checks Created: 2013 Aug 14 Updated: 2017 May 30 Resolved: 2015 May 19 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Documentation (D) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Incident report | Priority: | Trivial |
Reporter: | Iskra Zabbix | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Labels: | externalchecks, timeout | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
It is documented (https://www.zabbix.com/documentation/2.0/manual/appendix/config/zabbix_server and similar for proxy), that Timeout settings affects external checks, as well as SNMP or simple checks. But it is not clear, what happens after Timeout expires. My quick look in checks_external.c/execute.c points out that forked process and all it childrens are killed after Timeout. Correct me if I wrong. Anyway, it is worth to explicitly document de-facto behavior in "External checks" chapter. |
Comments |
Comment by Martins Valkovskis [ 2015 Apr 15 ] |
Added to documentation at https://www.zabbix.com/documentation/2.0/manual/config/items/itemtypes/external (also other versions): "In case of a timeout, the item will be marked as unsupported, an according error message will be displayed and the forked process for the script will be killed." RESOLVED. sasha CLOSED |
[ZBX-5697] Can not use end square bracket in external check params Created: 2012 Oct 16 Updated: 2017 May 30 Resolved: 2012 Oct 18 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Server (S) |
Affects Version/s: | 1.8.16rc1 |
Fix Version/s: | 1.8.16rc1 |
Type: | Incident report | Priority: | Major |
Reporter: | Alexey Pustovalov | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Labels: | externalchecks, patch | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | square_brackets_in_external_checks.patch | ||||
Issue Links: |
|
Description |
For example, item key is external["test","dads","dasdas","da[aa]asd"]: Zabbix server cuts the last argument. The problem occurs only on Zabbix 1.8! |
Comments |
Comment by Alexander Vladishev [ 2012 Oct 18 ] |
Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-5697 |
Comment by Andris Mednis [ 2012 Oct 19 ] |
Successfully tested. Please review comment improvements in r30976. |
Comment by Alexander Vladishev [ 2012 Oct 19 ] |
Fixed in version pre-1.8.16 r30986. |
[ZBX-5464] zabbix can't get 0 from external script Created: 2012 Aug 17 Updated: 2017 May 30 Resolved: 2013 Feb 14 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Server (S) |
Affects Version/s: | 2.0.2 |
Fix Version/s: | None |
Type: | Incident report | Priority: | Trivial |
Reporter: | sles | Assignee: | Unassigned |
Resolution: | Cannot Reproduce | Votes: | 0 |
Labels: | externalchecks | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
Centos 6.3/x86-64 |
Attachments: | 26052.tmp |
Description |
If external script returns 0 then I see in zabbix server log: 19516:20120817:093623.552 item [Lud-cr2801-1:pingloss.sh[-c 20, -q, -B1, -r1, -b1500, {HOST.CONN}]] became not supported: Received value [0]is not suitable for value type [Numeric (float)] If script returns 0.0 all is OK: 19516:20120817:095325.202 item [Lud-cr2801-1:pingloss.sh[-c 20, -q, -B1, -r1, -b1500, {HOST.CONN} ]] became supported I think this is wrong. |
Comments |
Comment by sles [ 2012 Aug 17 ] |
Oops! ]] became not supported: Received value [0.0 real situation is worse |
Comment by Alexander Vladishev [ 2012 Aug 21 ] |
Zabbix doesn't log CR and LF characters in the message "Received value [....". Possibly your script returns an empty line(s) before a value. Please reopen the issue if it not so. |
Comment by sles [ 2012 Aug 21 ] |
not so [root@zabbix externalscripts]# ./pingloss.sh -c 20 -q -B1 -r1 -b1500 192.168.22.220 |
Comment by sles [ 2012 Aug 21 ] |
not so |
Comment by Alexei Vladishev [ 2012 Aug 29 ] |
Please attach pingloss.sh here if possible. Thanks. |
Comment by sles [ 2012 Sep 10 ] |
Here it is: #!/bin/sh fping $* 2>&1 | awk '{ print $5 } ' | awk -F "/" ' { print $3 }' | awk -F "%" '{if ($1 == 0) { print "0.0"}else {print $1}}' Thank you! |
Comment by Andris Zeila [ 2013 Feb 05 ] |
For me the following script works fine: #!/bin/sh fping -c 1 -q -B1 -r1 -b1500 $@ 2>&1 | awk '{ print $5 }' | awk -F "/" '{ print $3 }' | awk -F "%" '{print $1}' It returns 0 which is read by server without problems. I checked the code - the decimal mark is not required for floating values. |
Comment by sles [ 2013 Feb 06 ] |
checked logs- 705:20130206:061256.677 item [Lud-cr2801-1:pingloss.sh[-c 20, -q, -B1, -r1, -b1500, {HOST.CONN}]] became not supported: Received value [0.0 |
Comment by Andris Zeila [ 2013 Feb 06 ] |
One question - is there really line feed character in the logs, or it was just inserted during copying this line? And another thing - could you pleas instead of copying pingloss.sh script output redirect to file and attach it here? |
Comment by sles [ 2013 Feb 08 ] |
Really it looks like: Received value [0.0] is not suitable so no line feed or carriage return here |
Comment by sles [ 2013 Feb 08 ] |
well, you are right, there is additional symbol at the end. |
Comment by Andris Zeila [ 2013 Feb 08 ] |
Yes, strange. LF/CR characters at the end should have been stripped by server. |
Comment by sles [ 2013 Feb 12 ] |
I changed script to just and there is no such problem ( at least I can't reproduce it), I guess script returns non-digit values in some situations and zabbix info about 0.0 in log is wrong, i.e. real bug is what zabbix writes to log |
Comment by Andris Zeila [ 2013 Feb 12 ] |
There is a potential problem if fping produces multiple lines of output (although I can't imagine how that could happen with this example, but maybe occasionally there could be some error or whatever message). In that case if the first line contains less than 5 fields, then the script would give output; Parser would fail because of the first empty line, but logger would strip the empty lines from message. This would lead to failed items with visually correct values in log files. So the suggestion would be to ensure that your script produces only single line of output (with head or tail for example). |
Comment by richlv [ 2013 Feb 12 ] |
should parser strip leading whitespace, too ? |
Comment by sles [ 2013 Feb 14 ] |
Hello! I added tail -n 1 to script, now I can't reproduce problem. |
Comment by Andris Zeila [ 2013 Feb 14 ] |
Great. Then I'm closing this one. |
[ZBX-5397] Macros {HOST.IP} doesn't work in External check Created: 2012 Aug 01 Updated: 2017 May 30 Resolved: 2012 Aug 03 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Documentation (D) |
Affects Version/s: | 2.0.2 |
Fix Version/s: | 2.0.3rc1, 2.1.0 |
Type: | Incident report | Priority: | Major |
Reporter: | Александр Новосёлов | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Labels: | externalchecks, macros | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | 2012-08-01.png |
Description |
{HOST.IP}
doesn't work in External check If add Agent interfaces - all fine. Why Agent interfaces on snmp only device? Russian forum http://www.zabbix.com/forum/showthread.php?t=27676 |
Comments |
Comment by richlv [ 2012 Aug 01 ] |
this should be already fixed for 2.0.2 with |
Comment by Александр Новосёлов [ 2012 Aug 01 ] |
Yes, in global scripts [ZBX 4976] fix problem. This problem - doesn't work in External check is not a global script. I reopen |
Comment by Александр Новосёлов [ 2012 Aug 01 ] |
This problem - doesn't work in External check is not a global script. |
Comment by richlv [ 2012 Aug 01 ] |
ok, so most likely the issue is with documentation |
Comment by richlv [ 2012 Aug 01 ] |
documented in http://www.zabbix.com/documentation/2.0/manual/appendix/macros/supported_by_location |
Comment by Александр Новосёлов [ 2012 Aug 01 ] |
Yes, when you add the Agent interface, everything works. But why should manually add the interface to the host anenta - which just is not an agent, and is used only snmp? |
Comment by richlv [ 2012 Aug 01 ] |
no, not adding agent interface - make sure snmp interface is selected for the external check in item properties |
Comment by Александр Новосёлов [ 2012 Aug 01 ] |
attach screenshot |
Comment by richlv [ 2012 Aug 01 ] |
indeed, external check HOST.IP macro resolution does not seem to take ip from the selected interface... |
Comment by Alexander Vladishev [ 2012 Aug 03 ] |
Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-5397 |
Comment by Александр Новосёлов [ 2012 Aug 06 ] |
Zabbix Sources Pre-2.0.3rc1 (stable) 29413 06 Aug, 2012 not fix? Or in the source have not got the change? |
Comment by richlv [ 2012 Aug 07 ] |
the fix is currently only in the development branch, indicated above - it is not yet fully reviewed and merged to the main branches |
Comment by dimir [ 2012 Aug 07 ] |
Successfully tested. Please review my changes in r29435. <Sasha> Great! Thanks. |
Comment by Alexander Vladishev [ 2012 Aug 08 ] |
Fixed in pre-2.0.3rc1 r29444 and pre-2.1.0 (trunk) r29445. |
[ZBX-4803] Error in External Check Upgrade in 2.0rc2 Script for more than 1 parameter Created: 2012 Mar 26 Updated: 2017 May 30 Resolved: 2012 Jun 13 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Server (S) |
Affects Version/s: | 2.0.0rc2 |
Fix Version/s: | None |
Type: | Incident report | Priority: | Minor |
Reporter: | Patrick Hooper | Assignee: | Unassigned |
Resolution: | Won't fix | Votes: | 0 |
Labels: | comma, externalchecks, upgrade | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
debian 6.03, kernel 2.6.32 mysql 5.x |
Description |
During an upgrade from 1.8.2 to 2.0rc2 there was an error in the upgrade scripts for conversion of the external scripts checks. I have checks that have more than 1 parameter for the external check. The upgrade only deals with 0 or 1 parameter. Example. upgrade changed the check to sdidu-nxgen-read-config.php[" {HOST.CONN}",1 "fset txmax"]should be sdidu-nxgen-read-config.php["{HOST.CONN} ",1 ,"fset txmax"] |
Comments |
Comment by Alexander Vladishev [ 2012 Apr 02 ] |
It should be fixed manually. Such action it is almost impossible to make by a SQL script. |
Comment by Oleksii Zagorskyi [ 2012 Apr 02 ] |
Probably a note can be added to the page http://www.zabbix.com/documentation/2.0/manual/installation/upgrade_notes |
Comment by Martins Valkovskis [ 2012 Apr 03 ] |
A note on this added here: http://www.zabbix.com/documentation/2.0/manual/installation/upgrade_notes?&#item_changes |
[ZBX-4098] HOST.CONN macro in external checks loses first character Created: 2011 Sep 01 Updated: 2017 May 30 Resolved: 2011 Sep 07 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Proxy (P), Server (S) |
Affects Version/s: | 1.9.5 (alpha) |
Fix Version/s: | 2.0.0 |
Type: | Incident report | Priority: | Blocker |
Reporter: | richlv | Assignee: | Unassigned |
Resolution: | Won't fix | Votes: | 0 |
Labels: | externalchecks, macros, trivial | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
external check key : test.sh["<${HOST.CONN}>"] host's ip = 127.0.0.1 printing all parameters to a file results in : 127.0.0.1 <27.0.0.1> note that other macros should be checked as well; this might also be present in 1.8 |
Comments |
Comment by Alexander Vladishev [ 2011 Sep 07 ] |
test.sh["<${HOST.CONN}>"] will be converted by Zabbix server to test.sh["<$127.0.0.1>"]. |
[ZBX-3647] keys of external checks do not conform to the item key syntax Created: 2011 Mar 26 Updated: 2017 Oct 30 Resolved: 2011 Sep 09 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Frontend (F), Server (S) |
Affects Version/s: | 1.8.4 |
Fix Version/s: | 1.9.6 (beta), 2.0.0 |
Type: | Problem report | Priority: | Blocker |
Reporter: | Robert Jerzak | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 0 |
Labels: | externalchecks, trivial, usability | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
Description |
edit item, type: external check, key with quotation marks generate: Error in item key: incorrect syntax near '[' example: generates: changing key to: and fix the problem |
Comments |
Comment by richlv [ 2011 Mar 27 ] |
could you please try with 1.8 svn head (or nightly snapshot) ? edit : hmm, actually not. if you are trying to pass two parameters, they should be separated by comma, not space |
Comment by Aleksandrs Saveljevs [ 2011 Mar 28 ] |
Rich is right: homepl.freeid["Auto UNIX" "free"] is not a valid key. See http://www.zabbix.com/documentation/1.8/manual/config/items#item_key for item key syntax. |
Comment by Robert Jerzak [ 2011 Mar 28 ] |
Yes, it's true but this is extermal check and passing parameters to external script should be space separated. |
Comment by Aleksandrs Saveljevs [ 2011 Mar 28 ] |
We should probably make the documentation more clear that item keys for external checks accept only one string argument. We should also modify the server so that it validates the key and passes the first argument to the script, instead of passing everything between "[" and "]". PS: Note that if you wish to pass "Auto UNIX" "free" to your external script, you can use homepl.freeid["\"Auto UNIX\" \"free\""] as the key. EDIT: Actually, disregard the PS. You should be able to write it this way, but currently you cannot, because external check keys do not follow the syntax. Thanks for reopening! |
Comment by richlv [ 2011 Sep 01 ] |
just to clarify, it would be preferred if external check keys fully followed syntax - as in, allowed key[param1,param2,...] |
Comment by Alexander Vladishev [ 2011 Sep 08 ] |
Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-3647 |
Comment by richlv [ 2011 Sep 08 ] |
does the fix change external key parameter format to the one other types have ( key[param1,param2,param3,...] ) ? |
Comment by Rudolfs Kreicbergs [ 2011 Sep 08 ] |
Decided to use the format suggested by Rich - "key[param1,param2,...]". |
Comment by Alexander Vladishev [ 2011 Sep 08 ] |
added multiple parameters for external checks in r21553. |
Comment by richlv [ 2011 Sep 09 ] |
this also solves |
Comment by Alexander Vladishev [ 2011 Sep 09 ] |
Available in version pre1.9.6, r21597. |
[ZBX-2450] no security measures are taken for external checks Created: 2010 May 21 Updated: 2024 Apr 10 Resolved: 2019 Mar 12 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Server (S) |
Affects Version/s: | 1.8.2 |
Fix Version/s: | None |
Type: | Defect (Security) | Priority: | Critical |
Reporter: | Aleksandrs Saveljevs | Assignee: | Andrejs Kozlovs |
Resolution: | Duplicate | Votes: | 2 |
Labels: | externalchecks, security | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
||||||||||||||||||||
Team: | Team A | ||||||||||||||||||||
Team: | Team A | ||||||||||||||||||||
Sprint: | Sprint 50 (Mar 2019) |
Description |
We might wish to do more security checking for external checks, similar to what |
Comments |
Comment by Aleksandrs Saveljevs [ 2017 Aug 25 ] |
Note that even though external checks use a different key format after |