[ZBX-20740] Server generated CUIDs are shorter on 32bit systems Created: 2022 Mar 14  Updated: 2024 Apr 10  Resolved: 2022 Mar 25

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 6.0.2rc1
Fix Version/s: 6.0.3rc1, 6.2.0alpha1, 6.2 (plan)

Type: Problem report Priority: Trivial
Reporter: Andris Zeila Assignee: Andris Zeila
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GIF File multiple_active_nodes.gif     PNG File screenshot-1.png     File zabbix_server.log    
Team: Team A
Sprint: Sprint 86 (Mar 2022)
Story Points: 0.5

 Description   

When generating CUID server constructs timestamp part without adding padding

gettimeofday(&current_time, NULL);
from_decimal(timestamp, CUID_BASE_36, (size_t)(current_time.tv_sec * 1000 + current_time.tv_usec / 1000));

However on 32 bit systems size_t is only 4 bytes which will cause the timestamp value to wrap around and be shorter, resulting in 24 character CUIDs.

The timestamp value also must be padded so CUIDs have fixed 25 character length.



 Comments   
Comment by Michele Manzani [ 2022 Mar 14 ]

Just deployed the 6.02 version and I stll have the same problem

     7:20220314:161934.500 Starting Zabbix Server. Zabbix 6.0.2 (revision d726a4d).

     7:20220314:161934.500 ****** Enabled features ******

     7:20220314:161934.500 SNMP monitoring:           YES

     7:20220314:161934.500 IPMI monitoring:           YES

     7:20220314:161934.500 Web monitoring:            YES

     7:20220314:161934.500 VMware monitoring:         YES

     7:20220314:161934.500 SMTP authentication:       YES

     7:20220314:161934.500 ODBC:                      YES

     7:20220314:161934.500 SSH support:               YES

     7:20220314:161934.500 IPv6 support:              YES

     7:20220314:161934.500 TLS support:               YES

     7:20220314:161934.500 ******************************

     7:20220314:161934.500 using configuration file: /etc/zabbix/zabbix_server.conf

     7:20220314:161934.670 current database version (mandatory/optional): 06000000/06000000

     7:20220314:161934.670 required mandatory version: 06000000

     7:20220314:161934.718 database could be upgraded to use primary keys in history tables

   175:20220314:161934.816 starting HA manager

   175:20220314:161934.864 HA manager started in active mode

     7:20220314:161934.866 server #0 started [main process]

   176:20220314:161934.867 server #1 started service manager #1

   177:20220314:161934.868 server #2 started configuration syncer #1

   178:20220314:161935.424 server #3 started alert manager #1

   179:20220314:161935.424 server #4 started alerter #1

   180:20220314:161935.426 server #5 started alerter #2

   181:20220314:161935.427 server #6 started alerter #3

   182:20220314:161935.428 server #7 started preprocessing manager #1

   183:20220314:161935.429 server #8 started preprocessing worker #1

   184:20220314:161935.430 server #9 started preprocessing worker #2

   185:20220314:161935.431 server #10 started preprocessing worker #3

   186:20220314:161935.432 server #11 started lld manager #1

   187:20220314:161935.432 server #12 started lld worker #1

   188:20220314:161935.433 server #13 started lld worker #2

   189:20220314:161935.435 server #14 started housekeeper #1

   190:20220314:161935.440 server #15 started timer #1

   191:20220314:161935.441 server #16 started http poller #1

   192:20220314:161935.444 server #17 started discoverer #1

   197:20220314:161935.446 server #22 started escalator #1

   196:20220314:161935.447 server #21 started history syncer #4

   194:20220314:161935.450 server #19 started history syncer #2

   195:20220314:161935.450 server #20 started history syncer #3

   200:20220314:161935.452 server #25 started self-monitoring #1

   204:20220314:161935.453 server #29 started poller #3

   202:20220314:161935.456 server #27 started poller #1

   203:20220314:161935.459 server #28 started poller #2

   193:20220314:161935.460 server #18 started history syncer #1

   201:20220314:161935.473 server #26 started task manager #1

   207:20220314:161935.474 server #32 started unreachable poller #1

   199:20220314:161935.475 server #24 started proxy poller #1

   198:20220314:161935.479 server #23 started snmp trapper #1

   205:20220314:161935.480 server #30 started poller #4

   206:20220314:161935.489 server #31 started poller #5

   208:20220314:161935.495 server #33 started trapper #1

   209:20220314:161935.505 server #34 started trapper #2

   211:20220314:161935.516 server #36 started trapper #4

   214:20220314:161935.517 server #39 started alert syncer #1

   213:20220314:161935.518 server #38 started icmp pinger #1

   212:20220314:161935.519 server #37 started trapper #5

   216:20220314:161935.523 server #41 started history poller #2

   210:20220314:161935.524 server #35 started trapper #3

   215:20220314:161935.530 server #40 started history poller #1

   218:20220314:161935.538 server #43 started history poller #4

   217:20220314:161935.554 server #42 started history poller #3

   222:20220314:161935.555 server #47 started odbc poller #1

   220:20220314:161935.566 server #45 started availability manager #1

   219:20220314:161935.587 server #44 started history poller #5

   221:20220314:161935.590 server #46 started trigger housekeeper #1

   175:20220314:161938.821 HA manager has been paused

     7:20220314:161938.821 HA manager error: the server HA registry record has changed ownership

     7:20220314:161938.821 Got signal [signal:11(SIGSEGV),reason:1,refaddr:0x2719]. Crashing ...

     7:20220314:161938.821 ====== Fatal information: ======

     7:20220314:161938.821 program counter not available for this architecture

     7:20220314:161938.821 === Registers: ===

     7:20220314:161938.821 register dump not available for this architecture

     7:20220314:161938.821 backtrace is not available for this platform

     7:20220314:161938.821 === Memory map: ===

