1. Maintenance and Troubleshooting Guide
  2. Logs
  3. Working with Logs

Working with Logs

This section explains how to work with logs.

Writing to Logs

You configure the Oracle Communications Session Border Controller to indicate you want messages written to logs. The system writes to these log files until they become their maximum size, and rotates them to the maximum number of files. Thresholds for size and number of files depend on whether the system is running on ramdrive or hard disk:

  • If on hard-disk with a formatted system partition, the limits are 5MB per file and 25 files.
  • If not using a hard-disk, the limits are 1MB per file and 12 files.

Note:

These sizes are fixed, based on system software parameters, and are not user configurable.
When a file reaches its maximum size, the system closes it and renames it with .1 appended to the original file name. For example, sipmsg.log becomessipmsg.log.1. The system proceeds with writing new logs to the original filename, sipmsg.log, until it reaches the size limit again. At this point, the system closes sipmsg.log again and:
  • Renames the existing sipmsg.log.1 file to sipmsg.log.2.
  • Renames sipmsg.log to sipmsg.log.1 again.

This continues until you have the maximum number of files associated with the log. When the system reaches this limit, it discards the oldest file.

Manually Rotating Logs

You can manually rotate (close) the log file by using the following command: 

notify * rotate-logs

The * can be any of the following Oracle Communications Session Border Controller tasks:

  • all
  • sipd
  • sysmand
  • berpd
  • lemd
  • mbcd
  • h323d
  • algd
  • radd

You can manually rotate the log files when you are trying to isolate a specific problem. Working with Oracle Technical Support, you could close all current log files (or just for a specific task) and then run a test of your problem. You can then easily identify the log files to review.

Working with Logs Example

For example, to troubleshoot issues you suspect are media-related using the ACLI, you can look at the logs for the middlebox control daemon (MBCD).

  1. Instruct the Oracle Communications Session Border Controller to write all media management transactions to mbcd.log by entering the following command: 
    notify mbcd log
  2. Make some test calls.
  3. Set message writing to the log off by entering the following command: 
    notify mbcd nolog
  4. SFTP the log off the Oracle Communications Session Border Controller to view it.

    Note:

    Oracle recommends only setting the log level to DEBUG on non-production systems.

Displaying List of Log Files

You can display the list of log files by using the display-logfiles ACLI command. Every task writes to its own process log (log.taskname) and protocol trace logs (transaction logs) are enabled or disabled creating a task.log file. The log files are stored in the /opt/logs directory on the Oracle Communications Session Border Controller.

For example: 

