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š <[email protected]> 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/systemd-devel >
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
