Turns out it does happened again a few times.
We have two servers both running s3ql and noticed the following crashes
Aug 10 21:43:32 cxseabackup01 kernel: [30464.161319] INFO: task
s3qlcp:18569 blocked for more than 120 seconds.
Aug 10 21:43:32 cxseabackup01 kernel: [30464.162118] Tainted: P
OX 3.13.0-88-generic #135-Ubuntu
Aug 10 21:43:32 cxseabackup01 kernel: [30464.162929] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163890] s3qlcp D
ffff88062fc33180 0 18569 18568 0x00000000
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163898] ffff88060f09fd00
0000000000000082 ffff880026906000 0000000000013180
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163906] ffff88060f09ffd8
0000000000013180 ffff880026906000 ffff880102fadda8
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163912] ffff880102faddac
ffff880026906000 00000000ffffffff ffff880102faddb0
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163919] Call Trace:
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163935] [<ffffffff8172e2f9>]
schedule_preempt_disabled+0x29/0x70
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163942] [<ffffffff81730135>]
__mutex_lock_slowpath+0x135/0x1b0
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163947] [<ffffffff817301cf>]
mutex_lock+0x1f/0x2f
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163956] [<ffffffff811e67e2>]
vfs_setxattr+0x62/0xc0
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163962] [<ffffffff811e696e>]
setxattr+0x12e/0x1c0
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163971] [<ffffffff811d1342>]
? final_putname+0x22/0x50
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163977] [<ffffffff811d1549>]
? putname+0x29/0x40
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163982] [<ffffffff811d209f>]
? user_path_at_empty+0x5f/0x90
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163988] [<ffffffff811c36d9>]
? __sb_start_write+0x49/0xe0
Aug 10 21:43:32 cxseabackup01 kernel: [30464.163994] [<ffffffff811e6bff>]
SyS_setxattr+0x8f/0xe0
Aug 10 21:43:32 cxseabackup01 kernel: [30464.164002] [<ffffffff8173a4dd>]
system_call_fastpath+0x1a/0x1f
Aug 10 21:45:32 cxseabackup01 kernel: [30584.095075] INFO: task
s3qlcp:18569 blocked for more than 120 seconds.
Aug 10 21:45:32 cxseabackup01 kernel: [30584.095876] Tainted: P
OX 3.13.0-88-generic #135-Ubuntu
Aug 10 21:45:32 cxseabackup01 kernel: [30584.096664] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097107] s3qlcp D
ffff88062fc33180 0 18569 18568 0x00000000
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097115] ffff88060f09fd00
0000000000000082 ffff880026906000 0000000000013180
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097123] ffff88060f09ffd8
0000000000013180 ffff880026906000 ffff880102fadda8
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097129] ffff880102faddac
ffff880026906000 00000000ffffffff ffff880102faddb0
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097137] Call Trace:
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097152] [<ffffffff8172e2f9>]
schedule_preempt_disabled+0x29/0x70
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097159] [<ffffffff81730135>]
__mutex_lock_slowpath+0x135/0x1b0
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097164] [<ffffffff817301cf>]
mutex_lock+0x1f/0x2f
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097173] [<ffffffff811e67e2>]
vfs_setxattr+0x62/0xc0
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097179] [<ffffffff811e696e>]
setxattr+0x12e/0x1c0
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097188] [<ffffffff811d1342>]
? final_putname+0x22/0x50
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097194] [<ffffffff811d1549>]
? putname+0x29/0x40
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097199] [<ffffffff811d209f>]
? user_path_at_empty+0x5f/0x90
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097205] [<ffffffff811c36d9>]
? __sb_start_write+0x49/0xe0
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097211] [<ffffffff811e6bff>]
SyS_setxattr+0x8f/0xe0
Aug 10 21:45:32 cxseabackup01 kernel: [30584.097219] [<ffffffff8173a4dd>]
system_call_fastpath+0x1a/0x1f
On Friday, July 15, 2016 at 1:07:39 PM UTC-7, Peter Auyeung wrote:
>
>
>
> On Friday, July 15, 2016 at 12:00:34 PM UTC-7, Nikolaus Rath wrote:
>>
>> On Jul 14 2016, Peter Auyeung <[email protected]> wrote:
>> > We noticed s3ql crashed during the nightly metadata dump....
>> > This is the first time happened after one month of s3ql in use. Is this
>> a
>> > bug?
>> >
>> > (src/s3ql/deltadump.c:3922)#012 File "src/s3ql/deltadump.pyx", line
>> 186,
>> > in s3ql.deltadump.SQLITE_CHECK_RC
>> > (src/s3ql/deltadump.c:1820)#012apsw.BusyError: database is locked
>>
>> Could be, but could also be the result of another process messing with
>> the cached metadata. Can you reproduce the problem?
>>
>> Not yet...just done for fsck will see if it happens again.
>
> Thanks
> Peter
>
--
You received this message because you are subscribed to the Google Groups
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