ORACLE# display-logfiles
Listing Directory /opt/logs:
drwxrwxrwx  1 0       0              512 Jul  4 18:02 ./
drwxrwxrwx  1 0       0              512 Jul  6 09:50 ../
-rwxrwxrwx  1 0       0           820707 Jul  6 11:55 acmelog
-rwxrwxrwx  1 0       0             3447 Jul  2 17:40 log.sysmand
-rwxrwxrwx  1 0       0             3724 Jul  2 15:59 log.bootstrap
-rwxrwxrwx  1 0       0              132 Jul  2 17:40 log.brokerd
-rwxrwxrwx  1 0       0              740 Jul  2 17:40 log.npsoft
-rwxrwxrwx  1 0       0              369 Jul  2 15:59 log.berpd
-rwxrwxrwx  1 0       0            26660 Jul  6 11:46 log.cliWorker
-rwxrwxrwx  1 0       0             3316 Jul  2 17:40 log.lemd
-rwxrwxrwx  1 0       0              852 Jul  2 17:40 log.atcpd
-rwxrwxrwx  1 0       0              733 Jul  2 17:40 log.atcpApp
-rwxrwxrwx  1 0       0             2877 Jul  2 17:40 log.mbcd
-rwxrwxrwx  1 0       0              757 Jul  2 17:40 log.lid
-rwxrwxrwx  1 0       0             1151 Jul  2 17:40 log.algd
-rwxrwxrwx  1 0       0              741 Jul  2 17:40 log.radd
-rwxrwxrwx  1 0       0              728 Jul  2 17:40 log.pusher
-rwxrwxrwx  1 0       0             1448 Jul  2 17:40 log.ebmd
-rwxrwxrwx  1 0       0           671322 Jul  6 11:55 log.sipd
-rwxrwxrwx  1 0       0           681011 Jul  6 11:55 log.h323d
-rwxrwxrwx  1 0       0             1169 Jul  2 15:59 log.h248d
-rwxrwxrwx  1 0       0            18294 Jul  2 17:40 log.snmpd
-rwxrwxrwx  1 0       0             1078 Jul  2 17:40 snmpd.log
-rwxrwxrwx  1 0       0              190 Jul  2 15:59 log.acliSSH0
-rwxrwxrwx  1 0       0              191 Jul  2 15:59 log.acliSSH1
-rwxrwxrwx  1 0       0              192 Jul  2 15:59 log.acliSSH2
-rwxrwxrwx  1 0       0              192 Jul  2 15:59 log.acliSSH3
-rwxrwxrwx  1 0       0              192 Jul  2 15:59 log.acliSSH4
-rwxrwxrwx  1 0       0             3043 Jul  6 11:38 log.acliConsole
-rwxrwxrwx  1 0       0             2655 Jul  2 21:07 log.acliTelnet0
-rwxrwxrwx  1 0       0              195 Jul  2 15:59 log.acliTelnet1
-rwxrwxrwx  1 0       0              195 Jul  2 15:59 log.acliTelnet2
-rwxrwxrwx  1 0       0              195 Jul  2 15:59 log.acliTelnet3
-rwxrwxrwx  1 0       0              195 Jul  2 15:59 log.acliTelnet4
-rwxrwxrwx  1 0       0          1000005 Jul  4 18:01 acmelog.1

Viewing Logs

You can send the log off the Oracle Communications Session Border Controller through wancom0 or retrieve it using SFTP in order to view it.

Note:

The view-log command currently listed in the ACLI is not supported.

Viewing a Specific Logfile

You can view a specific logfile saved on the Oracle Communications Session Border Controller using the show logfile <filename> command. For example: 

ORACLE# show logfile nginx_error.log
2020/03/27 14:33:07 [notice] 4063#0: signal process started
2020/03/27 14:33:07 [notice] 2680#0: using the "epoll" event method
2020/03/27 14:33:07 [notice] 2680#0: start worker processes
2020/03/27 14:33:07 [notice] 2680#0: start worker process 4064
2020/03/27 14:33:07 [notice] 2680#0: signal 17 (SIGCHLD) received from 2681
2020/03/27 14:33:07 [notice] 2680#0: worker process 2681 exited with code 0
2020/03/27 14:33:07 [notice] 2680#0: signal 29 (SIGIO) received
2020/03/30 09:05:45 [notice] 2678#0: using the "epoll" event method

Dynamically Changing Log Level

You can change the log level dynamically by using the ACLI log-level command in the Superuser mode. The log-level command sets the log level for a specific task. The following table lists the sub-commands within the log-level command.

log-level sub-commands Description
task_name Displays the log level according to the task or process name. (You do not have to enter @<system_name>.) To view all tasks, enter all.

To list available task or process names, enter the show processes command.

log_level Identifies the log level, either by name or by number.
log_type_list Lets you list log types by number or by name in parentheses (()).

Note:

You cannot set the following tasks with the log-level command. You must go to system-config and use system-log-level and process-log-level.
  • authqueue
  • fragHandler
  • heap
  • healthCheckd
  • SSHD
  • tLFMiBd

To change the log level:

  1. Access the ACLI in Superuser mode.
  2. Type log-level followed by a space and one of the log level sub-commands. You can change the log level for the following:

    • system-wide 

      log-level system <log level>

      For example: 

      log-level system DEBUG

    • log level at which a specific task/process sends to the acmelog file 

      log level <task name> <log level>

      For example: 

      log-level sipd debug
  3. Press Enter.

Requesting Log Level Data

You are able to view the current log level of processes/tasks that are running on the Oracle Communications Session Border Controller. You can do this through both the ACLI and ACP:

  • ACLI—The loglevel subcommand has been added to the ACLI show command
  • ACP—A new ACP method called GET_LOG_LEVEL has been added

