From: Vegard Nossum <vegard.nossum@oracle.com>
To: trinity@vger.kernel.org
Subject: Randomly reopening file descriptors
Date: Thu, 18 Aug 2016 12:45:36 +0200 [thread overview]
Message-ID: <57B591D0.7040808@oracle.com> (raw)
Hi,
I know we're not supposed to send feature requests, so I'm going to
thinly veil this feature request as a request for pointers on how to
make the change myself.
I've discovered that a few bugs only appear within the first few minutes
of trinity starting up -- in particular, proc file and socket bugs. If
the bug hasn't showed up within the first few minutes of running, no
matter how many hours or days it runs for, the bug will not show up at
all.
I *think* this is because a lot of system calls on these fds put the
file/socket in a state where it can't get back to its original state.
For sockets, for example, there is no way to "undo" a listen() call;
once it's in a listening state it will remain in a listening state for
the duration of its lifetime.
Therefore I think it would be useful if the parent process occasionally
reopened/recreated its file descriptors.
AFAICT the only things that currently open file descriptors are:
- open_fds() called ONCE in main() before entering the main loop
- get_new_random_fd() as a syscall argument, however this does not
replace existing fds and so it will only be used for a single syscall
before getting closed again
I may be wrong about any or all of the above, any pointers on how to
best randomly replace the persistent/global fds would be appreciated.
Vegard
next reply other threads:[~2016-08-18 10:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-18 10:45 Vegard Nossum [this message]
2016-08-18 15:43 ` Randomly reopening file descriptors Dave Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57B591D0.7040808@oracle.com \
--to=vegard.nossum@oracle.com \
--cc=trinity@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).