XMailforum is a readonly knowledge archive now.

Registering as a new user or answering posts is not possible anymore.

Might the force be with you, to find here what you are looking for.

2019-09-20 - hschneider, Admin

Cookie Disclaimer: This forum uses only essential, anonymous session cookies (xmailforum*), nothing to be scared of.

XMail Forum [Powered by Invision Power Board]
Printable Version of Topic
Click here to view this topic in its original format
XMail Forum > Documentation and Knowledge Base > Installing XMail on FreeBSD


Posted by: fonsy Apr 23 2003, 01:15 PM
Xmail & FreeBSD 5.0 in Spanish here:
http://adsi.c-kuma.com/modules/xTutoriales/tutorial.php?IdT=9

Posted by: hschneider May 10 2003, 07:28 AM
Here comes the short version (tested on FreeBSD 4.6.2):

# Build XMail from sourcecode
gmake -f Makefile.bsd

# Copy the created binaries to their appropriate locations
cp sendmail MailRoot/bin
cp XMail MailRoot/bin
cp sendmail MailRoot/bin
cp XMCrypt MailRoot/bin
cp CtrlClnt MailRoot/bin
cp MkUsers MailRoot/bin

# Change rights
chmod 700 MailRoot
chmod 755 MailRoot/bin/*

# Copy things to the final target
cp MailRoot /var/MailRoot

# Hook XMail into the system's startup sequence
# Edit xmail.sh for your needs (MAIL_ROOT and MAIL_CMD_LINE)
cp xmail /usr/local/etc/rc.d/xmail.sh
chmod +x /usr/local/etc/rc.d/xmail.sh

# Kill standard sendmail's process
killall sendmail
rm /var/run/sendmail.pid

#Prepare the startup script for sendmail
# Edit sendmail.sh for your needs (MAIL_ROOT and MAIL_CMD_LINE)
cp sendmail.sh /usr/bin/sendmail.sh
chmod +x /use/bin/sendmail.sh

# Remove the sendmail softlink and
# create a new one, pointing to the startup script
cd /usr/sbin
rm sendmail
ln -s /usr/bin/sendmail.sh sendmail

# -- DONE!

The final release of 1.15 causes a failure during built:

QUOTE

In file included from SysDep.cpp:40:
SysDepBSD.cpp: In function `long unsigned int SysGetDayLight()':
SysDepBSD.cpp:2762: `daylight' undeclared (first use this function)
SysDepBSD.cpp:2762: (Each undeclared identifier is reported only once
SysDepBSD.cpp:2762: for each function it appears in.)
gmake: *** [SysDep.o] Error 1


For a complete built
- open file SysDepBSD.cpp with an editor,
- search for SysGetDayLight(void) ,
- change return ((unsigned long) daylight); to //return ((unsigned long) daylight);

This disables the SysGetDayLight() function, which contains some BSD-invalid code.
This raw modification might have some some influence on the logfile creation. Look at it as a first aid workaround until Davide has fixed this.

Posted by: hschneider May 11 2003, 08:22 AM
Davide's fixed 1.15 for FreeBSD can be downloaded at
http://xmail.marketmix.com/downloads/xmail-1.15bsd.tar.gz




Posted by: fonsy May 14 2003, 08:38 PM
Thanks!

Posted by: hschneider Mar 1 2005, 05:23 PM
Looks like there is a mem leak with the standard make options on BSD platforms:

QUOTE

Hi all,

This is a brief summary from memory of the more excellent version of this mail before sylpheed crashed and ate the original. I lost all the strace and ktrace output I used in finding this :/ Sorry

While trying to figure out why I was getting the following errors on FreeBSD, I have tracked down an issue that is probably affecting others.

After running XMail for a few days, I found I wasn't able to check mail via POP3 (giving error about it not being able to open a file). In my system log I found:

Feb 28 14:31:59 krondor XMail[31933]: Unable to create file
Feb 28 14:42:05 krondor last message repeated 5 times
Feb 28 14:50:10 krondor last message repeated 4 times
Feb 28 14:52:11 krondor XMail[31933]: Unable to create file
Feb 28 14:53:29 krondor su: decker to root on /dev/ttyp0
Feb 28 14:54:12 krondor XMail[31933]: Unable to create file
Feb 28 14:56:13 krondor XMail[31933]: Unable to create file
Feb 28 14:58:14 krondor XMail[31933]: Unable to create file
Feb 28 15:08:20 krondor last message repeated 5 times
Feb 28 15:18:26 krondor last message repeated 5 times

A little checking showed the XMail has thousands of KQUEUE File Descriptors open.

Right after startup, no pop3 or smtp actions taken yet:

: lsof -n -p 10174
COMMAND  PID USER  FD  TYPE    DEVICE SIZE/OFF  NODE NAME
XMail  10174 root  cwd  VDIR      4,12      512      2 /
XMail  10174 root  rtd  VDIR      4,12      512      2 /
XMail  10174 root  txt  VREG      4,17  323624 353338 /var/email/bin/XMail
XMail  10174 root  txt  VREG      4,12  141604  32936 /libexec/ld-elf.so.1
XMail  10174 root  txt  VREG      4,12    20260    14 /lib/libkvm.so.2
XMail  10174 root  txt  VREG      4,12    28644    13 /lib/libcrypt.so.2
XMail  10174 root  txt  VREG      4,18  102568 706635 /usr/lib/libc_r.so.5
XMail  10174 root  txt  VREG      4,18  834196 706807 /usr/lib/libstdc++.so.4
XMail  10174 root  txt  VREG      4,12  114504    15 /lib/libm.so.3
XMail  10174 root  txt  VREG      4,18  133164 706750 /usr/lib/libpthread.so.1
XMail  10174 root  txt  VREG      4,12  882780    24 /lib/libc.so.5
XMail  10174 root    0u  IPv4 0xc34ae1c0      0t0    TCP *:6017 (LISTEN)
XMail  10174 root    1u  VCHR        2,2      0t0    16 /dev/null
XMail  10174 root    2u  VCHR        2,2      0t0    16 /dev/null
XMail  10174 root    3u  PIPE 0xc7cd7180    16384        ->0xc7cd722c
XMail  10174 root    4u  PIPE 0xc7cd722c        0        ->0xc7cd7180
XMail  10174 root    5u  IPv4 0xc34b6000      0t0    TCP *:pop3 (LISTEN)
XMail  10174 root    6u  IPv4 0xc32af380      0t0    TCP *:smtp (LISTEN)
XMail  10174 root    7u  IPv4 0xc51838c0      0t0    TCP *:finger (LISTEN)

After checking one pop3 account:

(snip)
XMail  10174 root    4u    PIPE 0xc7cd722c        0        ->0xc7cd7180
XMail  10174 root    5u    IPv4 0xc34b6000      0t0    TCP *:pop3 (LISTEN)
XMail  10174 root    6u    IPv4 0xc32af380      0t0    TCP *:smtp (LISTEN)
XMail  10174 root    7u    IPv4 0xc51838c0      0t0    TCP *:finger (LISTEN)
XMail  10174 root    9u  KQUEUE 0xc60df100                count=0, state=0

After checking the account again:

(snip)
XMail  10174 root    6u    IPv4 0xc32af380      0t0    TCP *:smtp (LISTEN)
XMail  10174 root    7u    IPv4 0xc51838c0      0t0    TCP *:finger (LISTEN)
XMail  10174 root    9u  KQUEUE 0xc60df100                count=0, state=0
XMail  10174 root  10u  KQUEUE 0xd1c54380                count=0, state=0



I strace'd and ktrace'd XMail processes and found that it was calling kqueue() whenever it was doing a DNS lookup (gethostbyaddr was, I believe, the main culprit).

I started googling for "freebsd kqueue" and a variety of other words appended and found that this has been a problem for some time with FreeBSD. Dating back to 2003 I found posts regarding use of libc_r causing FD leaks with host lookups.

http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042423.html
http://lists.freebsd.org/mailman/htdig/freebsd-bugs/2003-October/003809.html
http://lists.freebsd.org/mailman/htdig/freebsd-bugs/2003-October/003810.html
http://www.rhyolite.com/pipermail/dcc/2003/001409.html

I'm using FreeBSD 5.3-RELEASE (just cvsuped this morning) and still the patches given in the above URLs are not present in the source (though that's not an xmail problem).

After poking at the source a bit I found in Makefile.bsd that it was using libc_r when compiling, but I don't why.

ifeq ($(OSTYPE),OpenBSD)
        SYSTYPE = openbsd
        CFLAGS := $(CFLAGS) -I. -D__UNIX__ -D__BSD__ -D__OPENBSD__ -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAS_SYSMACHINE
        LDFLAGS = -lkvm -pthread -lc_r
else
ifeq ($(OSTYPE),NetBSD)
        SYSTYPE = netbsd
        CFLAGS := $(CFLAGS) -I. -D__UNIX__ -D__BSD__ -D__NETBSD__ -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAS_SYSMACHINE
        LDFLAGS = -lkvm -pthread -lc_r
else
ifeq ($(OSTYPE),Darwin)
        SYSTYPE = darwin
        CFLAGS := $(CFLAGS) -I. -D__UNIX__ -D__BSD__ -D__DARWIN__ -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAS_SYSMACHINE
        LDFLAGS = -lkvm -lpthread
else
        SYSTYPE = freebsd
        CFLAGS := $(CFLAGS) -I. -D__UNIX__ -D__BSD__ -D__FREEBSD__ -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAS_SYSMACHINE
        LDFLAGS = -lkvm -lcrypt -pthread -lc_r
endif


I removed " -lc_r " from the freebsd systype and compiled it normally (gmake -f Makefile.bsd), then installed the new binaries and voila, the FD leak is no more. I haven't tested this on OpenBSD or NetBSD, nor another version of FreeBSD for that matter. I strongly suggest removing -lc_r from the bsd makefile if it's not needed. Why is it there ? If anyone else is running XMail on FreeBSD, I'd like to know what version of freebsd and if you also see the KQUEUE issue, and if the fix I mentioned works for you so maybe Davide can change it in the main release to save fellow unsuspecting bsd users some grief smile.gif

(side note, while testing this I removed all my patches to xmail, was testing with vanilla source)

Thanks,
Darren

Posted by: hschneider Mar 4 2005, 02:56 PM
Looks like this goes deeper than assumed first:

QUOTE

It looks like the bug with KQUEUE  (kqueue() can't close() obtained
descriptors if linked with libc_r) has been reported to the FreeBSD team
as a 5.3 specific problem.  The link follows:

http://www.freebsd.org/cgi/query-pr.cgi?pr=threads/75795

Jeff


QUOTE

By the way, the author of the link I posted previously kindly included
code that he used to solve the prblem on his system.  Here it is:

static int
kqueue_stat(struct file *fp, struct stat *st, struct ucred *active_cred,
  struct thread *td)
{
  struct kqueue *kq;
  int error;

  if ((error = kqueue_aquire(fp, &kq)))
  return ENOENT;
  KQ_LOCK(kq);
  bzero((void *)st, sizeof(*st));
  st->st_size = kq->kq_count;
  kqueue_release(kq, 1);
  KQ_UNLOCK(kq);
  st->st_blksize = sizeof(struct kevent);
  st->st_mode = S_IFIFO;
        return (0);
}

I have not tested it yet, but I am going to this evening.

Jeff




QUOTE

Hi All (FreeBSD 5.3 users) -

The code fragment works well so far on my freeBSD 5.3 system to fix the
-lc_r/KQUEUE bug in the FreeBSD librc - it should be added to
sys/kern/kern_event.c and the kenel recompiled.  I consistently have 0
KQUEUE entries, and I have compiled xmail with -lc_r so that xmail is
using the reentrant functions.

I'll know more as a bit of time goes by!

Jeff

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)