Le 13/05/13 15:32, sf...@users.sourceforge.net a écrit :
> Hi,
>
> Thank you for additional info.
>
> Francois Goudal:
>> You can find below all the strace related to /var/spool while starting=20
>> squid, up to the error caused by aufs :
>>
>> root@wheezy:~# strace squid -D -YC -N 2>&1 | grep spool
> :::
>> open("/var/spool/squid/swap.state",=20
>> O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0644) =3D 18
> :::
>> open("/var/spool/squid/swap.state.new",=20
>> O_WRONLY|O_CREAT|O_TRUNC|O_APPEND|O_LARGEFILE, 0644) =3D -1 EIO=20
>> (Input/output error)
> Ok.
> First open(2) doesn't specify O_TRUNC, so copyup doesn't happen.
> But next open(2) has O_TRUNC and aufs starts copyup.
>
>
>> You can find attached the debug trace. It's the output of the dmesg=20
>> command right after booting my system (squid is auto-started by init=20
>> scripts).
>> I hope it helps.
> The debug log tells that the error happend in copying-up "spool".
> By the recent change, aufs copyup issues "rename" operation internally,
> which is
> - copyup a file from the lower layer to upper as a temporary hidden
> name.
> - sets various attributes to the file on the upper layer.
> - rename the file to the correct name.
>
> This is similar to these commands.
> $ cp ro/fileA rw/tmp_fileA
> $ chmod, chown brabra rw/tmp_fileA
> $ mv rw/tmp_fileA rw/fileA
>
> And the debug output shows the error happened in the last rename (mv)
> operation.
> Also it shows the root dir of the upper layer has a sticky bit set. Is
> this intentional? Did aufs produce a warning about the ownership and the
> bits at the mount-time? Or did you specify the "noverbose" option or
> something?
>
I have nowarn_perm as a mount option. I tried removing it, and indeed, I
get a warning about the permissions when mounting this aufs on /var
With regards to the sticky bit, I didn't set it myself. So if there is a
sticky bit, it was set by Debian themselves.
> While it may not be a problem, it looks weird to me. As you might know,
> the sticky bit of a dir restricts a delete operation, and the rename
> contains the delete operation semantically.
> But also the capability feature affects this behaviour. The debug log
> doesn't print anything about the capability, so I am not sure whether
> the sticky bit is the cause of the problem.
>
> Before I develop and send you more debug patch, it is worth to try
> dropping the sticky bit from your upper layer. Would you try?
> Of course as long as the sticky bit is intentinally set, we should go
> another debugging way. In this case, I'd ask you why the sticky bit is
> necessary.
>
I would try, but I have tried to find that sticky bit, but can't find it :
root@wheezy:~# ls -ld /var
drwxr-xr-x 12 root root 4096 May 7 23:05 /var
root@wheezy:~# ls -ld /var/spool
drwxr-xr-x 7 root root 4096 May 7 23:31 /var/spool
root@wheezy:~# ls -ld /var/spool/squid
drwxr-x--- 18 proxy proxy 4096 May 13 21:54 /var/spool/squid
(these were done without the aufs mount, so they reflect the real
"state" of my upper layer)
The only sticky bit I have here is on /var/spool/samba
And samba also starts on bootup, at "the same time" as squid.
So I wonder if maybe samba starts, tries to copyup something on
/var/spool/samba, then this fails and screws the whole /var/spool tree,
and then squid fails to start as a consequence.
I will try to disable samba from the boot scripts and see if this
"solves" the problem.
> On the other hand, aufs copyup may have to support such case I am
> afraid... Still thinking...
>
>
> J. R. Okajima
Thank's !
--
Francois GOUDAL
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
