Troubleshooting

Logs

LogCraft internal logs are located under LOGCRAFT_HOME/var/log.

• internal.log contains traces of potential issues and should be the first file to review when troubleshooting. Sending this file to support accelerates resolution, as it is the primary resource examined during analysis.

• access.log records all HTTP requests to the LogCraft API and web interface. This log is especially useful for troubleshooting API issues, monitoring client requests, and verifying authentication or network connectivity.

• debug.log generated only when debug mode is enabled. It provides detailed traces useful for in-depth diagnostics, but can grow quickly and should be turned off after use.

Debug mode

LogCraft should only be started in debug mode when requested by support, as it produces highly verbose output.

Enable debug logging by editing LOGCRAFT_HOME/etc/logcraft.conf

[logging]
debug = true

Then, restart the service:

systemctl restart logcraft

Debug traces are written to LOGCRAFT_HOME/var/log/debug.log

Important

Remember to turn off debug logging after use. Leaving it enabled can quickly generate large trace files that may exhaust available disk space.

Network Troubleshooting

This section regroups handy and commonly used tools and procedures to diagnose the most common network issues.

Port Connectivity

netcat, often called the “Swiss Army knife” of networking, is a versatile Unix utility that facilitates reading and writing data across TCP or UDP connections.

To check if a specific port is accessible on a remote server:

nc -z -v -w2 <server> <port>

If successful, netcat returns a “succeeded” message.

If it fails, it may indicate:

• Incorrect DNS resolution
• Routing issues
• A firewall blocking the connection (often shown as “operation timed out”)

DNS Resolution

As a quick check, the ping command can be used since it must first resolve the hostname before sending packets:

ping -c 1 <server>

Ping vs DNS Resolution

The success of the ping itself is not important here, as ICMP may be blocked by a firewall. What matters is whether ping is able to resolve the hostname into an IP address. If resolution succeeds, the IP address is usually displayed in the output.

For a more accurate test, use DNS-specific tools such as dig or nslookup. These tools are dedicated to DNS resolution and provide detailed output that can help identify misconfigurations.