Opened 12 years ago

Last modified 10 years ago

#36984 new defect

fetchmail - BUG in libdispatch client - ML 10.8.2

Reported by: srothe@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: Cc: matthias.andree@…
Port: fetchmail

Description

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

Change History (13)

comment:1 Changed 12 years ago by neverpanic (Clemens Lang)

Keywords: fetchmail removed
Owner: changed from macports-tickets@… to pmq@…

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.

comment:2 Changed 12 years ago by 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.

comment:3 Changed 12 years ago by srothe@…

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

comment:4 Changed 12 years ago by pmq@…

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

comment:5 Changed 12 years ago by srothe@…

OK.

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

comment:6 Changed 12 years ago by pmq@…

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

comment:7 Changed 12 years ago by srothe@…

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

comment:8 Changed 12 years ago by 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

comment:9 Changed 12 years ago by 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.
  1. How do I avoid the system forcing additional constraints on my application that are in direct violation of relevant standards (details below)?
  1. 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?

comment:10 Changed 12 years ago by matthias.andree@…

Cc: matthias.andree@… added

Cc Me!

comment:11 Changed 12 years ago by matthias.andree@…

Apparently the collected workaround is:

env LC_ALL=C fetchmail -d0 ...

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

comment:12 Changed 12 years ago by 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

Last edited 12 years ago by srothe@… (previous) (diff)

comment:13 Changed 10 years ago by mf2k (Frank Schima)

Owner: changed from pmq@… to macports-tickets@…

This port is no longer maintained.

Note: See TracTickets for help on using tickets.