EM 13c: TNS-01190 errors when listener owner and agent owner are not the same account

Problem:

When monitoring listener's logfile, lots of TNS-01190 are found:

<msg time='2017-06-26T10:21:47.608+02:00' org_id='oracle' comp_id='tnslsnr'

 type='UNKNOWN' level='16' host_id='edosrvoda03'

 host_addr='192.168.15.70'>

 <txt>26-JUN-2017 10:21:47 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=edosrvoda03)(USER=oracle))(COMMAND=trc_directory)(ARGUMENTS=2)(SERVICE=LISTENER)(VERSION=202375680)) * trc_directory * 1190

 </txt>

</msg>

<msg time='2017-06-26T10:21:47.608+02:00' org_id='oracle' comp_id='tnslsnr'

 type='UNKNOWN' level='16' host_id='edosrvoda03'

 host_addr='192.168.15.70'>

 <txt>TNS-01190: The user is not authorized to execute the requested listener command

 </txt>

</msg>

The owners of the agent process is different from the listener process owner. Example: agent is installed and run under user account 'oracle' - listener is started by user 'grid'. 

Reproducability: Every time, Enterprise Manager tries to discover or rediscover new targets on a system, these TNS-01190 errors will occur in listener's logfile. So, try a rediscover on a certain host - after that, You'll find TNS-01190 errors in the listener log.

'Solution'

MOS Note "How To Disable Oracle Database Listener Alerts TNS-01190 In Enterprise Manager Cloud Control to avoid the error "trc_directory (TNS-1190), log_directory (TNS-1190),. Please check log for details." (Doc ID 1399060.1)" recommends two possible solutions:

1. set a listener password and include that password in 'Monitoring Configuration' of the listener target.
   This recommendation does not work for listeners of version 12.1 and higher, because the password feature is no longer supported.
2. edit the metric and remove the 1190 string from the list of values.
   Remains the only possibility ... change Your monitoring template and/or target setting, edit TNS Errors / TNSMsg and replace 'TNS-[ ]*0*(1169|1189|12508|1190)' with 'TNS-[ ]*0*(1169|1189|12508)' (remove the '|1190') or - and that's imho the best way - do not monitor TNSMsgs ...