[ZBX-7917] Output of system.uname is different between 2.0 and 2.2 Created: 2014 Mar 08  Updated: 2017 May 30  Resolved: 2014 Mar 28

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Documentation (D)
Affects Version/s: 2.2.2
Fix Version/s: None

Type: Incident report Priority: Minor
Reporter: Volker Fröhlich Assignee: Martins Valkovskis
Resolution: Fixed Votes: 0
Labels: regression, uname
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux; others are probably affected



 Description   

Quoting myself from ZBX-5616:

The results of system.uname are different between the old and the new implementation:

Old: Linux example.com 2.6.32-431.1.2.el6.ppc64 #1 SMP Sun Nov 24 09:36:46 EST 2013 ppc64 ppc64 ppc64 GNU/Linux
New: Linux example.com 2.6.32-431.1.2.el6.ppc64 #1 SMP Sun Nov 24 09:36:46 EST 2013 ppc64

That's equivalent to -i, -p and -o missing from the uname utility, it seems to me. This should be documented or changed.



 Comments   
Comment by Aleksandrs Saveljevs [ 2014 Mar 11 ]

According to sasha, this change was intended. The last three values do not seem to be present in the structure that uname() call returns:

struct utsname {
    char sysname[];    /* Operating system name (e.g., "Linux") */
    char nodename[];   /* Name within "some implementation-defined
                          network" */
    char release[];    /* Operating system release (e.g., "2.6.28") */
    char version[];    /* Operating system version */
    char machine[];    /* Hardware identifier */
#ifdef _GNU_SOURCE
    char domainname[]; /* NIS or YP domain name */
#endif
};

On other operating systems the last three values are not printed either.

So, again, since ZBX-5616 replaces the invocation of uname utility with uname() system call, the change was intended.

Comment by Aleksandrs Saveljevs [ 2014 Mar 28 ]

We have decided to document the change. The following documentation was updated:

martins-v Reviewed, with minor grammar corrections. CLOSED.

Generated at Fri May 16 10:02:01 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.