fetchmail - BUG in libdispatch client - ML 10.8.2

[srothe@…]

I installed fetchmail using mac ports. But everytime I start fetchmail (SSL included), I receive the following message in /var/log/mail.log

[...] BUG in libdispatch client: Do not close random Unix descriptors [...]

I have compiled the latest fetchmail version by myself, but I receive the same message.

Fetchmail itself works, but what does it means?

Thanks Soeren

[neverpanic (Clemens Lang)]

Please remember to Cc (or assign to) the maintainer, if any. I have done this for you.

This message is printed by libdispatch (and is thus Apple-specific). Apparently fetchmail closes file descriptors that are used by libdispatch, which terminates the process using this message when this happens. I guess one would have to attach a debugger, see where the file descriptor is closed and see whether this actually is a "random" file descriptor and what can be done about it. The maintainer might also consider forwarding this to upstream fetchmail.

[neverpanic (Clemens Lang)]

Actually it seems this has already been reported upstream as ​http://developer.berlios.de/bugs/?func=detailbug&bug_id=18794&group_id=1824.

[srothe@…]

Do you have a debug script? If yes, I can do this for sure :)

[pmq@…]

Hey guys, I'm not using fetchmail any more. Feel free to step up to maintainership if needed.

[srothe@…]

OK.

What do you use instead? Maybe there are good alternatives.

[pmq@…]

There's ​Getmail I guess. But I'm currently using a SaaS solution.

[srothe@…]

Comes libdispatch with OSX, or does mac port install it?

[jmroot (Joshua Root)]

Libdispatch is part of the OS. It's linked into virtually every program, as you can see from:

otool -L /usr/lib/libc.dylib

[matthias.andree@…]

Greetings,

I am the current upstream maintainer of fetchmail, am unaware of MacOS X idiosyncrasies beyond the mere fact that it exists, and causes irritation with GCD idiosyncrasies and recent MacOS X regressions.

Having said that, I also know nothing of otool or .dylibs or any of that stuff, and I do not care to learn any of that stuff, or obtain MacOS X. I have not got the faintest clue as to why a single-threaded application needs to deal with threading garbage. Very irritating.

Documentation on this GCD requirement (keep file descriptor open, how to avoid GCD altogether, ...) is scarce and/or hard to find. I looked around Apple's developer docs, googled for quite a while without coming up with anything substantial, except that a few ported applications are also trapped by these GCD file descriptor idiosyncrasies, and apparently GCD has recently gotten in the fad of killing applications rather than just complaining.

I find it strange that a UNIX-derived system is now breaking a UNIX application that has been around for far more of a decade -- and I am a bit alienated by the whole story:

1. apparently the whole issue only appears if NLS (through gettext/libintl) is in use. LC_ALL=C appears to avoid it, according to srothe@'s reports.
2. apparently the operating system forces underdocumented premature threading stuff on my single-threaded application
3. apparently the operating system also imposes open file descriptors on my single-threaded application.
4. Documentation on this GCD requirement (keep file descriptor open, how to avoid GCD altogether, ...) is scarce and/or hard to find.

What I need is:

1. I need to be able to close all file descriptors in the daemonize() functionm before and/or after close()ing all open file descriptors. That is how Unix has worked for ages, this is required to let go of controlling terminals and thereabouts so we can thoroughly detach from the process that launched fetchmail in order to go in the background.

2. How do I avoid the system forcing additional constraints on my application that are in direct violation of relevant standards (details below)?

3. How do I determine when this descriptor needs to remain open, and which one it is?

I am not ready to break my application for other Unices just because one OS acts up and imposes restrictions that violate the Single Unix Specification aka. IEEE Std 1003.1; If MacOS X believes I must not close its special file descriptor, it is required, that it - when I call close(SPECIAL_MACOS_FILE_DESC) - sets errno = EBADF and returns -1, rather than kill the application.

Now, how can we resolve the mess without depriving end users of established fetchmail functionality (such as NLS or background/daemon mode) that they could successfully use in earlier MacOS X 10.n versions?

[matthias.andree@…]

Cc Me!

[matthias.andree@…]

Apparently the collected workaround is:

env LC_ALL=C fetchmail -d0 ...

where ... is to be substituted by other options, if any.

[srothe@…]

Thanks Matthias for all the information.

I have compiled fetchmail without Native language Support and now there is no error message anymore. But this should be considered only as a workaround.

./configure --disable-nls

[mf2k (Frank Schima)]

This port is no longer maintained.