Manticore Search under systemd: beyond fork, PID files, and guesswork

Manticore Search under systemd: beyond fork, PID files, and guesswork<br>Author: Aleksey Vinogradov<br>Published: Jun 25, 2026 - 7 Min read

If you run Manticore Search on Linux, systemd should be the default way to manage it.<br>That sentence sounds obvious now, but for a long time it was only partly true. Manticore could run under systemd, yes, though the relationship was a little awkward. The daemon model came from an earlier Unix world; systemd came later and wanted different things from a service. So the setup worked, but never in a very satisfying way.<br>What changed is simple enough: Manticore now supports native systemd notifications.<br>Why care? Because several mildly annoying operational problems get better at once:<br>systemctl status tells a more truthful story<br>startup and reload are easier to follow<br>logs fit naturally into journalctl<br>shutdown is safer when real-time tables are flushing data<br>PID files stop doing so much heavy lifting<br>That last point matters less than people think, until the day it matters a lot.<br>Start with shutdown, because that's where things usually get real<br>The nicest part of this change is not the nicest-looking part. It is shutdown behavior.<br>If Manticore is flushing data from real-time tables, shutdown may take a while. Older setups often fell back to searchd --stopwait and a certain amount of hope. Sometimes that was enough. Sometimes it really was not.<br>The failure mode is boring and nasty: systemd decides the service is stuck, waits long enough, then sends SIGKILL. If Manticore is in the middle of a flush, that is about the worst possible moment to force the process down.<br>The newer behavior is cooperative. While Manticore is still flushing data, it tells systemd that progress is ongoing and that more time is needed. Concretely, it sends timeout-extension notifications every 15 seconds, each asking for another 30 seconds.<br>I would put this above almost every other benefit in the article. Better status output is nice. Cleaner reload is nice. Not getting your shutdown path mangled during an RT flush is nicer.<br>A slow stop is not automatically suspicious anymore. Sometimes it just means the server is finishing the part that actually matters.<br>What the old setup looked like<br>Historically, Manticore used the normal Unix daemon pattern: detach from the terminal, double-fork into the background, write a PID file, continue on. That was not some strange design choice. If portability matters, you end up there pretty quickly.<br>The friction came from mixing that model with systemd.<br>Support existed, but it was limited. The unit had to trust that the daemon forked correctly and that the PID file existed and still pointed to the right process. When everything behaved, fine. When it drifted even a little, supervision got fuzzy.<br>The usual weak spots were predictable:<br>process tracking depended on an external file<br>status reporting was indirect<br>startup progress was mostly invisible to systemd<br>reloads and shutdowns were harder to monitor cleanly<br>None of this sounds dramatic when written out calmly. In practice it leads to exactly the kind of question operators hate: is this service actually healthy, or just currently alive.<br>One specific example is worth keeping in mind. If Manticore's internal watchdog restarted searchd after a crash, systemd could keep supervising the original process relationship instead of the newly resurrected daemon. That is where warnings like Supervising process ... which is not our child came from.<br>A smaller but common failure mode was config drift: change the pid_file path in Manticore, forget to update the unit, and systemd ends up tracking the wrong place. The daemon might be up while systemctl status tells a much less helpful story.

That screenshot captures the old setup fairly well. systemd could see a process tree, but not always the service lifecycle you cared about.<br>The notify-based unit<br>The newer setup uses Type=notify, which lets Manticore report its own state directly instead of forcing systemd to infer too much from a PID file and guesswork.<br>The systemd unit now looks like this:<br>[Unit]<br>Description=Manticore Search Engine<br>...

[Service]<br>Type=notify<br>...

ExecStart=/usr/bin/searchd --config /etc/manticoresearch/manticore.conf --nodetach $_ADDITIONAL_SEARCHD_PARAMS<br>...

Restart=on-failure<br>...

A few details matter here.<br>Type=notify means systemd expects status updates from Manticore itself.<br>--nodetach keeps searchd in the foreground. Under systemd, that is the right default. Anything else is extra ceremony. The flag itself is not new; what changed is that it is now part of the packaged systemd setup rather than a debugging-only kind of option.<br>PIDFile is no longer the main supervision mechanism, but it can still be useful and added manually if you have older tooling that expects it.<br>With this setup, Manticore can report states such as:<br>starting<br>loading tables<br>reloading<br>ready<br>That does not sound glamorous....