Nimbus error on RHEL8 or Ubuntu 20.x - processes probe - failed to decrypt value. RC=3
search cancel

Nimbus error on RHEL8 or Ubuntu 20.x - processes probe - failed to decrypt value. RC=3

book

Article ID: 216156

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

I have installed DXIM robot version 9.30 and processes probe version 4.70 on Red Hat Enterprise Linux release 8.3 (Ootpa), but we are getting the following error on In

/opt/nimsoft/probes/processes/processes.log :

  May 11 14:52:44:746 processes: (NimCryptographerCfgKeyReadEncryptedValue) failed to decrypt value. RC=3
  May 11 14:52:44:746 processes: (NimCryptographerCfgKeyReadEncryptedValue) failed to decrypt value. RC=3
  May 11 14:52:44:747 processes: (NimCryptographerCfgKeyReadEncryptedValue) failed to decrypt value. RC=3

 

Environment

Release : DX UIM 20.4*/23.4*

Component : UIM - PROCESSES

Note: can happened with other probes as well

Resolution

Dev Team informed that this is a benign message so can be ignored if the probe is in green state and working fine with the profiles.

When the new profile is created in the process probe, it creates a password key for each profile in the cfg if that password is blank then the probe sends an information log, as the probe is not able to decrypt it as the password is blank.

 

 processes: (NimCryptographerCfgKeyReadEncryptedValue) failed to decrypt value. RC=3

 

Cfg snap :- 

 <automount>
      qos_process_io_read_disk = yes
      scan_threads = no
      mcs_profileid = 506740
      scan_proc_parent_name = 
      process_restart = no
      thread_count_type = 
      scan_size = no
      start_dir = 
      qos_process_io_write = yes
      subsystem = 
      resource_arguments = 
      invert_owner = no
      thread_count_limit = 
      action = none
      qos_process_io_write_cancelled = yes
      qos_schedule = 
      user = 
      qos_process_threads = yes
      alarm_schedule = 
      resource_start_dir = 
      qos_process_io_other_data_transfer_rate = yes
      scan_handles = no
      execute = 
      active = no
      description = 
      scan_proc_parent = False
      qos_target = 
      password = 
      cpu_usage_min = 
      resource_execute = no
      arguments = 
   </automount>

Based on that:

1 -The error has no impact and can be ignored

2 - For now the log code would stay as an INFO level message while we ascertain its impact to other components of the solution

3 - If we find it needed and safe to do so, we would update the same in one of our future releases

Additional Information

Dev will discuss  the scope with the team if is good to change the log level of the above message to show just in loglevel 5 in the next probe release.