Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forking daemon #8278

Closed
wants to merge 3 commits into from
Closed

Forking daemon #8278

wants to merge 3 commits into from

Conversation

ChoHag
Copy link
Contributor

@ChoHag ChoHag commented Jun 28, 2016

When started with cron, the sendmail process hung around waiting for its stdin, bitcoind's stdout/err, to close. Fix that using daemon(3) where possible and doing its work where not.

Also makes the forking error messages more consistent and, by using strerror, more explanatory.

@laanwj
Copy link
Member

laanwj commented Jun 28, 2016

Concept ACK

@sipa
Copy link
Member

sipa commented Jun 28, 2016

Concept ACK

@@ -514,6 +514,9 @@ AC_SEARCH_LIBS([inet_pton], [nsl resolv], [AC_DEFINE(HAVE_INET_PTON, 1, [Define

AC_CHECK_DECLS([strnlen])

# Check for daemon(3), unrelated to --with-daemon (although used by it)
AC_CHECK_DECLS([daemon])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice use of the build system

@jonasschnelli
Copy link
Contributor

Concept ACK

@ChoHag
Copy link
Contributor Author

ChoHag commented Jun 30, 2016

I'm not overly concerned with making the feature freeze but I realised it's a bad code smell to have two mutually exclusive command line arguments, so have simply removed the chdir for the time being.

@laanwj
Copy link
Member

laanwj commented Jul 1, 2016

Thanks. Will test.

@laanwj
Copy link
Member

laanwj commented Jul 1, 2016

I get the following compile error when I force HAVE_DECL_DAEMON off:

/home/user/src/bitcoin/src/bitcoind.cpp:164:27: error: use of undeclared identifier '_PATH_DEVNULL'
            int fd = open(_PATH_DEVNULL, 02, 0);

Where is that definition supposed to come from?

@ChoHag
Copy link
Contributor Author

ChoHag commented Jul 1, 2016

It's from /usr/include/paths.h but now that I see the initial _ (and, of course, your error) I wonder how portable it is. The file's there on OpenBSD and Linux. I don't have anything else to hand to look in but notably the file's copyright is 1993 to Berkely so if not officially portable it's probably practically portable.

According to gnulib's manual:
Portability problems not fixed by Gnulib:
This header file is missing on some platforms: Minix 3.1.8, HP-UX 11, Solaris 11 2010-11, mingw, MSVC 9, BeOS.
The set of PATH* macros is platform dependent.

I'll push a change shortly to be more thorough.

@sipa
Copy link
Member

sipa commented Aug 25, 2016

Anything holding this up?

@laanwj
Copy link
Member

laanwj commented Aug 26, 2016

Yes, it's not compiling for me when pretending not to have daemonize(). If we can't test that fallback code, we shouldn't even include it.
@ChoHag was working on a change.
(probably an autotools detection for _PATH_DEVNULL)

@laanwj
Copy link
Member

laanwj commented Aug 26, 2016

Note that we do have some things that potentially print to stdout/stderr after daemonize():

  • util.cpp: PrintExceptionContinue
  • noui.cpp: noui_ThreadSafeMessageBox (used for reporting some errors during http initialization)
  • sync.cpp: AssertLockHeldInternal

Should not hold up this pull, as this is bad behavior in the first place, but we should make sure that everything printed also ends up in the log.

@gmaxwell
Copy link
Contributor

@ChoHag Around? If not then maybe someone else wants to pick this up?

@ChoHag
Copy link
Contributor Author

ChoHag commented Sep 23, 2016

I'm not really, I have pressing personal matters to deal with and cannot
devote time to hacking so I'm happy to hand this over to someone else. I
was researching the best way to make the change fully portable but really
the whole process is quite simple.

Matthew

@ChoHag Around? If not then maybe someone else wants to pick this up?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#8278 (comment)

@laanwj
Copy link
Member

laanwj commented Sep 26, 2016

Are there any POSIX-ish OSes that are supported by our build that don't support daemon()? I've checked at least Linux and OpenBSD and they do. OSX does too (thanks @jonasschnelli).

If not, we could just disable -daemon if that call is not available (like on WIndows). That makes it a lot easier to do this as well as maintain the code afterward as the fallback path is not needed.

@laanwj
Copy link
Member

laanwj commented Sep 26, 2016

Closing in favor of #8813

@laanwj laanwj closed this Sep 26, 2016
laanwj pushed a commit to laanwj/bitcoin that referenced this pull request Sep 26, 2016
Simplified version of bitcoin#8278. Assumes that every OS that (a) is supported
by Bitcoin Core (b) supports daemonization has the `daemon()` function
in its C library.

- Removes the fallback path for operating systems that support
  daemonization but not `daemon()`. This prevents never-exercised code from
  ending up in the repository (see discussion here:
  bitcoin#8278 (comment)).

- Removes the windows-specific path. Windows doesn't support `daemon()`,
  so it don't support daemonization there, automatically.

Original code by Matthew King, adapted by Wladimir van der Laan.
luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Dec 21, 2016
Simplified version of bitcoin#8278. Assumes that every OS that (a) is supported
by Bitcoin Core (b) supports daemonization has the `daemon()` function
in its C library.

- Removes the fallback path for operating systems that support
  daemonization but not `daemon()`. This prevents never-exercised code from
  ending up in the repository (see discussion here:
  bitcoin#8278 (comment)).

- Removes the windows-specific path. Windows doesn't support `daemon()`,
  so it don't support daemonization there, automatically.

Original code by Matthew King, adapted by Wladimir van der Laan.

Github-Pull: bitcoin#8813
Rebased-From: a92bf4a
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants