You have spent three hours tweaking a config file, restarting a service, and checking status, only to find the binary is still using default values. This is one of those classic production headaches where the application log says it is running fine, but the actual behavior tells a different story. It usually means the binary is looking in the wrong place, but the kernel-level system call that actually opened the file never made it into your logs.

Skip the guess-work and trace the syscalls

Instead of blindly running strings on your binary to find hardcoded paths, use eBPF to see what the kernel sees. If a process tries to open a config file, it has to invoke an openat system call. This is where you can catch it red-handed. Most folks reach for strace, but that creates massive overhead and slows down production services. Using opensnoop, you get a clean view of every file open event in real-time.

opensnoop -n my_service_name

• The -n flag filters results to your specific process name so you don’t drown in noise
• Watch for return codes showing ENOENT, which confirms the file wasn’t found where you expected
• Check if the binary is opening a stale file from a hidden vendor directory you forgot existed

Once you confirm the exact path the process is trying to hit, you have the context to decide whether to fix the symlink, adjust the environment variables, or update the systemd unit file. Next time your service ignores your config, you won’t need to guess—you’ll just check which file the kernel actually allowed the process to open.