Comment by Massimo Rimondini [ 2022 Mar 18 ]

@Michele, please consider enclosing code snippets in a

{code}
...
{code}

block or just add long outputs as attachments for better readability.

No fixes are going to appear in 6.0.2, as this issue is marked to target other releases. Concerning the error, as far as I have understood there are different origins:

  • the HA manager is never expected to crash, as mentioned in this comment of ZBX-20661; this seems to have been recognized and fixed, but I am not sure where
  • a first candidate cause that might trigger such a crash is launching two zabbix server instances with the same database, and this is why ZBX-20661 has been opened
  • another candidate cause is that CUIDs may be shorted on 32 bit OSes, causing some pieces of code to be potentially unsafe even when a single instance is executed without any HA: this is tracked here, and might be a possible cause of ZBX-20715
  • there is also ZBX-20693, but it possibly deals with a different issue

I hope this (unofficial) answer helps understand where developer efforts are heading.

Comment by Andris Zeila [ 2022 Mar 25 ]

Released ZBX-20740 in:

  • pre-6.0.3rc1 f239402d22
  • pre-6.2.0alpha1 2be6d03ce0
Comment by Michele Manzani [ 2022 Mar 25 ]

Hi, I've just installed the versione alpine-trunk with the addition of the parameters 

  • ZBX_HANODENAME=node1

and now the server is up  

Thanks

 

Comment by Michele Manzani [ 2022 Mar 26 ]

Hi, i've just update to the last alpha version and now it's not working the web components 

2022-03-26 08:59:55,464 INFO success: php-fpm7 entered RUNNING state, process has stayed up for > than 2 seconds (startsecs)

2022/03/26 08:59:56 [error] 16#16: *1 FastCGI sent in stderr: "PHP message: PHP Warning:  pg_query(): Query failed: ERROR:  column c.vault_provider does not exist

 

Generated at Sat May 03 06:45:39 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.