qmail
Thanks to all for helping me with my email server, installed Qmail-mysql and is working awsome :) Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Don Lewis [EMAIL PROTECTED] writes: Thanks for doing the testing. I just committed this patch. Seems fine here too -- many thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote: I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Hi, On Mon, 15 Jun 2003, Chris Shenton wrote: [...] qmail is run under daemontools and all work fine (the configuration is 2 years old!), but when I delivery the first mail (localy or remote) the qmail-send process fire up to 100% of CPU infinitely All other mail are right delivery, and the CPU use is the only problem, I see in qmail-send.c that select() function, after the first message, allways return 1 same here too. I don't know what it could be - perhaps a problem with named pipes (lock/trigger)? You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt Would be nice if anyone have an idea :) A truss shows me it's running in a tight loop over this code: close(9) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) Anyone else seen this or know what in FreeBSD-5.1 might have changed to cause this? Any thoughts on how I might go about diagnosing this any better? greetings, thorsten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Thorsten Schroeder wrote: Hi, On Mon, 15 Jun 2003, Chris Shenton wrote: [...] qmail is run under daemontools and all work fine (the configuration is 2 years old!), but when I delivery the first mail (localy or remote) the qmail-send process fire up to 100% of CPU infinitely All other mail are right delivery, and the CPU use is the only problem, I see in qmail-send.c that select() function, after the first message, allways return 1 same here too. I don't know what it could be - perhaps a problem with named pipes (lock/trigger)? You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt Would be nice if anyone have an idea :) A truss shows me it's running in a tight loop over this code: close(9) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) Anyone else seen this or know what in FreeBSD-5.1 might have changed to cause this? Any thoughts on how I might go about diagnosing this any better? Which version of fifo_vnops.c? If the problem is present in 5.1-RELEASE, then the problem is likely to be the change made in 1.79 and 1.85. If the problem didn't show up until after the 5.1-RELEASE, then the problem could be the changes in 1.87 or 1.88. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Mon, Jun 16, 2003 at 04:09:51PM +1000, Tim Robbins wrote: On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote: I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Looks like revision 1.86 works, but it stops working with 1.87. Moving the soclose() calls to fifo_inactive() may have caused it. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Hi, On Sun, 15 Jun 2003, Don Lewis wrote: I don't know what it could be - perhaps a problem with named pipes (lock/trigger)? You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt Which version of fifo_vnops.c? If the problem is present in 5.1-RELEASE, then the problem is likely to be the change made in 1.79 and 1.85. If the problem didn't show up until after the 5.1-RELEASE, then the problem could be the changes in 1.87 or 1.88. FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003 fifo_vnops.c: $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $ bye, thorsten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Tim Robbins wrote: On Mon, Jun 16, 2003 at 04:09:51PM +1000, Tim Robbins wrote: On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote: I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Looks like revision 1.86 works, but it stops working with 1.87. Moving the soclose() calls to fifo_inactive() may have caused it. This is an interesting observation, but I'm not sure why it would make a difference. I haven't looked at the qmail source, but it looks like it is doing a non-blocking open on the fifo, calling select() on the fd, and hoping that select() waits for a writer to open the fifo before returning with an indication that the descriptor is readable. It looks like the select code is calling the soreadable() macro to determine if the fifo descriptor is readable, and the soreadable() macro returns a true value if the SS_CANTRCVMORE socket flag is set, which would indicate an EOF condition. I might believe that I accidentally changed the setting of this flag, but I just compared fifo_vnops.c rev 1.78 with 1.87 and I believe this flag should be set the same way in both versions. In both versions, fifo_close() always calls socantrcvmore(), which sets SS_CANTRCVMORE when the writer count drops to zero. Prior to 1.87, fifo_close() also destroyed the sockets when the reference count dropped to zero, which caused fifo_open() to recreate the sockets when the fifo was opened again, and when it did, fifo_open() set the SS_CANTRCVMORE flag again. The posted qmail syscall trace looks like what I would expect to see in the present implementation. I can't explain why it would behave any differently prior to 1.87 ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, I wrote:
On 16 Jun, Tim Robbins wrote:
This looks like a bug in the named pipe code. Reverting
sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go
away. I haven't tracked down exactly what change between RELENG_5_0 and
RELENG_5_1 caused the problem.
Looks like revision 1.86 works, but it stops working with 1.87. Moving the
soclose() calls to fifo_inactive() may have caused it.
This is an interesting observation, but I'm not sure why it would make a
difference. I haven't looked at the qmail source, but it looks like it
is doing a non-blocking open on the fifo, calling select() on the fd,
and hoping that select() waits for a writer to open the fifo before
returning with an indication that the descriptor is readable.
It looks like the select code is calling the soreadable() macro to
determine if the fifo descriptor is readable, and the soreadable() macro
returns a true value if the SS_CANTRCVMORE socket flag is set, which
would indicate an EOF condition.
I might believe that I accidentally changed the setting of this flag,
but I just compared fifo_vnops.c rev 1.78 with 1.87 and I believe this
flag should be set the same way in both versions.
In both versions, fifo_close() always calls socantrcvmore(), which sets
SS_CANTRCVMORE when the writer count drops to zero. Prior to 1.87,
fifo_close() also destroyed the sockets when the reference count dropped
to zero, which caused fifo_open() to recreate the sockets when the fifo
was opened again, and when it did, fifo_open() set the SS_CANTRCVMORE
flag again.
The posted qmail syscall trace looks like what I would expect to see in
the present implementation. I can't explain why it would behave any
differently prior to 1.87 ...
The plot thickens ...
I ran this bit of code on both 5.1 current with version 1.88 of
fifo_vnops.c, and 4.8-stable:
#include sys/types.h
#include sys/time.h
#include unistd.h
#include fcntl.h
main()
{
int fd;
fd_set readfds;
fd = open(myfifo, O_RDONLY | O_NONBLOCK);
printf(before the loop\n);
while (1) {
FD_ZERO(readfds);
FD_SET(fd, readfds);
printf(%d %d\n, fd, select(20, readfds, NULL, NULL, NULL));
}
exit(0);
}
On 4.8-stable, select() immediately returns a 1, whether or not the
fifo has ever been opened for writing.
On 5.1-current, select() waits forever, even if the fifo has been opened
for writing by another process. Select() only returns when something
has actually been written to the fifo, and since this process doesn't
read anything from the fifo, it spins on select() forever.
If some data is getting written to the fifo, it doesn't look like qmail
consumes it, and since fifo_close in 1.87 doesn't destroy the sockets,
it looks like the data is hanging around in the fifo while neither end
is open, and qmail stumbles across this data when it calls select()
after re-opening the fifo.
Now there are two questions that I can't answer:
Why is my analysis of select() and the SS_CANTRCVMORE flag
incorrect in 5.1-current with version 1.87 or 1.88 of
fifo_vnops.c.
Why doesn't qmail get stuck in a similar loop in 4.8-stable,
since select always returns true for reading on a fifo with no
writers?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Mon, 16 Jun 2003, Don Lewis wrote:
On 16 Jun, I wrote:
On 16 Jun, Tim Robbins wrote:
This looks like a bug in the named pipe code. Reverting
sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go
away. I haven't tracked down exactly what change between RELENG_5_0 and
RELENG_5_1 caused the problem.
Looks like revision 1.86 works, but it stops working with 1.87. Moving the
soclose() calls to fifo_inactive() may have caused it.
This is an interesting observation, but I'm not sure why it would make a
difference. I haven't looked at the qmail source, but it looks like it
is doing a non-blocking open on the fifo, calling select() on the fd,
and hoping that select() waits for a writer to open the fifo before
returning with an indication that the descriptor is readable.
In my review of 1.87, I forgot to ask you how atomic the close is with part
of it moved out to fifo_inactive(). I think it's important that all
traces of the old open have gone away (as far as applications can tell)
when the last close returns.
It looks like the select code is calling the soreadable() macro to
determine if the fifo descriptor is readable, and the soreadable() macro
returns a true value if the SS_CANTRCVMORE socket flag is set, which
would indicate an EOF condition.
fifo_close() sets this flag and the corresponding send flag on last close,
so there is no direct problem here.
...
The posted qmail syscall trace looks like what I would expect to see in
the present implementation. I can't explain why it would behave any
differently prior to 1.87 ...
The plot thickens ...
I ran this bit of code on both 5.1 current with version 1.88 of
fifo_vnops.c, and 4.8-stable:
#include sys/types.h
#include sys/time.h
#include unistd.h
#include fcntl.h
main()
{
int fd;
fd_set readfds;
fd = open(myfifo, O_RDONLY | O_NONBLOCK);
printf(before the loop\n);
while (1) {
FD_ZERO(readfds);
FD_SET(fd, readfds);
printf(%d %d\n, fd, select(20, readfds, NULL, NULL, NULL));
}
exit(0);
}
On 4.8-stable, select() immediately returns a 1, whether or not the
fifo has ever been opened for writing.
On 5.1-current, select() waits forever, even if the fifo has been opened
for writing by another process. Select() only returns when something
has actually been written to the fifo, and since this process doesn't
read anything from the fifo, it spins on select() forever.
If some data is getting written to the fifo, it doesn't look like qmail
consumes it, and since fifo_close in 1.87 doesn't destroy the sockets,
it looks like the data is hanging around in the fifo while neither end
is open, and qmail stumbles across this data when it calls select()
after re-opening the fifo.
Now there are two questions that I can't answer:
Why is my analysis of select() and the SS_CANTRCVMORE flag
incorrect in 5.1-current with version 1.87 or 1.88 of
fifo_vnops.c.
I think it is correct, assuming that something writes to the fifo.
Writing might be part of synchronization but actually reading the
data should not be necessary since the last close must discard the
data (POSIX spec).
Why doesn't qmail get stuck in a similar loop in 4.8-stable,
since select always returns true for reading on a fifo with no
writers?
Don't know. Maybe it uses autoconfig to handle the 4.8 behaviour.
The 4.8 behaviour is normal compared with the buggy behaviour of
not discarding data on last close, so applications should handle it
better :-). Maybe qmain spins under 4.8 too, but only until
synchronization is achieved.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Bruce Evans wrote: On Mon, 16 Jun 2003, Don Lewis wrote: On 16 Jun, I wrote: On 16 Jun, Tim Robbins wrote: This looks like a bug in the named pipe code. Reverting sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go away. I haven't tracked down exactly what change between RELENG_5_0 and RELENG_5_1 caused the problem. Looks like revision 1.86 works, but it stops working with 1.87. Moving the soclose() calls to fifo_inactive() may have caused it. This is an interesting observation, but I'm not sure why it would make a difference. I haven't looked at the qmail source, but it looks like it is doing a non-blocking open on the fifo, calling select() on the fd, and hoping that select() waits for a writer to open the fifo before returning with an indication that the descriptor is readable. In my review of 1.87, I forgot to ask you how atomic the close is with part of it moved out to fifo_inactive(). I think it's important that all traces of the old open have gone away (as far as applications can tell) when the last close returns. I hadn't taken queued data into consideration. Now that I've looked at this more closely, there are other problems in both the old and new code. If a process calls fcntl(fd, F_SETOWN, ...) on one end of the fifo, that should be undone when that end of the fifo is closed. In the old implementation, that only happens when both ends of the fifo are closed and the sockets are deleted. On 5.1-current, select() waits forever, even if the fifo has been opened for writing by another process. Select() only returns when something has actually been written to the fifo, and since this process doesn't read anything from the fifo, it spins on select() forever. If some data is getting written to the fifo, it doesn't look like qmail consumes it, and since fifo_close in 1.87 doesn't destroy the sockets, it looks like the data is hanging around in the fifo while neither end is open, and qmail stumbles across this data when it calls select() after re-opening the fifo. Now there are two questions that I can't answer: Why is my analysis of select() and the SS_CANTRCVMORE flag incorrect in 5.1-current with version 1.87 or 1.88 of fifo_vnops.c. I think it is correct, assuming that something writes to the fifo. Writing might be part of synchronization but actually reading the data should not be necessary since the last close must discard the data (POSIX spec). It sure looks to me like SS_CANTRCVMORE is always set when the write end of the fifo is closed, no matter whether the the sockets were freshly allocated by a fifo_open() call on the read end of the fifo, or because the the last writer closed the write end of the fifo. It sure looks like select() should immediately return if this flag is set, but it is not returning ... Actually, something seems broken. I modified my little test program to actually read the data, which works just fine, but select() still blocks when the writer closes the fifo, so there doesn't seem to be a way to detect the EOF. Why doesn't qmail get stuck in a similar loop in 4.8-stable, since select always returns true for reading on a fifo with no writers? Don't know. Maybe it uses autoconfig to handle the 4.8 behaviour. The 4.8 behaviour is normal compared with the buggy behaviour of not discarding data on last close, so applications should handle it better :-). Maybe qmain spins under 4.8 too, but only until synchronization is achieved. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Thorsten Schroeder wrote:
Hi,
On Sun, 15 Jun 2003, Don Lewis wrote:
I don't know what it could be - perhaps a problem with named pipes
(lock/trigger)?
You can find my ktrace output here: http://cs.so36.net/~ths/kdump.txt
Which version of fifo_vnops.c? If the problem is present in
5.1-RELEASE, then the problem is likely to be the change made in 1.79
and 1.85. If the problem didn't show up until after the 5.1-RELEASE,
then the problem could be the changes in 1.87 or 1.88.
FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003
fifo_vnops.c:
$FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $
Try upgrading to 1.88 and applying this patch:
Index: sys/fs/fifofs/fifo_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v
retrieving revision 1.88
diff -u -r1.88 fifo_vnops.c
--- sys/fs/fifofs/fifo_vnops.c 13 Jun 2003 06:58:11 - 1.88
+++ sys/fs/fifofs/fifo_vnops.c 16 Jun 2003 08:44:20 -
@@ -70,7 +70,6 @@
static int fifo_lookup(struct vop_lookup_args *);
static int fifo_open(struct vop_open_args *);
static int fifo_close(struct vop_close_args *);
-static int fifo_inactive(struct vop_inactive_args *);
static int fifo_read(struct vop_read_args *);
static int fifo_write(struct vop_write_args *);
static int fifo_ioctl(struct vop_ioctl_args *);
@@ -98,7 +97,6 @@
{ vop_create_desc, (vop_t *) vop_panic },
{ vop_getattr_desc,(vop_t *) vop_ebadf },
{ vop_getwritemount_desc, (vop_t *) vop_stdgetwritemount },
- { vop_inactive_desc, (vop_t *) fifo_inactive },
{ vop_ioctl_desc, (vop_t *) fifo_ioctl },
{ vop_kqfilter_desc, (vop_t *) fifo_kqfilter },
{ vop_lease_desc, (vop_t *) vop_null },
@@ -556,32 +554,18 @@
if (fip-fi_writers == 0)
socantrcvmore(fip-fi_readsock);
}
- VOP_UNLOCK(vp, 0, td);
- return (0);
-}
-
-static int
-fifo_inactive(ap)
- struct vop_inactive_args /* {
- struct vnode *a_vp;
- struct thread *a_td;
- } */ *ap;
-{
- struct vnode *vp = ap-a_vp;
- struct fifoinfo *fip = vp-v_fifoinfo;
-
VI_LOCK(vp);
- if (fip != NULL vp-v_usecount == 0) {
+ if (vp-v_usecount == 1) {
vp-v_fifoinfo = NULL;
VI_UNLOCK(vp);
(void)soclose(fip-fi_readsock);
(void)soclose(fip-fi_writesock);
FREE(fip, M_VNODE);
- }
- VOP_UNLOCK(vp, 0, ap-a_td);
+ } else
+ VI_UNLOCK(vp);
+ VOP_UNLOCK(vp, 0, td);
return (0);
}
-
/*
* Print out internal contents of a fifo vnode.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Don Lewis wrote: Actually, something seems broken. I modified my little test program to actually read the data, which works just fine, but select() still blocks when the writer closes the fifo, so there doesn't seem to be a way to detect the EOF. I think this should be covered under the exceptional event and read select flags (a subsequent read will return 0). Also, you should remember that qmail opens the thing with non-blocking I/O, and then expects the select to block. Very odd program, qmail. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On Mon, 16 Jun 2003, Don Lewis wrote: On 16 Jun, Bruce Evans wrote: In my review of 1.87, I forgot to ask you how atomic the close is with part of it moved out to fifo_inactive(). I think it's important that all traces of the old open have gone away (as far as applications can tell) when the last close returns. I hadn't taken queued data into consideration. Now that I've looked at this more closely, there are other problems in both the old and new code. If a process calls fcntl(fd, F_SETOWN, ...) on one end of the fifo, that should be undone when that end of the fifo is closed. In the old implementation, that only happens when both ends of the fifo are closed and the sockets are deleted. F_SETOWN (and associated signal delivery) is even more broken than that :-]. This fcntl() should applied to the file (though not just the file descriptor), so its effect should be limited to fd's open in the file instance and go away when all thse are closed. However, F_SETOWN (and associated signal delivery) actually applies to the socket for fifos. It doesn't work quite right for ttys either. F_SETOWN apparently isn't used in ways complicated enough to require it to work right. Now there are two questions that I can't answer: Why is my analysis of select() and the SS_CANTRCVMORE flag incorrect in 5.1-current with version 1.87 or 1.88 of fifo_vnops.c. I think it is correct, assuming that something writes to the fifo. Writing might be part of synchronization but actually reading the data should not be necessary since the last close must discard the data (POSIX spec). It sure looks to me like SS_CANTRCVMORE is always set when the write end of the fifo is closed, no matter whether the the sockets were freshly allocated by a fifo_open() call on the read end of the fifo, or because the the last writer closed the write end of the fifo. It sure looks like select() should immediately return if this flag is set, but it is not returning ... Alfred changed the semantics for 5.x. I thought that you knew this. I finally gave up resisting this change after a lot of email :-). In 5.x, SS_CANTRCVMORE often has no effect for fifos (it still works normally for sockets). fifo_poll() normally calls soo_poll() with POLLIN converted to POLLINIGNEOF. This causes soo_poll() (sopoll()) to skip the usual SS_CANTRCVMORE check (which is inside soreadable()) and check the watermark instead, so that select() on a fifo normally waits for data even when the fifo is open in nonblocking mode and SS_CANTRCVMORE is set. Blocking in select() even in nonblocking mode is usually what is wanted, but is not what is wanted for detecting EOF. 4.8 handles EOF detection (== all writers going away in the context of fifos) better at a cost of providing no good way to wait for the first writer. We changed it since all other systems seem to do it like 5.x and few applications understand this. Actually, something seems broken. I modified my little test program to actually read the data, which works just fine, but select() still blocks when the writer closes the fifo, so there doesn't seem to be a way to detect the EOF. Hmm, we may have changed too much. EOF can be detected using poll() instead of select() and seting POLLIN and POLLINIGNEOF in the poll flags (this stops fifo_poll() clearing POLLIN -- see the comment), but the POLLINIGNEOF is not documented at the application level and is probably never used there. I suspect that other systems have more magic to handle EOF. I tried to avoid such magic since I think the state of the fifo should be the same when there are no writers (and no data) no matter how the state of having no writers was reached (otherwise I think the state depends too much on races between open() for reading and close() by the last writer). POSIX is clear enough on this for read/write but fuzzy for select/poll. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Hi, On Mon, 16 Jun 2003, Don Lewis wrote: FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003 fifo_vnops.c: $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $ Try upgrading to 1.88 and applying this patch: Index: sys/fs/fifofs/fifo_vnops.c === RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v retrieving revision 1.88 diff -u -r1.88 fifo_vnops.c --- sys/fs/fifofs/fifo_vnops.c13 Jun 2003 06:58:11 - 1.88 +++ sys/fs/fifofs/fifo_vnops.c16 Jun 2003 08:44:20 - [...] Yes! This seems to work fine :) qmail-send doesn't increase cpu usage after the first mail anymore. Thanks a lot, Thorsten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
Thorsten Schroeder wrote: Hi, On Mon, 16 Jun 2003, Don Lewis wrote: FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003 fifo_vnops.c: $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $ Try upgrading to 1.88 and applying this patch: Index: sys/fs/fifofs/fifo_vnops.c === RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v retrieving revision 1.88 diff -u -r1.88 fifo_vnops.c --- sys/fs/fifofs/fifo_vnops.c 13 Jun 2003 06:58:11 - 1.88 +++ sys/fs/fifofs/fifo_vnops.c 16 Jun 2003 08:44:20 - [...] Yes! This seems to work fine :) I run qmail on my 4.8 servers. For my sanity, is this a problem in 5.1-RELEASE, or in code after 5.1-RELEASE? We haven't upgraded to 5.1 yet (and don't intend to for a while), but I thought I'd ask since this bug would cripple our mail server. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Thorsten Schroeder wrote: Hi, On Mon, 16 Jun 2003, Don Lewis wrote: FreeBSD 5.1-CURRENT #1: Thu Jun 5 19:29:29 CEST 2003 fifo_vnops.c: $FreeBSD: src/sys/fs/fifofs/fifo_vnops.c,v 1.87 2003/06/01 06:24:32 truckman Exp $ Try upgrading to 1.88 and applying this patch: Index: sys/fs/fifofs/fifo_vnops.c === RCS file: /home/ncvs/src/sys/fs/fifofs/fifo_vnops.c,v retrieving revision 1.88 diff -u -r1.88 fifo_vnops.c --- sys/fs/fifofs/fifo_vnops.c 13 Jun 2003 06:58:11 - 1.88 +++ sys/fs/fifofs/fifo_vnops.c 16 Jun 2003 08:44:20 - [...] Yes! This seems to work fine :) qmail-send doesn't increase cpu usage after the first mail anymore. Thanks a lot, Thanks for doing the testing. I just committed this patch. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Jesse Guardiani wrote: I run qmail on my 4.8 servers. For my sanity, is this a problem in 5.1-RELEASE, or in code after 5.1-RELEASE? We haven't upgraded to 5.1 yet (and don't intend to for a while), but I thought I'd ask since this bug would cripple our mail server. It was broken in 5.1-CURRENT shortly after 5.1-RELEASE, until I committed a patch a few minutes ago. 5.1-RELEASE is fine. The problematic versions of fifo_vnops.c are 1.87 and 1.88. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
On 16 Jun, Bruce Evans wrote: On Mon, 16 Jun 2003, Don Lewis wrote: On 16 Jun, Bruce Evans wrote: In my review of 1.87, I forgot to ask you how atomic the close is with part of it moved out to fifo_inactive(). I think it's important that all traces of the old open have gone away (as far as applications can tell) when the last close returns. I hadn't taken queued data into consideration. Now that I've looked at this more closely, there are other problems in both the old and new code. If a process calls fcntl(fd, F_SETOWN, ...) on one end of the fifo, that should be undone when that end of the fifo is closed. In the old implementation, that only happens when both ends of the fifo are closed and the sockets are deleted. F_SETOWN (and associated signal delivery) is even more broken than that :-]. This fcntl() should applied to the file (though not just the file descriptor), so its effect should be limited to fd's open in the file instance and go away when all thse are closed. However, F_SETOWN (and associated signal delivery) actually applies to the socket for fifos. It doesn't work quite right for ttys either. F_SETOWN apparently isn't used in ways complicated enough to require it to work right. There is a fundamental architectural problem -- devices and files don't have a list of the descriptors that have them open. That would require putting descriptors on another list (and dealing with the necessary locking), which would also bloat the size of the descriptor structure. Storing the F_SETOWN info there would bloat all descriptors even more rather than the relative handful of device structures that support this feature. Now there are two questions that I can't answer: Why is my analysis of select() and the SS_CANTRCVMORE flag incorrect in 5.1-current with version 1.87 or 1.88 of fifo_vnops.c. I think it is correct, assuming that something writes to the fifo. Writing might be part of synchronization but actually reading the data should not be necessary since the last close must discard the data (POSIX spec). It sure looks to me like SS_CANTRCVMORE is always set when the write end of the fifo is closed, no matter whether the the sockets were freshly allocated by a fifo_open() call on the read end of the fifo, or because the the last writer closed the write end of the fifo. It sure looks like select() should immediately return if this flag is set, but it is not returning ... Alfred changed the semantics for 5.x. I thought that you knew this. I finally gave up resisting this change after a lot of email :-). In 5.x, SS_CANTRCVMORE often has no effect for fifos (it still works normally for sockets). fifo_poll() normally calls soo_poll() with POLLIN converted to POLLINIGNEOF. This causes soo_poll() (sopoll()) to skip the usual SS_CANTRCVMORE check (which is inside soreadable()) and check the watermark instead, so that select() on a fifo normally waits for data even when the fifo is open in nonblocking mode and SS_CANTRCVMORE is set. Nope, I didn't know this, and I missed the POLLIN-POLLINIGNEOF conversion when I was tracing the code. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. last pid: 22793; load averages: 1.06, 1.02, 1.00 up 0+08:13:46 20:36:32 74 processes: 2 running, 72 sleeping Mem: 38M Active, 51M Inact, 84M Wired, 28K Cache, 73M Buf, 452M Free Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 615 qmails 1320 1228K 616K RUN483:00 96.88% 96.88% qmail-send I noticed an identical complaint on the qmail list, to which there have so far been no replies (except you should ask the FreeBSD list): From: Luca Morettoni [EMAIL PROTECTED] Subject: qmail on FreeBSD 5.1-CURRENT To: [EMAIL PROTECTED] [...] qmail is run under daemontools and all work fine (the configuration is 2 years old!), but when I delivery the first mail (localy or remote) the qmail-send process fire up to 100% of CPU infinitely All other mail are right delivery, and the CPU use is the only problem, I see in qmail-send.c that select() function, after the first message, allways return 1 A truss shows me it's running in a tight loop over this code: open(lock/trigger,0x4,027757775230)= 8 (0x8) stat(todo,0xbfbffa00) = 0 (0x0) open(todo,0x4,01) = 9 (0x9) fstat(9,0xbfbffa00) = 0 (0x0) fcntl(0x9,0x2,0x1) = 0 (0x0) fstatfs(0x9,0xbfbff900) = 0 (0x0) getdirentries(0x9,0x8059000,0x1000,0x805a214)= 512 (0x200) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) getdirentries(0x9,0x8059000,0x1000,0x805a214)= 0 (0x0) lseek(9,0x0,0) = 0 (0x0) close(9) = 0 (0x0) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) select(0x9,0xbfbffcbc,0xbfbffc3c,0x0,0xbfbffc24) = 1 (0x1) gettimeofday(0xbfbffbc8,0x0) = 0 (0x0) close(8) = 0 (0x0) open(lock/trigger,0x4,027757775230)= 8 (0x8) I see nothing besides usual message delivery information in qmail's logs. Failing that, I rebuilt qmail and it seemed to have fixed it, but I didn't wait long enough: it's pegged at 100% CPU, constantly. If what Luca says is true, maybe it hadn't sent a message yet. Anyone else seen this or know what in FreeBSD-5.1 might have changed to cause this? Any thoughts on how I might go about diagnosing this any better? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qmail uses 100% cpu after FreeBSD-5.0 to 5.1 upgrade
I've been running qmail for years and like it, installed pretty much per www.LifeWithQmail.org. My main system was running FreeBSD 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to 5.1-CURRENT a couple days back, the qmail-send process started using all CPU. [snip] Anyone else seen this or know what in FreeBSD-5.1 might have changed to cause this? Any thoughts on how I might go about diagnosing this any better? I saw this too, but couldn't get it fixed either. My solution (hopefully temporary) was to switch to another MTA. Fred -- I used to think romantic love was a neurosis shared by two, a supreme foolishness. I no longer thought that. There's nothing foolish in loving anyone. Thinking you'll be loved in return is what's foolish. -- Rita Mae Brown pgp0.pgp Description: PGP signature
Re: Integrating QMAIL in the world
We argue about this a lot. Nobody has, as yet, ever done the work to make "bindist" a meta-package which depends (perhaps selectively) on sub-packages like groff, sendmail, gcc, et al. to achieve the required state of "bundling by default but not by requirement" in FreeBSD. This is despite the fact that we've even gotten to the level of discussing "how it should look" many many times, and I even believe a few people volunteered to do the work the last few times this came up. They subsequently disappeared into the same black hole which swallows so many prospective volunteers, it seems, and all that was left to mark the event was the echos of thread in the mail archives. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
At 11:21 PM -0700 2000/4/12, Jordan K. Hubbard wrote: They subsequently disappeared into the same black hole which swallows so many prospective volunteers, it seems, and all that was left to mark the event was the echos of thread in the mail archives. :-) Sorry, my fault. I shouldn't have gotten this mess going again. ;-( -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Fri, 14 Apr 2000, Joe Greco wrote: In other words, if we're going to be replacing sendmail with an alternative MTA, I'd prefer postfix over qmail, and I believe I can marshall some pretty strong arguments for that position. Perhaps it's time to revisit something I proposed several years ago. Remove Sendmail from the base system - or, at least, make it a "package" that is removable with the package management tool. Then be able to add another mailer (or an updated Sendmail) in its place. Ideally, Sendmail would be available as a package for installation as part of the base system, just like games or info or proflibs. I would love to see this happen with other components of the system as well, such as BIND. While it is fantastic that FreeBSD comes out of the box so fully functional, it does make it a bit of a pain for those of us who intend to build servers - we have to disable the original before installing a new package. :-/ I always keep hearing the same line. You guys *know* perfectly well how to do it, and it's not a big thing to you, you even admit it's only "a bit of a pain". To most of the rest of the world, it's a huge thing, and they don't have the least clue how to do it. If you guys want so desperately to make things 1% easier, why have I never seen anyone bring out a parallel "sparse" FreeBSD? It wouldnt' be a large thing to do, and you who keep on asking for it, you know that very well. Just have a reasonable bit of compassion for everyone else. That's not to say the huge hurt it would do to FreeBSD to all reviewers and the public at large, just to save you "a bit of a pain". Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Fri, 14 Apr 2000, Joe Greco wrote: In other words, if we're going to be replacing sendmail with an alternative MTA, I'd prefer postfix over qmail, and I believe I can marshall some pretty strong arguments for that position. Perhaps it's time to revisit something I proposed several years ago. Remove Sendmail from the base system - or, at least, make it a "package" that is removable with the package management tool. Then be able to add another mailer (or an updated Sendmail) in its place. Ideally, Sendmail would be available as a package for installation as part of the base system, just like games or info or proflibs. I would love to see this happen with other components of the system as well, such as BIND. While it is fantastic that FreeBSD comes out of the box so fully functional, it does make it a bit of a pain for those of us who intend to build servers - we have to disable the original before installing a new package. :-/ I always keep hearing the same line. You guys *know* perfectly well how to do it, and it's not a big thing to you, you even admit it's only "a bit of a pain". To most of the rest of the world, it's a huge thing, and they don't have the least clue how to do it. If you guys want so desperately to make things 1% easier, why have I never seen anyone bring out a parallel "sparse" FreeBSD? It wouldnt' be a large thing to do, and you who keep on asking for it, you know that very well. Just have a reasonable bit of compassion for everyone else. That's not to say the huge hurt it would do to FreeBSD to all reviewers and the public at large, just to save you "a bit of a pain". Uh, Chuck, can you tell me how many BIND and Sendmail advisories there have been in the last five years? Wouldn't it be nice if we could just tell newbies, "hey, yeah, that Sendmail has a known security issue, pkg_delete it and then add this new one here". Or would you prefer to explain to someone who doesn't "have the least clue how to do it" how to upgrade BIND and Sendmail to the latest? The concept is beneficial from _many_ angles, not just the one I gave. Despite my tendency to promote the traditional BSD distribution style, that does not mean that I feel that everything in FreeBSD should arrive as it did on the 4.4BSD tape. I think that the ability to be able to select modules for inclusion or exclusion would be particularly useful. ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Sat, 15 Apr 2000, Joe Greco wrote: Uh, Chuck, can you tell me how many BIND and Sendmail advisories there have been in the last five years? Wouldn't it be nice if we could just tell newbies, "hey, yeah, that Sendmail has a known security issue, pkg_delete it and then add this new one here". Or would you prefer to explain to someone who doesn't "have the least clue how to do it" how to upgrade BIND and Sendmail to the latest? The concept is beneficial from _many_ angles, not just the one I gave. Despite my tendency to promote the traditional BSD distribution style, that does not mean that I feel that everything in FreeBSD should arrive as it did on the 4.4BSD tape. I think that the ability to be able to select modules for inclusion or exclusion would be particularly useful. If you want to pick another one and by default install that, fine. If you want to force new users to read all about mailers just to get their first mail working, no, that's just too much, Joe, you're asking too much of folks. If you've got a bone to pick with sendmail, that's ok, but you have to pick a better one. If you can't decide on the best one, then how in the heck do you expect Joe Public to do better? ALWAYS provide sensible default values, not a bunch of expert questions. Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Sat, 15 Apr 2000, Joe Greco wrote: Uh, Chuck, can you tell me how many BIND and Sendmail advisories there have been in the last five years? Wouldn't it be nice if we could just tell newbies, "hey, yeah, that Sendmail has a known security issue, pkg_delete it and then add this new one here". Or would you prefer to explain to someone who doesn't "have the least clue how to do it" how to upgrade BIND and Sendmail to the latest? The concept is beneficial from _many_ angles, not just the one I gave. Despite my tendency to promote the traditional BSD distribution style, that does not mean that I feel that everything in FreeBSD should arrive as it did on the 4.4BSD tape. I think that the ability to be able to select modules for inclusion or exclusion would be particularly useful. If you want to pick another one and by default install that, fine. If you want to force new users to read all about mailers just to get their first mail working, no, that's just too much, Joe, you're asking too much of folks. If you've got a bone to pick with sendmail, that's ok, but you have to pick a better one. If you can't decide on the best one, then how in the heck do you expect Joe Public to do better? ALWAYS provide sensible default values, not a bunch of expert questions. Chuck, Please go back and read what I _wrote_. Your response assumes I made statements that I certainly did not, and suggests to me that you missed every third word in my previous messages. :-( In particular, I advocated including Sendmail in the base system in a manner that would allow it to be trivially removed (or, alternatively, not including it but making it a selectable package, like X11). This could, for example, be done in the very same way that we currently do loads of other crap, like /usr/games, proflibs, etc. More ideally, it would be done in a format compatible with the package management system, so that one could simply "pkg_delete" Sendmail and install a new one. Am I getting through now? :-) -- ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
How will this affect this /etc/mail/mailer.conf "thing" (and I wonder why that was put there to begin with). If we're going to use a mailer.conf, then it should be able to work with other MTAs; which it probably won't because they perform their respective tasks differently. _F To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Sat, 15 Apr 2000, Joe Greco wrote: Chuck, Please go back and read what I _wrote_. Your response assumes I made I've got your message, I quoted it fully in my first response. You asked to "Remove Sendmail from the base system", and that's a direct quote, Joe. statements that I certainly did not, and suggests to me that you missed every third word in my previous messages. :-( In particular, I advocated including Sendmail in the base system in a manner that would allow it to be trivially removed (or, alternatively, not including it but making it a selectable package, like X11). No, you said remove it, or at least make it removeable. I responded that you can't just remove it. Go to your sent mail message folder, I'm not making this up. I said don't remove it (not "don't make it removeable"). You're the one who's sticking new words in. This could, for example, be done in the very same way that we currently do loads of other crap, like /usr/games, proflibs, etc. More ideally, it would be done in a format compatible with the package management system, so that one could simply "pkg_delete" Sendmail and install a new one. Am I getting through now? :-) You asked in your mail to remove it, I said you can't leave ordinary users without a good default. Your context in what you said was that it was a minor pain to have to remove the default mailer. I stand by what I said. You changed your message, and if you want, I can send your message back to you. If you argue *only* that some easier method be arranged so that mailers can be swapped out, that I fully approve of. I never said otherwise, and I don't like much the way you changed things. In fact, what the heck, here's your original message, cut out of my reply (where I quoted all of your part of the exchange): Perhaps it's time to revisit something I proposed several years ago. Remove Sendmail from the base system - or, at least, make it a "package" that is removable with the package management tool. Then be able to add another mailer (or an updated Sendmail) in its place. Ideally, Sendmail would be available as a package for installation as part of the base system, just like games or info or proflibs. I would love to see this happen with other components of the system as well, such as BIND. While it is fantastic that FreeBSD comes out of the box so fully functional, it does make it a bit of a pain for those of us who intend to build servers - we have to disable the original before installing a new package. :-/ Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Sat, 15 Apr 2000, Joe Greco wrote: Chuck, Please go back and read what I _wrote_. Your response assumes I made I've got your message, I quoted it fully in my first response. You asked to "Remove Sendmail from the base system", and that's a direct quote, Joe. Yes. That doesn't mean that it can't come with FreeBSD... manpages, games, proflibs, even X11, none of those are part of the base system, but people find their way to installing them. Somehow. Also, you've completely ignored that there was a latter half to that sentence. "Hmm." I love creative quoting, and I really have an aversion to being made to say something that I didn't, like "let's force users to choose a mailer". -- ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Fri, Apr 14, 2000 at 05:21:24PM -0500, Joe Greco wrote: Remove Sendmail from the base system - or, at least, make it a "package" that is removable with the package management tool. Then be able to add another mailer (or an updated Sendmail) in its place. Ideally, Sendmail would be available as a package for installation as part of the base system, just like games or info or proflibs. Sounds all basically like a good idea to have different choices for a MTA. But I don't like _basic_ system functionalities to be out sourced completely to ports. Two examples: If I give people a FreeBSD-STABLE snapshot CD, I'd like to give them a complete Unix, and for me a MTA belongs to a basic package. If I want to do a complete upgrade of all of my system ports, because I come to the conclusion - I installed to much experimental crap and don't get it sorted out manually - or I want to upgrade everything to the latest and greatest I don't want to kill my MTA (sendmail) by performing a rm -rf /usr/local/* action. FreeBSD - as is - has all the basic system functionality in the base system and I wouldn't like to have a "neutral" "castrated" Unix just for the sake, that you can start later to customize things like sendmail and maybe other things I would love to see this happen with other components of the system as well, such as BIND. definitively not. I hate the Linux way to have a puzzle system. Could we please still agree on a base system that is complete, so that SNAP CD's still represent a complete BSD without having to create additional ports ??? Again FreeBSD != Linux. While it is fantastic that FreeBSD comes out of the box so fully functional, it does make it a bit of a pain for those of us who intend to build servers - we have to disable the original before installing a new package. :-/ Well ... for that purpose I'd vote for the following: a) make more NO_ (sendmail, bind, whatever) knobs in /etc/make.conf as needed b) make the Makefiles in the install target more complete by removing (old) occurrencies of sendmail, bind, if such a NO_XXX knob has been set. Then you get such an ISP server as you like after a make world session c) Split FreeBSD packaging any further (bin, man, doc, compat,...) Add something like a package internet (sendmail, bind, ...) Then you can install a sendmail, DNS free system as you like. But I wouldn't for a generally castrated BSD. -- Andreas Klemm http://people.FreeBSD.ORG/~andreas http://www.freebsd.org/~fsmp/SMP/SMP.html powered by Symmetric MultiProcessor FreeBSD New APSFILTER 533 and songs from our band - http://people.freebsd.org/~andreas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
At 2:44 PM -0400 2000/4/9, Patrick Bihan-Faou wrote: The advantage would be that we can have a fairly decent qmail configuration using the standard make world feature. Is there any interest in that kind of work ? Considering the number of qmail-specific pieces that need to be installed to support it (and the resulting domino effect), the highly negative impacts that qmail is notorious for, and that it is not intended to be a drop-in replacement for sendmail, I would be highly opposed to this change. If we are actively interested in finding a replacement for the open-source sendmail MTA, I would prefer one that was designed from the beginning with security in mind (including going so far as being intended to run in a chroot() environment), is intended to avoid undesirable behaviour as much as possible, and is intended to be a drop-in replacement for sendmail to the greatest degree possible. In other words, if we're going to be replacing sendmail with an alternative MTA, I'd prefer postfix over qmail, and I believe I can marshall some pretty strong arguments for that position. Perhaps it's time to revisit something I proposed several years ago. Remove Sendmail from the base system - or, at least, make it a "package" that is removable with the package management tool. Then be able to add another mailer (or an updated Sendmail) in its place. Ideally, Sendmail would be available as a package for installation as part of the base system, just like games or info or proflibs. I would love to see this happen with other components of the system as well, such as BIND. While it is fantastic that FreeBSD comes out of the box so fully functional, it does make it a bit of a pain for those of us who intend to build servers - we have to disable the original before installing a new package. :-/ -- ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Fri, Apr 14, 2000 at 05:21:24PM -0500, Joe Greco wrote: While it is fantastic that FreeBSD comes out of the box so fully functional, it does make it a bit of a pain for those of us who intend to build servers - we have to disable the original before installing a new package. :-/ man mailwrapper No, that's not what I'm talking about. If you want to install the latest Sendmail, what do you do? (hint: it has nothing to do with mailwrapper) I'd like it to be something like: # pkg_delete sendmail; pkg_add sendmail Right now, to do a chrooted sendmail, not only do you have to remove the pre-existing sendmail: # chmod 000 /usr/sbin/sendmail /etc/sendmail.cf (etc etc) but you also have to do some things to install it chrooted someplace safe. Some of us also view the concept of having to actually change executables within the base system as something nearing criminal. I _really_ like the idea of mounting my systems RO and very secure. Changing modes on files doesn't bother me so much, but I'd prefer not to do it. The ideal situation would be where sendmail did not come installed by default. -- ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
At 2:44 PM -0400 2000/4/9, Patrick Bihan-Faou wrote: The advantage would be that we can have a fairly decent qmail configuration using the standard make world feature. Is there any interest in that kind of work ? Considering the number of qmail-specific pieces that need to be installed to support it (and the resulting domino effect), the highly negative impacts that qmail is notorious for, and that it is not intended to be a drop-in replacement for sendmail, I would be highly opposed to this change. If we are actively interested in finding a replacement for the open-source sendmail MTA, I would prefer one that was designed from the beginning with security in mind (including going so far as being intended to run in a chroot() environment), is intended to avoid undesirable behaviour as much as possible, and is intended to be a drop-in replacement for sendmail to the greatest degree possible. In other words, if we're going to be replacing sendmail with an alternative MTA, I'd prefer postfix over qmail, and I believe I can marshall some pretty strong arguments for that position. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
At 5:40 PM -0400 2000/4/9, Patrick Bihan-Faou wrote: Then people that are running a mail server could install either the Sendmail, Postfix, Qmail, Zmail, etc... MTA ports. Sounds like a great idea. The reason why I am doing this is because I DONT want sendmail. The solution that is being implemented sounds like the best way to approach this. I can support this position as well. I don't think we're likely to find consensus on replacing one MTA with another (the community is too diverse for that), so replacing a full-featured MTA with one that has the minimum necessary features for "nullclient" operations and then allowing people to install whatever full-featured MTA they may want seems to be the best alternative. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Integrating QMAIL in the world
Hi, I have integrated the source of qmail so it can be built as part of the "world". I think that it would be nice to have an alternative for the mailer package to be built as part of a make world. What I would like to do is upgrate the "NO_SENDMAIL" variable to a "MAILER_SYSTEM" variable, which could be set to "SENDMAIL" (default), "NONE" or "QMAIL". The advantage would be that we can have a fairly decent qmail configuration using the standard make world feature. Is there any interest in that kind of work ? Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Sun, Apr 09, 2000 at 02:44:25PM -0400, Patrick Bihan-Faou wrote: I have integrated the source of qmail so it can be built as part of the "world". I think that it would be nice to have an alternative for the mailer package to be built as part of a make world. I don't recall the particulars (it's been a while since I've managed a qmail installation), but aren't there issues with qmail's distribution license that would make integrating it into the build tree illegal? As a side note, I don't think it's all that good of an idea to add another MTA to the build tree, but I'm sure others will raise a more substantial argument than I could. -- Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
From: "Jon Parise" [EMAIL PROTECTED] On Sun, Apr 09, 2000 at 02:44:25PM -0400, Patrick Bihan-Faou wrote: I have integrated the source of qmail so it can be built as part of the "world". I think that it would be nice to have an alternative for the mailer package to be built as part of a make world. I don't recall the particulars (it's been a while since I've managed a qmail installation), but aren't there issues with qmail's distribution license that would make integrating it into the build tree illegal? I will contact DJB and find out if this is OK with him. After reading his "license" page, I come to the conclusion that it is a matter of obtaining is approval. He wants to ensure that qmail IS qmail no matter how and where it is installed. As a side note, I don't think it's all that good of an idea to add another MTA to the build tree, but I'm sure others will raise a more substantial argument than I could. Well, qmail is a fairly popular alternative to sendmail. It is supposedly more secure, and definitely easier to configure. I use it exclusively and it would be a lot nicer for me to have it included in the base distribution of FreeBSD. I am sure that other people feel the same. My intent is NOT to start a flame war on MTA's. If nobody is interested and/or the FreeBSD team does not want it, then it will not be included in the tree. It's that simple. I remember some while ago some threads going wild on the subject of MTA. The only reason why I am posting this is that I did the work for some other project I am involved in, and if it can help others, then I'd rather share it. Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
On Sun, Apr 09, 2000 at 02:44:25PM -0400, Patrick Bihan-Faou wrote: I have integrated the source of qmail so it can be built as part of the "world". I think that it would be nice to have an alternative for the mailer package to be built as part of a make world. ... Is there any interest in that kind of work ? I'd say probably not. Peter Wemm is working on kicking Sendmail out of the base system and replacing it with a very simple piece that can do local mail delivery and outgoing SMTP to a relay host -- these are the minimal operational requirements. Then people that are running a mail server could install either the Sendmail, Postfix, Qmail, Zmail, etc... MTA ports. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
- Original Message - From: "David O'Brien" [EMAIL PROTECTED] On Sun, Apr 09, 2000 at 02:44:25PM -0400, Patrick Bihan-Faou wrote: I have integrated the source of qmail so it can be built as part of the "world". I think that it would be nice to have an alternative for the mailer package to be built as part of a make world. ... Is there any interest in that kind of work ? I'd say probably not. Peter Wemm is working on kicking Sendmail out of the base system and replacing it with a very simple piece that can do local mail delivery and outgoing SMTP to a relay host -- these are the minimal operational requirements. Then people that are running a mail server could install either the Sendmail, Postfix, Qmail, Zmail, etc... MTA ports. Sounds like a great idea. The reason why I am doing this is because I DONT want sendmail. The solution that is being implemented sounds like the best way to approach this. Thread closed ? Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Integrating QMAIL in the world
qmail is distributed as "freeware" according to freshmeat.net. They do not define the term, but by my definition, freeware would be freer than the BSD license. * Jon Parise ([EMAIL PROTECTED]) [000409 15:04]: I don't recall the particulars (it's been a while since I've managed a qmail installation), but aren't there issues with qmail's distribution license that would make integrating it into the build tree illegal? -- Hasan Diwan [[EMAIL PROTECTED]] :) Rensselaer Polytechnic Institute Computer Science Department http://forsythe.dhs.org/~hdiwan PGP signature
