Understanding the ltaudit service:

The ltaudit service is the NSS Audit Agent daemon that runs continuously on each OES server, collecting NSS file activity and forwarding it to the LT Auditor ^MP server via syslog. It is registered with systemd during installation and can be managed using standard systemctl commands or the agent’s built-in control script located at /opt/bluelance/bin/ltaudit.rc.

Both management methods produce the same result — use whichever is more familiar or appropriate for your environment.

When you need to manage the service:

Checking service status:

Always check the service status first before taking any other management action — it tells you whether the service is running, stopped, or in an error state.

Using systemctl:

systemctl status ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc status

Interpreting the status output:

Starting the service:

If the service is stopped and needs to be started:

Using systemctl:

systemctl start ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc start

After starting, confirm the service is running:

systemctl status ltaudit.service

Stopping the service:

If the service needs to be stopped for maintenance, configuration changes, or troubleshooting:

Using systemctl:

systemctl stop ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc stop

Stopping the service suspends NSS file activity collection on that server. Any events that occur while the service is stopped will not be captured. Stop the service only when necessary and restart it as soon as possible to minimize monitoring gaps.

Restarting the service:

Restart the service to apply configuration changes or reset connections to the LT Auditor ^MP server:

Using systemctl:

systemctl restart ltaudit.service

Using the control script:

/opt/bluelance/bin/ltaudit.rc stop

/opt/bluelance/bin/ltaudit.rc start

After restarting, confirm the service returns to an active (running) state:

systemctl status ltaudit.service

Enabling automatic startup on boot:

To ensure the ltaudit service starts automatically when the OES server reboots, enable it with systemctl:

systemctl enable ltaudit.service

Confirm the service is enabled:

systemctl is-enabled ltaudit.service

The output should return enabled. If it returns disabled, run the enable command again.

Enabling automatic startup is strongly recommended for all production OES servers. Without it, NSS audit collection will not resume after a server reboot until an administrator manually starts the service — potentially leaving a significant monitoring gap.

Disabling automatic startup on boot:

If automatic startup needs to be disabled (e.g., for a server being decommissioned):

systemctl disable ltaudit.service

Reviewing service logs:

If the service fails to start or is behaving unexpectedly, review the agent logs for error details:

General application logs:

ls /opt/bluelance/logs/

NSS audit status log:

cat /opt/bluelance/log/nssstatus.log

Syslog forwarding log:

cat /opt/bluelance/log/syslog_send.log

systemd journal (for service startup errors):

journalctl -u ltaudit.service -n 50

The -n 50 flag returns the last 50 log entries. Increase this number if you need to look further back.

Common errors to look for:

• Connection refused — firewall blocking syslog port
• Certificate errors — TLS configuration issue
• Permission denied — agent lacks required access to NSS volumes
• Failed to open live vigil file — NSS audit subsystem not available

Service management after a configuration change:

Whenever the syslog forwarding configuration is updated using update_syslog_config.sh, restart the service to apply the new settings:

systemctl restart ltaudit.service

Confirm the service is running after the restart, then verify that events are appearing in LT Auditor ^MP to confirm the new configuration is working correctly.

Best practices:

• Always check the service status before investigating log collection issues — a stopped service is the most common cause of missing NSS audit data
• Enable automatic startup on boot on every production OES server to prevent monitoring gaps after reboots
• Restart rather than stop-and-start when applying configuration changes — it is faster and reduces the monitoring gap
• Review the nssstatus.log and syslog_send.log as the first step when troubleshooting collection or forwarding issues
• Include systemctl status ltaudit.service in your regular OES server health check routine alongside other service checks
• Document any planned service interruptions (maintenance windows, upgrades) so the security team is aware of expected monitoring gaps

[Your administrator should include ltaudit service status in any OES server monitoring dashboards or health check scripts used in your environment.]