0

I have many multithread C++ programs built in Red Hat 2.6.18-164.11.1.el5 and they run and exit properly e.g. in Red Hat 4.18.0-240.15.1.el8_3.x86_64 - no matter if daemonized or not.

But if I build and run them in 4.18.0-372.16.1.el8_6.x86_64, they

  • runs properly,
  • exit properly if not daemonized,
  • but if daemonized, jams on exit after running out of main ( daemonized using function daemon() ).

What might be the reason?

All I have found out is the following:

strace-print if not daemonized:

...
close(4)                                = 0
munmap(0x7f71715f8000, 2105416)         = 0
futex(0x25323b0, FUTEX_WAKE_PRIVATE, 2147483647) = 4
futex(0x2532330, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x2532330, FUTEX_WAKE_PRIVATE, 1) = 0
close(25)                               = 0
...

strace-print if daemonized:

...
close(3)                                = 0
munmap(0x7ff978453000, 2105416)         = 0
futex(0xf953b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xf953b4, FUTEX_WAIT_PRIVATE, 0, NULL) = ?
+++ killed by SIGKILL +++
...

So, calling futex with "waking up all waiters":

  • returns 4 if not daemonized, but
  • returns 0 otherwise, and then the next futex-call jams and brutal killing is the only option.

Is this significant or not?

What might it be I'm doing wrong... any idea?

And remember, I do not use futex function - calls are made by the system itself.

-J

P.S.

Daemonizing using fork does not help.

Forking twice leaves the first child hanging - probably for the same, unknown reason.

WeakIce
  • 1
  • 1
  • May I kindly ask, why you are even using `daemon()` in the first place. Programs detaching themselves from the process group and controlling terminal are the worst, when it comes to service supervision. The length and hacks you have to go to, just to properly supervise them are ridiculous. If `daemon()` is the only thing causing you trouble, why not simply **not** use it? – datenwolf Aug 26 '22 at 07:44
  • Well... perhaps I do not understand. Programs has to run - how to say it - in the backgound. Daemonized. – WeakIce Aug 26 '22 at 07:58
  • @WeakIce: The program does not need to care whether it is daemonized or not. When you want it to run quietly on the background, you start it using `bash -c '(setsid program /dev/null &)'`. – Blabbo the Verbose Aug 26 '22 at 09:31
  • @WeakIce: The usual "reason" for running programs in the "background" is, that the program in question is a long running service. This type of program should be launched, and monitored by service supervisor like *systemd*, or *OpenRC*, or *runit*. Daemonizing a process is strongly discouraged as it makes monitoring a process difficult. You can't rely on the PID (and pidfiles) due to the [ToCToU](https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use) problem. For desktop sessions just use the session autostart facilities. – datenwolf Aug 26 '22 at 16:44
  • All of you - thank you. Wiser every day :) Weight of history: these progs run under a “framework” created in HP-UX >20 y ago. They’r “long running” and “nohup with &” was the 1st option to put them “background”. But we chose to daemonize “by ourselves” by doing it by the book: forking twice etc. And it has worked properly through HP-UX upgrades, change to RHEL and upgrades - until ggc ver 8.5.0. Your advice “solves” the problem, but does not give any hint to find any answer to the original question: what’s wrong with our own “daemonize”-function; where the bug might be? – WeakIce Aug 29 '22 at 03:42

0 Answers0