This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strerror_r() between fork and exec?


On 09/09/2014 12:21 PM, Steven Stewart-Gallus wrote:
> Hello, as you can see in the manual (at
> http://www.gnu.org/software/libc/manual/html_mono/libc.html#index-strerror_005fr)
> strerror_r is not safe in such a situation. The usual trick in such a
> situation is to use a pipe to report back the error code to the
> parent. If you really cannot use such a trick then one hack you might
> be able to do is to fork an initial zygote process from before you
> start using multithreaded functions and then spawn off forks of that
> process instead of your latest one. These are just a few potential
> approaches though and I would need to more about your particular
> situation before I could give you better help.

Steven -

Thanks for the response.  The context of my question is that I have an
existing multithreaded daemon (a NAS monitoring program).  Several of
the threads use external programs to gather their data -- smartctl,
hddtemp, and mdadm.  If the program encounters an error while spawning
one of these external commands, I want to report/log the most useful
error message possible.  "No such file or directory" is obviously more
useful than "Error 2".

I recently learned of the async-safe restriction, and I'm fixing up the
post-fork error reporting to accommodate it.  I've taken the approach of
passing a file descriptor to the child process that refers to either
stderr (if the program is running in "foreground" mode) or a socket to
the syslog daemon.  In the event of an error, the child process can
simply write its message to this file descriptor (with a syslog header
if required).

sys_errlist and sys_nerr work well in this environment.  I realize that
I may miss out on translation or some very obscure error messages, but
I'm OK with that tradeoff.  Given that all of the alternatives seem to
involve fairly significant structural changes to the program, I'll
probably just continue to use them as long as they're around.  (Given
that no completely equivalent replacement exists, I suspect that will be
quite a while.)

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]