VPN Client Segfault on a Pi? Capture the Process First

You start the client, the terminal prints Segmentation fault (core dumped), and the next hour goes into reflashing the card. That message describes how one process died at one moment. It does not say the board is damaged, and it does not clear the power supply, the storage or the image either.

Work from the line the shell printed back to the process behind it. The useful facts are which executable failed, under which environment, and at which stage of the connection.

Start From the Line the Shell Printed

The name in your command is often a wrapper or a launcher that starts a different binary, so confirm which executable the kernel actually terminated. Write down the full path, the package and application version, the architecture, the OS and kernel release, the account that launched it, and the exact time. A shell command named after a VPN can easily start a helper process, and the record will name the helper. Copying the version string from a package you installed last month tells you nothing about what ran.

Note what immediately preceded the crash: startup, profile parsing, authentication, or a session that was already passing traffic. Those four stages narrow the search far more than the word segfault does. Keep the short log window around that event, and leave out guesses about which recent change caused it until the record says so.

Find Out Whether a Memory Image Exists

The core file reference describes a dump as an image of process memory written at termination, and it also lists the conditions that stop that write from happening. Those conditions include a resource limit of zero and a core pattern that routes the dump somewhere other than the working directory. A missing file named core therefore proves nothing about whether a crash occurred. Check the configured pattern and the limit before you conclude the system produced no evidence.

On a system using systemd's collector, the supported view correlates a stored record with an executable and a time. A journal entry and a readable memory image are two different artifacts: retention policy and permissions can leave you with one and not the other. Ask the distribution or the application maintainer for the diagnostic workflow they support, because a trace produced from a different build or a different library set usually wastes their time.

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

Repeat those reads on the machine that actually crashed. Doing them on a fresh install answers a question nobody asked.

Treat the Dump as Secret-Bearing Material

Process memory can hold credentials, session keys and profile contents, which makes a dump more sensitive than the text log beside it. Redacting the log does nothing for an opaque memory image, and ordinary issue trackers keep attachments far longer than a support thread lasts. Move the file through the private channel the vendor or maintainer provides. Posting a raw dump in a public issue exposes whatever was resident when the process died, and you cannot know what that was until someone inspects it.

If a maintainer asks for a trace, ask which executable and libraries they want it from. A backtrace whose frames do not match the reported build is hard to trust and easy to misread.

Check Provenance Before You Replace Anything

Verify package provenance and file integrity through whoever owns the installation, and preserve configuration and identity material before any controlled repair. Do not overwrite the only copy of the evidence just to see whether a clean install starts. A fresh image that boots tells you the new image boots. It does not tell you whether the old one contained a corrupt package, a failing card, or a binary that was always going to fault on this architecture.

If unrelated programs also fail, or the system logs storage, power or kernel errors, keep those observations for the platform investigation. They widen the scope; they do not prove that every segfault comes from failing RAM or a corrupt image.

After a targeted fix, repeat the same authorized launch and the same VPN operation on the same hardware. Say which failure stopped and under which version. A clean boot on its own neither identifies a defective component nor predicts the next hardware fault.