OS: * FreeBSD 9.2 RELEASE p3 Packages: * prosody-0.9.3 * lua-5.1.5_6 * lua51-luaexpat-1.2.0 * lua51-luafilesystem-1.5.0 * lua51-luasec-0.5 * lua51-luasocket-3.0r1 * libevent-1.4.14b_3 * luaevent from https://github.com/harningt/luaevent In prosody.cfg.lua: ... use_libevent = true; ... # lua-5.1 Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio > require "luaevent" > Ctrl-D # ldd /usr/local/lib/lua/5.1/luaevent/core.so /usr/local/lib/lua/5.1/luaevent/core.so: libevent-1.4.so.4 => /usr/local/lib/libevent-1.4.so.4 (0x801206000) libc.so.7 => /lib/libc.so.7 (0x80081b000) # service prosody start Still waiting... Prosody is still not running. Please give it some time or check your log files for errors. Same problem if using "internal_plain" or "external". Both providers are working fine with "use_libevent = false". # cat /var/log/prosody/prosody.log ... May 06 13:50:42 general info Hello and welcome to Prosody version 0.9.3 May 06 13:50:42 general info Prosody is using the kqueue backend for connection handling May 06 13:50:42 hostmanager debug Activated host: DOMAIN May 06 13:50:42 usermanager debug host 'DOMAIN' now set to use user provider 'external' May 06 13:50:42 portmanager debug No active service for s2s, activating... May 06 13:50:42 socket debug creating server interface... May 06 13:50:42 socket debug new server created with id: table: 0x801b9ad00 May 06 13:50:42 portmanager debug Added listening service s2s to [IP]:5269 May 06 13:50:42 portmanager info Activated service 's2s' on [IP]:5269 May 06 13:50:42 portmanager debug No active service for c2s, activating... May 06 13:50:42 socket debug creating server interface... May 06 13:50:42 socket debug new server created with id: table: 0x801bae980 May 06 13:50:42 portmanager debug Added listening service c2s to [IP]:5222 May 06 13:50:42 portmanager info Activated service 'c2s' on [IP]:5222 May 06 13:50:42 portmanager debug No active service for legacy_ssl, activating... May 06 13:50:42 portmanager info Activated service 'legacy_ssl' on no ports May 06 13:50:42 mod_posix info Prosody is about to detach from the console, disabling further console output May 06 13:50:42 mod_posix info Successfully daemonized to PID 93312 May 06 13:50:42 hostmanager debug Activated host: conference.DOMAIN May 06 13:50:42 datamanager debug Assuming empty persistent storage ('cannot open /PATH/persistent.dat: No such file or directory') for user: nil@conference.DOMAIN May 06 13:50:42 hostmanager debug Activated host: openchat.DOMAIN May 06 13:50:42 usermanager debug host 'OTHER.DOMAIN' now set to use user provider 'external' May 06 13:50:42 hostmanager debug Activated host: freechat.DOMAIN May 06 13:50:42 usermanager debug host 'OTHER.DOMAIN' now set to use user provider 'external' May 06 13:50:42 general info Shutting down... May 06 13:50:42 general info Shutdown status: Cleaning up May 06 13:50:42 general info Shutdown complete ...

I have a vague memory of this being discussed in the chat room, and it being related to daemonization. Or it could be something broken with libevent 1.4, I would suggest trying libevent 2.0 and see if this goes away.

• tag OpSys-FreeBSD

As Nulani just reported in the chatroom, this also affects OpenBSD. It's due to the fact that we initialize libevent (and therefore kqueue) before we daemonize, and kqueue doesn't like that (epoll doesn't mind). Unfortunately this is quite tricky to fix, with the way we currently start up (daemonizing happens in a plugin, and plugins are loaded after the network code is initialized). However we are looking into ways to improve this.

• tags Status-Accepted
• owner MattJ

One solution would be to simply not daemonize, but let something else handle this before starting Prosody. I know some Linux init systems and process supervision systems can take care of daemonization. I am not familiar enough with *BSD to know if something equivalent exists there, but I would be surprised if it did not.

Citing https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2 <pre> The kqueue() system call creates a new kernel event queue and returns a descriptor. The queue is not inherited by a child created with fork(2). However, if rfork(2) is called without the RFFDG flag, then the descrip- tor table is shared, which will allow sharing of the kqueue between two processes.</pre> So basically a wrapper around fork would do the job, calling rfork(RFPROC) instead, should do the job.

This seems like it should do the trick: diff -r 8603b16e85c7 util-src/pposix.c --- a/util-src/pposix.c Sun May 22 18:18:23 2016 +0100 +++ b/util-src/pposix.c Tue May 24 12:45:14 2016 +0200 @@ -49,6 +49,10 @@ #define WITH_MALLINFO #endif +#if defined(RFPROC) +#define fork() rfork(RFPROC) +#endif + /* Daemonization support */ static int lc_daemonize(lua_State* L) {

Fixed in https://hg.prosody.im/0.10/rev/5424e24cdcb1

• tags Status-Fixed
• owner MattJ Zash

• tags Milestone-0.10

FYI this fix does not work on FreeBSD. You have to #include <sys/event.h> and <sys/unistd.h> for EV_SET and RFPROC to be defined, respectively. I can confirm that adding them to the top of pposix.c allows libevent to work while demonized on FreeBSD 10.3.

I imagine that would require even more conditional hackery to only include those when needed.

• tags Status-NeedInfo

How about just #if defined(__FreeBSD__) && defined(RFPROC)

Above applied as https://hg.prosody.im/0.10/rev/93dd90309779 Please verify

• tags Status-Fixed