При daemon() процесс попадает в deadlock

Похоже, одно из проявлений «треды + fork = PITA»

после fork ниток нет, если действительно юзается fork то это скорей всего man signal-safety
но нужно смотреть в дебаге info threads

после fork ниток нет

Спасибо, капитан. Системных нет. Но плюсовые объекты std::thread, например, никуда не деваются. Они, или ntpl где-то внутри себя, или ещё что-то, хранит (ставшую невалидной) инфу о потоках

Похожая проблема, где виснет в деструкторе тредпула после daemon

Не нагуглил что такое PITA

Pita = pain in the ass.

Многопоточное приложение так просто не демонизируешь. daemon() рассчитан на однопоточное приложение. Его можно вызвать до создания потоков. Но результат такой демонизации будет так себе. Фоновый процесс начнёт создавать потоки после выхода из daemon(), словит критическую ошибку, и что ему делать? Ведь об успешной демонизации уже рапортовал успешно завершившийся стартовый процесс.

В общем, приведенный бектрейс – это бектрейс треда, который запускается в конструкторе глобального объекта, я на этот поток никак не могу повлиять снаружи.

в общем, понятно, что нужно остановить все «лишние» потоки перед fork(). Так как этот поток блокирует мьютекс, после чего вызывается fork() и разблокировать не получится.

ничего подобного… утебя :mempool_t::~mempool_t который делает join которому скорей всего это делать не нужно. уметь правильно выходить из fork нужно учиться)

#include <chrono>
#include <thread>
#include <iostream>
#include <unistd.h>

using namespace std::chrono_literals;

int main()
{
    auto thr = std::thread([]()
    {
        for(int ii = 0; ii < 10; ++ii)
        {
            std::cout << "id: " << std::this_thread::get_id() << ", " << ii << std::endl;
            std::this_thread::sleep_for( 1s );
        }
    });

    int pid = fork();

    if(pid)
    {
        std::cout << "pid: " << pid <<std::endl;
        thr.join();
    }
    else
    {
        std::cout << (thr.joinable() ? "111" : "222") <<std::endl;
        execl("/bin/false", "/bin/false", nullptr);
    }

    return 0;
}

Создание потока в конструкторе, ожидание завершения потока в деструкторе, форки вперемешку с тредами. Вы не ищите лёгких путей, судя по всему.

и что ему делать?

Записать в лог и завершить работу? В чём боль, демоны всё пишут в лог, какая разница, когда возникла ошибка, через 100 часов работы или через 100 тактов?

На мой взгляд фоновый процесс демона не должен завершаться из-за каких-то ошибок. Если стартовый процесс вернул 0, значит фоновый процесс успешно запущен и будет работать до усрачки. Фоновый процесс должен завершаться только по команде. Иначе это какой-то дефективный демон.

ИМХО, любой софт содержит ошибки в коде, если не в настоящем времени, то в грядущем, когда что-то изменять в используемых библиотках. И, по большому счёту без разницы, ошибка в конфиге или в коде, что так, что так процесс (фоновый или переднего плана) «не знает» что неправильно, проще завершаться. Да и вобще, ошибка в коде, она на то и ошибка, что программа завершится независимо от желаний кодера :)

А в мире Unix с overcommit-памятью работать до усрачки вобще непонятно как — зарезервируешь на старте побольше памяти, дак OOM-killer убъёт. Будешь брать память понемногу, получишь SIGSEGV. Если уж делать что-то зубодробильное, то и управляющий сокет демону и отдельно висящая задача, контролирующий не просто, что демон есть в списке процессов, а то, что он правильно работает, не зациклился, не залип на внутренних блокировках.

С тем, что переделывать чужой код может быть БОЛЬ, согласен, но, ИМХО, не важно, в демона или какой-то другой функционал прикручивать...

в мире Unix с overcommit-памятью

overcommit – сранный позор.

OOM-killer убъёт.

Лучше хотя бы systemd-oomd настроить или ещё что-то адекватное.

вызова daemon() всё нормально.

Выкинь каку. Вызов daemon() не нужен уже лет 10 как. Тот же systemd умеет просто запускать процессы и управлять ими. Форкаться, закрывать stdin/out/err или перенаправлять их изнутри программы вообще не требуется.