Hi Serge:
Thanks a lot for your comment - the getrlimit() behaviour is indeed
puzzling!
Having a closer look at my system, I believe I found the reason, though.
The Ubuntu upgrade from 10.10 to 11.04 failed to change the bootloader
config (yaboot on Mac's) to boot the kernel coming with the new
Marking invalid based on reporter feedback.
** Changed in: postfix (Ubuntu)
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix in Ubuntu.
https://bugs.launchpad.net/bugs/774852
Title:
Postfix
Fascinating. The getrlimit kernel code should never return -EPERM, nor
lead to any selinux or apparmor calls fwiw. I'd be curious to see an
strace of local. If in fact a call to the kernel/sys.c:getrlimit() is
returning -EPERM, then the arguments passed to do_prlimit are being
corrupted along
Marking this 'high' importance as I think it falls into 'Has a severe
impact on a small portion of Ubuntu users'
** Changed in: postfix (Ubuntu)
Importance: Undecided = High
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix
Tried to reproduce this on i386, but couldn't.
Albrecht, it's a long shot, but could you try this modified getrlimit
test program? (replace 112 and 105 with the gid and uid for postfix,
respectively, if they are different on your system).
#include sys/resource.h
#include stdio.h
#include
Side note: the following code runs fine on my box:
code
#include sys/resource.h
#include stdio.h
int main(int argc, char **argv)
{
struct rlimit rl;
int result;
result = getrlimit(RLIMIT_NOFILE, rl);
printf(%d - %d %d\n, result, (int) rl.rlim_cur, (int) rl.rlim_max);
I am having the same issues on my boxes, running i386
This is what I found in the mail.log
May 12 08:45:50 vps594 postfix/postdrop[6857]: fatal: getrlimit: Operation not
permitted
May 12 08:45:51 vps594 postfix/sendmail[6856]: warning: command
/usr/sbin/postdrop -r exited with status 1
May 12
I re-compiled the package with some extra information (added
strerror(errno) at varoius places). The reason for the failing 'local'
process is in src/util/open_limit.c, where the call to getrlimit (yes,
*not* setrlimit!) fails with EPERM. That's really strange!
BTW, I don't have SElinux
apport information
** Tags added: apport-collected natty
** Description changed:
Binary package hint: postfix
Ubuntu version: Ubuntu 11.04
Package version: postfix 2.8.2-1ubuntu1
System: PowerMac G4 Silver
After an update of my box from 10.10 to 11.04, the 'local' delivery
Hi Clint:
Asking Google about this issue, I found some complaints from Gentoo
users related to glibc 2.13 and pre-linking [1]. However, the prelink
package is not installed on my box, and installing it doesn't change
anything. It might have been a build issue, though.
An other source might be
Albrecht, I'm getting no such failure on my amd64 11.04 machines, I
wonder if this is a problem for powerpc only.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix in Ubuntu.
https://bugs.launchpad.net/bugs/774852
Title:
Albrecht, it would help us determine the status of this bug if you could
run
sudo apport-collect 774852
in a terminal
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix in Ubuntu.
https://bugs.launchpad.net/bugs/774852
12 matches
Mail list logo
