You are here: Home » Topic » mt-daapd crashes suddenly – disk spindown?

mt-daapd crashes suddenly – disk spindown?

This topic contains 18 replies, has 3 voices, and was last updated by  rpedde 11 years, 11 months ago.

Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
    Posts
  • #47

    politby

    I have a problem with mt-daapd crashing suddenly. This seems to happen at irregular intervals when there is no client connected. So far it has never happened during client activity. Log file shows only:

    2005-04-10 16:17:27: Rescanning database
    2005-04-10 16:19:44: Rendezvous socket closed (daap server crashed?) Aborting.
    2005-04-10 16:19:44: Aborting

    I’m running mt-daapd on an NSLU2 with a Maxtor Onetouch disk. The disk is set to spin down after a certain time of inactivity – IIRC it’s set at one hour. I’m wondering whether the crashes could happen because the disk spins down?

    /POL

    #3229

    rpedde
    Participant

    Possibly. Try turning up the debugging a little.. say -d5, and see what that says.

    #3230

    politby

    rpedde wrote:

    Possibly. Try turning up the debugging a little.. say -d5, and see what that says.

    OK, -d5 adds no additional info about the crash. Last lines from log:

    2005-04-12 01:33:16: Rescanning database
    2005-04-12 01:36:13: Rendezvous socket closed (daap server crashed?) Aborting.
    2005-04-12 01:36:13: Aborting

    There’s quite a long time between disk spin down and the server crashing so maybe that’s not it after all. Can I make the log file even more verbose?

    /POL

    #3231

    politby

    politby wrote:

    rpedde wrote:

    Possibly. Try turning up the debugging a little.. say -d5, and see what that says.

    OK, -d5 adds no additional info about the crash. Last lines from log:

    2005-04-12 01:33:16: Rescanning database
    2005-04-12 01:36:13: Rendezvous socket closed (daap server crashed?) Aborting.
    2005-04-12 01:36:13: Aborting

    There’s quite a long time between disk spin down and the server crashing so maybe that’s not it after all. Can I make the log file even more verbose?

    /POL

    Oops, please disregard, I found that there is also a -d9 option. I’m running it with that option enabled now – will post the results tonight.

    #3232

    politby

    With -d9 debugging, all I get in the log is this:

    2005-04-12 09:48:43: Found /share/hdd/data/public/Music/Power Supply/Bass for the Ground Pounder/16 Just the Bass.mp3
    2005-04-12 09:48:44: Executing: SELECT * FROM songs WHERE path=’/share/hdd/data/public/Music/Power Supply/Bass for the Ground Pounder/16 Just the Bass.mp3′
    2005-04-12 09:48:44: Executing: INSERT INTO updated VALUES (2999)
    2005-04-12 09:48:46: Processing rendezvous message
    2005-04-12 09:48:46: Rendezvous socket closed (daap server crashed?) Aborting.
    2005-04-12 09:48:46: Aborting

    Does this indicate a problem with this specific file? If so, I can try it again and see if it crashes at the same file every time.

    /POL

    #3233

    rpedde
    Participant

    Might be the song, although I’d tend to doubt it.

    As a worst case, you could always delete the songs.db and see what it does. On the nightlies, all the database code is new. Chances of crashy stuff is real good. I’ll have to add more debugging there to see what’s up.

    #3234

    politby

    rpedde wrote:

    Might be the song, although I’d tend to doubt it.

    As a worst case, you could always delete the songs.db and see what it does. On the nightlies, all the database code is new. Chances of crashy stuff is real good. I’ll have to add more debugging there to see what’s up.

    New songs database – there is no change, crash still happens and I’ve also verified that it’s not tied to a specific song.

    /POL

    #3235

    rpedde
    Participant

    Okay…

    I’ve pushed all my packages up to unslung, and it looks like they made this mornings build, so I’m going to repackage a slug ipk with latest libraries and whatnot.

    There have also been quite a few fixes since the 3/20 snap, so that may just be the fix.

    #3236

    rpedde
    Participant

    new slug packages are up.

    Give that a shot.

    — Ron

    #3237

    politby

    OK, this is probably a stupid question – I’m new to these embedded linuxes – but my slug won’t let me uninstall mt-daapd; it just returns a “no packages removed”.
    You indicate that the old version must be installed before installing a newer one, so how should I force an uninstall of the old version?

    thanks,
    /POL

    #3238

    velociped
    Participant

    Just curious, but what command did you issue to attempt the removal?

    The correct syntax is


    ipkg remove mt-daapd

    If that is the command you used, you may have to resort to manual removal. The installed files and their respective paths are listed on the package page for mt-daapd at the slug site – about halfway down the page.

    Remember to backup your configuration file.

    Should you need to resort to manual removal, you will likely need to force a subsequent installation.

    Herman

    #3239

    politby

    OK, I did a manual remove and then installed the April 14, version of the slug package. This install went fine.

    But the crash still happens in exactly the same way. The funny thing is that it runs great for several hours, no re-buffering, no errors or anything.
    I started the server at 18.53 yesterday and it ran until 01.31 this morning – that’s almost 6 hours – until it crashed. I’m now running it with -d9 and just a few usic files to see if this version produces any more useful error output. Will post the results.

    I’m considering going back to the stable version; would re-flashing the slug, reinstalling unslung and then mt-daapd ensure I’m back to a fresh start?

    regards,
    P-O

    #3240

    velociped
    Participant

    …would re-flashing the slug, reinstalling unslung
    and then mt-daapd ensure I’m back to a fresh start?

    That would definitely get you back to square one. However, I am thinking that going to that extreme may be overkill and only provides a slightly better than average chance of restoring stability.

    I say that, because this this thread has been active on the NSLU2-linux list for the past couple of days. It seems to suggest a generalized reliability problem involving the combination of an NSLU2 and Maxtor OneTouch drives.

    Your posting history suggests that you only recently (04 April) began using mt-daapd to broadcast your DAAP share and have done so from the slug all along. The history also suggests that you have been experiencing some degree of difficulty with this set-up all along. I have to wonder whether it is somehow your hardware combination which is more at fault than the daemon versioning.

    Another obeservation…Other than your post on 12 April (current thread) containing the debug level nine log extract, it would appear that most of your crashes occur during an automatic rescan of the database. Much as it may be a feature you are interested in preserving, you may want to consider turning the auto-rescan off for a while and see if the stability improves. It may be that the Maxtor drive is spinning down between scans and some aspect of the interaction between the three (the slug, the Maxtor drive and the daemon) is causing the daemon to crash.

    Herman

    #3241

    politby

    Herman, thanks for your comments, very helpful. I ran mt-daapd with a music directory of just 17 songs, and it ran successfully for 7 hours withour crashing, so may be some combination of the large number of songs (=long rescan times) and the Maxtor drive spinning down.

    I’ve now turned off the autoscan and will let it run until tomorrow morning to see what happens.

    I guess I don’t really need the auto scan, I don’t add songs that often so I can just do a rescan via the web interface.

    /P-O

    #3242

    rpedde
    Participant

    Aha. *that* sounds like a memory leak.

    My guess is that it’s slowly leaking memory on rescans — with frequent rescans on lots of files, it would cause more memory loss, until the slug runs out of memory and the OOM killer reaps it.

    I haven’t run memory or fd leak checks on it yet, but I bet that’s it. I’ll valgrind out the obvious memory leaks this weekend.

    — Ron

    obtw – to go back to stable, just “ipkg remove mt-daapd”, “ipkg update”, and “ipkg install mt-daapd”. That should pull latest version from the stable feeds. (0.2.1.1-1, although I might backport that cover-art fd leak patch into a 0.2.1.1-2 if I get to it this weekend).

    The last “stable” snapshot was the the march 5th snapshot. If you want transcoding, but want a more stable db backend, that’s the one to use. After march 5th, it’s sqlite only, and a huge refactoring of the whole program. If you aren’t using transcoding, there really isn’t a reason not to use the stable version in unslung, unless you just want to play with it. Just be aware that the stability isn’t there like it is in stable.

    Hence the name, i guess. 🙂

Viewing 15 posts - 1 through 15 (of 19 total)

The forum ‘General Discussion’ is closed to new topics and replies.