On Thursday 04 February 2010, 10:48:39 Hans-Peter Jansen wrote:
> On Thursday 04 February 2010, 07:49:12 sf...@users.sourceforge.net 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?= <pant...@balabit.hu>
> > Date: Fri, 6 Nov 2009 12:33:55 +0100
> > Subject: kernel oops during chown, NULL pointer dereference
> > To: aufs-users@lists.sourceforge.net
> > Message-Id: <a65c0740-92a7-4454-9eb3-497a78a5d...@balabit.hu>
>
> 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

Reply via email to