Am 20.05.2010 12:33, schrieb Allan McRae:
> Any ideas on this?
>
> -------- Original Message --------
> Subject: [arch-notifications] Core/Extra Cleanup 20-05-2010
> Date: Thu, 20 May 2010 06:24:50 -0400 (EDT)
> From: repomaint@archlinux.org
> Reply-To: List for automated notifications
> <arch-notifications@archlinux.org>
> To: arch-notifications@archlinux.org
>
> Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64
> The following files are missing in the repo
> %FILENAME%

Looks like a broken database entry. But the output doesn't tell us where
exactly it was.

Did this happen more than once?

On 20/05/10 21:16, Thomas Bächler wrote:

Am 20.05.2010 12:33, schrieb Allan McRae:

Any ideas on this?

-------- Original Message --------
Subject: [arch-notifications] Core/Extra Cleanup 20-05-2010
Date: Thu, 20 May 2010 06:24:50 -0400 (EDT)
From: repomaint@archlinux.org
Reply-To: List for automated notifications
<arch-notifications@archlinux.org>
To: arch-notifications@archlinux.org

Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64
The following files are missing in the repo
%FILENAME%


Looks like a broken database entry. But the output doesn't tell us where
exactly it was.

Did this happen more than once?



Only the once. The previous run of the clean-up script ran fine.
There were no commits between them... so I guess this is caused by a
package moving from someones staging dir in that timeframe.

Am 20.05.2010 13:20, schrieb Allan McRae:
>>> Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64
>>> The following files are missing in the repo
>>> %FILENAME%
>>
>> Looks like a broken database entry. But the output doesn't tell us where
>> exactly it was.
>>
>> Did this happen more than once?
>>
>
> Only the once. The previous run of the clean-up script ran fine. There
> were no commits between them... so I guess this is caused by a package
> moving from someones staging dir in that timeframe.

This is where the file name comes from:

filename=$(grep -A1 '^%FILENAME%$' "${pkg}/desc" | tail -n1)

This would mean that the last line of the 'desc' file is %FILENAME% with
no file name following it. I checked the extra x86_64 db, and there is
no such entry. *shrugs*

On 20/05/10 21:25, Thomas Bächler wrote:

Am 20.05.2010 13:20, schrieb Allan McRae:

Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64
The following files are missing in the repo
%FILENAME%


Looks like a broken database entry. But the output doesn't tell us where
exactly it was.

Did this happen more than once?



Only the once. The previous run of the clean-up script ran fine. There
were no commits between them... so I guess this is caused by a package
moving from someones staging dir in that timeframe.


This is where the file name comes from:

filename=$(grep -A1 '^%FILENAME%$' "${pkg}/desc" | tail -n1)

This would mean that the last line of the 'desc' file is %FILENAME% with
no file name following it. I checked the extra x86_64 db, and there is
no such entry. *shrugs*


The next run worked fine.

Am 20.05.2010 15:32, schrieb Allan McRae:
> On 20/05/10 21:25, Thomas Bächler wrote:
>> Am 20.05.2010 13:20, schrieb Allan McRae:
>>>>> Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64
>>>>> The following files are missing in the repo
>>>>> %FILENAME%
>>>>
>>>> Looks like a broken database entry. But the output doesn't tell us
>>>> where
>>>> exactly it was.
>>>>
>>>> Did this happen more than once?
>>>>
>>>
>>> Only the once. The previous run of the clean-up script ran fine. There
>>> were no commits between them... so I guess this is caused by a package
>>> moving from someones staging dir in that timeframe.
>>
>> This is where the file name comes from:
>>
>> filename=$(grep -A1 '^%FILENAME%$' "${pkg}/desc" | tail -n1)
>>
>> This would mean that the last line of the 'desc' file is %FILENAME% with
>> no file name following it. I checked the extra x86_64 db, and there is
>> no such entry. *shrugs*
>
> The next run worked fine.

Pierre noticed svn segfaulting during db-update.

Looking into dmesg, I saw that both svn and bsdtar segfaulted 10 to 20
times a week over the past 4 weeks (logs don't go back further than
that). A bsdtar segfault looks like a likely cause of the above issues.

I updated the kernel from 2.6.33.2 to 2.6.33.4 on both gerolde and
gudrun (.3 and .4 include a huge number of bugfixes) and rebooted. We'll
need to watch if the segfaults still occur.

Am 21.05.2010 10:29, schrieb Thomas Bächler:
> Pierre noticed svn segfaulting during db-update.
>
> Looking into dmesg, I saw that both svn and bsdtar segfaulted 10 to 20
> times a week over the past 4 weeks (logs don't go back further than
> that). A bsdtar segfault looks like a likely cause of the above issues.
>
> I updated the kernel from 2.6.33.2 to 2.6.33.4 on both gerolde and
> gudrun (.3 and .4 include a huge number of bugfixes) and rebooted. We'll
> need to watch if the segfaults still occur.

I just noticed another svn segfault. Where is this coming from? Any ideas?

Am 21.05.2010 19:31, schrieb Aaron Griffin:
> On Fri, May 21, 2010 at 11:54 AM, Thomas Bächler <thomas@archlinux.org> wrote:
>> Am 21.05.2010 10:29, schrieb Thomas Bächler:
>>> Pierre noticed svn segfaulting during db-update.
>>>
>>> Looking into dmesg, I saw that both svn and bsdtar segfaulted 10 to 20
>>> times a week over the past 4 weeks (logs don't go back further than
>>> that). A bsdtar segfault looks like a likely cause of the above issues.
>>>
>>> I updated the kernel from 2.6.33.2 to 2.6.33.4 on both gerolde and
>>> gudrun (.3 and .4 include a huge number of bugfixes) and rebooted. We'll
>>> need to watch if the segfaults still occur.
>>
>> I just noticed another svn segfault. Where is this coming from? Any ideas?
>
> Can you manually run the dbscripts cron jobs? How regular is the segfault?

It was just one since the reboot:

May 21 08:09:36 gerolde kernel: svn[8674]: segfault at ffffffff00000008
ip 00007f3be8142eb3 sp 00007fffb8dccd00 error 4 in
libapr-1.so.0.4.2[7f3be8131000+2c000]

On average, it seems that there were between 2 and 4 segfaults in either
svn or bsdtar per day over the last few weeks.