I'm not sure if it's more portable. I recall FreeBSD only exposing 0–2 in its /dev/fd by default unless you mounted a separate virtual filesystem there. NetBSD seems to always have 64 devnodes no matter how many fds.
I don't think there's a *good* portable method (which is why closerange() is being added) and besides that I'm not sure if that is even in scope for this systemd-centric manpage...the whole idea is that under systemd, a daemon shouldn't need that.
On Mon, Dec 7, 2020, 19:30 Petar Kapriš <petarkapris@xxxxxxxxxxx> wrote:
In the daemon.7 manpage, I added an instruction on closing open file
descriptors, an important step in daemon startup, showing an option to
close them using the files in /dev/fd (a more portable alternative
across systems to using /proc/self/fd)
---
man/daemon.xml | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/man/daemon.xml b/man/daemon.xml
index db95d2f75b..4bae6ebb82 100644
--- a/man/daemon.xml
+++ b/man/daemon.xml
@@ -47,12 +47,13 @@
<listitem><para>Close all open file descriptors except
standard input, output, and error (i.e. the first three file
descriptors 0, 1, 2). This ensures that no accidentally passed
- file descriptor stays around in the daemon process. On Linux,
- this is best implemented by iterating through
- <filename>/proc/self/fd</filename>, with a fallback of
- iterating from file descriptor 3 to the value returned by
+ file descriptor stays around in the daemon process. On most
+ modern systems, this is best implemented by iterating through
+ <filename>/dev/fd</filename>, or
+ <filename>/proc/self/fd</filename> on Linux, with a fallback
+ of iterating from file descriptor 3 to the value returned by
<function>getrlimit()</function> for
- <constant>RLIMIT_NOFILE</constant>. </para></listitem>
+ <constant>RLIMIT_NOFILE</constant>. </para></listitem>
<listitem><para>Reset all signal handlers to their default.
This is best done by iterating through the available signals
--
2.29.2
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