ACLI show loglevel Command

The ACLI show loglevel command allows you to request log level data from the ACLI console. It takes one mandatory and two optional parameters. The mandatory parameter specifies the name of the Oracle Communications Session Border Controller task for which you are requesting information; one of the optional parameters specifies the type of log level for which you want information and the other allows you to select whether you want to view a verbose display of the task.

You can enter all as the value for either of these parameters to view information for all system tasks or all log levels. If you do not enter a parameter, the system returns an error message and provides a list of valid parameters. You can also wildcard these parameters by entering an asterisk (*), but entering partial wildcards does not work.

To view log level information for a single system task:

  • Type show loglevel, a Space, and then the name of the system task for which you want to see log level information. Then press Enter. 
    ORACLE# show loglevel sipd
Log Levels for process sipd:
loglevel=DEBUG

    To view log level information for a single system task with a specific log level:

  • Type show loglevel, a Space, the name of the system task for which you want to see log level information, and the name of the log. Then press Enter. 
    ORACLE# show loglevel sipd GENERAL
Log Levels for process sipd:
        GENERAL=NOTICE
ORACLE# show loglevel sipd MINOR
Log Levels for process sipd:
        MINOR=NOTICE
ORACLE# show loglevel sipd DNS
Log Levels for process sipd:
        DNS=NOTICE

    To view verbose log level information for a single system task:

  • Type show loglevel, a Space, the name of the system task for which you want to see log level information, and verbose. Then press Enter. 
    ORACLE# show loglevel sipd verbose
Log Levels for process sipd:
GENERAL=DEBUG
EMERGENCY=DEBUG
CRITICAL=DEBUG
MAJOR=DEBUG
MINOR=DEBUG
WARNING=DEBUG
PROC=DEBUG
IPC=DEBUG
SERVICE=DEBUG
EVENT=DEBUG
MESSAGE=DEBUG
TEST=DEBUG
TRIP=DEBUG
SIP=DEBUG
MBCP=DEBUG
FLOW=DEBUG
MEDIA=DEBUG
SESSION=DEBUG
TRANS=DEBUG
TIMER=DEBUG
ALG=DEBUG
NPSOFT=DEBUG
ARP=DEBUG
SNMP=DEBUG
ANDD=DEBUG
XNTP=DEBUG
REDUNDANCY=DEBUG
SIPNAT=DEBUG
H323=DEBUG
ERROR=DEBUG
CONFIG=DEBUG
DNS=DEBUG
H248=DEBUG
BAND=DEBUG
ALI=DEBUG
SS8GI=DEBUG
COPS=DEBUG
ATCP=DEBUG
ATCPAPP=DEBUG
CLF=DEBUG


ACP

Note:

ACP requires a TLS profile.

The new ACP command GET_LOG_LEVEL provides log level information. This ACP request requires authentication, and it must be sent to port 3000.

Because ACP message length is limited, obtaining log level information for multiple system tasks is a multi-step procedure. For a known, single task, the procedure does not require as many steps.

To obtain log level information, an ACP message with the GET_LOG_LEVEL method is sent, and its message body contains information about the log levels being requested. This message body takes the following format: process:type.

An asterisk (*) can be used instead of the process name or log type to wildcard that value. If the process name is replaced with a *, then the first message response is a list of processes; this allows the querying management software to query the level of each process directly.

Wildcarding Task Name and Log Type

When you want to wildcard the process name and log type, the ACP requests looks like this: 

GET_LOG_LEVEL sysmand@acmesystem ACME/1.0
Object-ID:0
Trans-ID: 0
From: user@10.0.0.1
To: sd@10.0.0.2
Content-Type: text/plain
CSeq: 3 GET_LOG_LEVEL
Authorization: Digest
    username="user",
    realm="intern1",
    nonce=6eccad8d8a4d7473d3725bc54bdf4a59,
    uri="sysmand@acmesystem",
    response=5a700cf8c15a0902cb8e75a02cc99f33,
    algorithm="md5-sess",
    cnonce=4c11d5,
    qop="auth",
    nc=00000002
Content-Length: 3
*:*

The response would return the actual list of tasks running on the system. Depending on what tasks are running, it would look like this: 

