On Thursday 04 February 2010, 10:48:39 Hans-Peter Jansen wrote:
> On Thursday 04 February 2010, 07:49:12 [email protected] wrote:
> > "Hans-Peter Jansen":
> >
> > How did you set it up? I need to know about it, particulary the order
> > of - mounting aufs
> > - telling autofs that /net is the mount point.
>
> Sorry, it was late yesterday evening..
>
> aufs2, compiled with default options.
> /read-write NFS RW mount
> /read-only NFS RO mount
> NFS-RW and NFS-RO branches mounted in initrd (xino on tmpfs) on /mnt
> which is switched to / at the end of initrd phase. (diskless NFS root
> setup) Everything besides /home and /work comes from this aufs mount.
>
> > > and Postfix does not work:
> > >
> > > Call Trace:
> > > [<f9489066>] aufs_setattr+0xfa/0x6c4 [aufs]
> > > [<c0198388>] fnotify_change+0x196/0x2f3
> > > [<c0184e47>] sys_fchmod+0x97/0xcb
> > > [<c0103a0d>] sysenter_do_call+0x12/0x21
> > > [<ffffe430>] 0xffffe430
> >
> > If the AppArmor patch is applied to your kernel source, it is a known
> > problem. Please refer to the posts to aufs-users ML and check whether
> > the problem is same or not.
> >
> > From: =?iso-8859-2?Q?T=F3th_L=E1szl=F3_Attila?= <[email protected]>
> > Date: Fri, 6 Nov 2009 12:33:55 +0100
> > Subject: kernel oops during chown, NULL pointer dereference
> > To: [email protected]
> > Message-Id: <[email protected]>
>
> Ahh, cool, found it, applied it, will test now...
Okay, close, but no cigar. After applying the aforementioned modifications,
the segfault vanishes. Now postfix seems to start fine, but:
Feb 4 22:21:09 x130 postfix/postfix-script[6130]: starting the Postfix mail
system
Feb 4 22:21:09 x130 postfix/master[6131]: fatal: fifo_listen: fchmod
public/pickup: Operation not permitted
the master process fails, and postfix really is dysfunctional. Sure, it's
somewhat overkill, but it's the distro's default smtp daemon and the setup
is using it in a nullclient config (e.g. store and forward, no local
delivery.
Here's the relevant trace.
7621 geteuid32() = 0
7621 setresgid32(-1, 51, -1) = 0
7621 setgroups32(1, [51]) = 0
7621 setresuid32(-1, 51, -1) = 0
7621 time(NULL) = 1265319834
7621 send(3, "<22>Feb 4 22:43:54 postfix/master[7621]: set_eugid: euid 51
egid 51", 68, MSG_NOSIGNAL) = 68
7621 unlink("public/pickup") = 0
7621 mknod("public/pickup", S_IFIFO|0622) = 0
7621 open("public/pickup", O_RDWR|O_NONBLOCK) = 12
7621 poll([{fd=12, events=POLLIN}], 1, 0) = 0 (Timeout)
7621 fstat64(12, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
7621 fchmod(12, 0622) = -1 EPERM (Operation not permitted)
7621 time(NULL) = 1265319834
7621 send(3, "<18>Feb 4 22:43:54 postfix/master[7621]:
fatal: fifo_listen: fchmod public/pickup: Operation not permitted", 107,
MSG_NOSIGNAL) = 107
Indeed, while /var/spool/postfix/public/ usually looks like this:
# l /var/spool/postfix/public/
insgesamt 4
drwx--x--- 2 postfix maildrop 79 17. Jan 02:20 ./
drwxr-xr-x 16 root root 4096 3. Dez 2008 ../
srw-rw-rw- 1 postfix postfix 0 17. Jan 02:20 cleanup=
srw-rw-rw- 1 postfix postfix 0 17. Jan 02:20 flush=
srwxrwxrwx 1 root root 0 16. Nov 2004 lmtp=
prw--w--w- 1 postfix postfix 0 17. Jan 02:20 pickup|
prw--w--w- 1 postfix postfix 0 17. Jan 02:20 qmgr|
srw-rw-rw- 1 postfix postfix 0 17. Jan 02:20 showq=
the failure case looks like this:
# l /var/spool/postfix/public/
insgesamt 0
drwx--x--- 2 postfix maildrop 19 4. Feb 22:43 ./
drwxr-xr-x 20 root root 56 3. Feb 22:10 ../
prw------- 1 postfix postfix 0 4. Feb 22:43 pickup|
# LANG=C id postfix
uid=51(postfix) gid=51(postfix) groups=51(postfix)
You mentioned in the thread, that NFS may also uses ->private_data.
Could this be the reason for this issue?
Thanks,
Pete
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