ACME/1.0 200 Everything is OK
Trans-ID: 0
From: user@10.0.0.1
To: sd@10.0.0.2
CSeq: 3 GET_LOG_LEVEL
Content-Type: text/xml
Content-Length: 253
<ProcessList>
    <process name='sysmand'/>
    <process name='brokerd'/>
    <process name='lemd'/>
    <process name='atcpd'/>
    <process name='atcpApp'/>
    <process name='mbcd'/>
    <process name='lid'/>
    <process name='radd'/>
    <process name='pusher'/>
    <process name='ebmd'/>
    <process name='sipd'/>
    <process name='snmpd'/>
</ProcessList>

Specific Task with Wildcard Log Level

The NMS can use the list from the above example to query each task using additional GET_LOG_LEVEL messages by specifying the name of the tasks and the levels.

The message would look like this: 

GET_LOG_LEVEL sysmand@acmesystem ACME/1.0
Object-ID: 0
Trans-ID: 0
From: user@10.0.0.1
To: sd@10.0.0.2
Content-Type: text/plain
CSeq: 3 GET_LOG_LEVEL
Authorization: Digest
    username="user",
    realm="intern1",
    nonce=5dd735490c78a0146ca06d50f47c0a50,
    uri="sysmand@acmesystem",
    response=129b882a3ee110db86565932819d017b,
    algorithm="md5-sess",
    cnonce=859dcc,
    qop="auth",
    nc=00000002
Content-Length: 9
sysmand:*

To which the response would look like this: 

ACME/1.0 200 Everything is OK
Object-ID: 0
Trans-ID: 0
From: user@10.0.0.1
To: sd@10.0.0.2
CSeq: 3 GET_LOG_LEVEL
Content-Type: text/xml
Content-Length: 544
<sysmand
        GENERAL=DEBUG
        EMERGENCY=DEBUG
        CRITICAL=DEBUG
        MAJOR=DEBUG
        MINOR=DEBUG
        WARNING=DEBUG
        PROC=DEBUG
        IPC=DEBUG
        SERVICE=DEBUG
        EVENT=DEBUG
        MESSAGE=DEBUG
        TEST=DEBUG
        TRIP=DEBUG
        SIP=DEBUG
        MBCP=DEBUG
        FLOW=DEBUG
        MEDIA=DEBUG
        SESSION=DEBUG
        TRANS=DEBUG
        TIMER=DEBUG
        ALG=DEBUG
        NPSOFT=DEBUG
        ARP=DEBUG
        SNMP=DEBUG
        ANDD=DEBUG
        XNTP=DEBUG
        REDUNDANCY=DEBUG
        SIPNAT=DEBUG
        H323=DEBUG
        ERROR=DEBUG
        CONFIG=DEBUG
        DNS=DEBUG
        H248=DEBUG
        BAND=DEBUG
        ALI=DEBUG
        SS8GI=DEBUG
        COPS=DEBUG
        ATCP=DEBUG
        ATCPAPP=DEBUG
        CLF=DEBUG
/>

Specific Task and Log Level Type

To request a specific type of log level for a specific process, specify the process name and type specified in the body of the request: 

GET_LOG_LEVEL sysmand@acmesystem ACME/1.0
Object-ID: 0
Trans-ID: 0
From: user@10.0.0.1
To: sd@10.0.0.2
Content-Type: text/plain
CSeq: 3 GET_LOG_LEVEL
Authorization: Digest
     username="user",
     realm="intern1",
     nonce=d11774ac886bf2293217b1ed894444e3,
     uri="sysmand@acmesystem",
     response=b2eb7cae77e544685ce2883b90189e78,
     algorithm="md5-sess",
     cnonce=e0ad7,
     qop="auth",
     nc=00000002
Content-Length: 14

sysmand:CONFIG

The response to this request would look like this: 

ACME/1.0 200 Everything is OK
Object-ID: 0
Trans-ID: 0
From: user@10.0.0.1
To: sd@10.0.0.2
CSeq: 3 GET_LOG_LEVEL
Content-Type: text/xml
Content-Length: 26
<sysmand
     CONFIG=DEBUG
/>