download-dir is reset after transmission daemon crash in settings.json

[krx]

If the transmission daemon crashes, the "download-dir" setting in the settings.json is reset on new daemon startup.

The original:
    "download-dir": "\/mmc\/transmission\/downloads",
After the startup after the crash:
    "download-dir": "\/\/Downloads",

Of course, the second option is bad, and transmission does not load any torrents, the list is empty. The solution is to kill deamon, correct the directive, restart daemon.

[charles]

I can't reproduce this:

[charles@sita ~]$ grep \"download-dir ~/.config/transmission/settings.json 
    "download-dir": "\/tmp", 
[charles@sita ~]$ pkill -9 transmission
[charles@sita ~]$ grep \"download-dir ~/.config/transmission/settings.json 
    "download-dir": "\/tmp", 

Please answer these questions:

• Is this reproducible?
• If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

[krx]

Replying to charles:

I can't reproduce this:

[charles@sita ~]$ grep \"download-dir ~/.config/transmission/settings.json 
    "download-dir": "\/tmp", 
[charles@sita ~]$ pkill -9 transmission
[charles@sita ~]$ grep \"download-dir ~/.config/transmission/settings.json 
    "download-dir": "\/tmp", 

Please answer these questions:

• Is this reproducible?
• If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

I can not tell at this moment, as Transmission is not used (HDD was deattached with content and went with me to holidays). When I get back, I can check. Should I check 1.75, or first try to upgrade to latest Optware version, and then check?

Nonetheless, Transmission is to heavy on my Asus :-(, as I cannot let to switch off encryption due to the local situation with the BSA-style organizations.

[charles]

TBH I'm not interested on any testing reports that aren't from a fresh build of Transmission. There's no point in tracking down bugs in 1.75 if they've been fixed since then.

[krx]

Replying to charles:

TBH I'm not interested on any testing reports that aren't from a fresh build of Transmission. There's no point in tracking down bugs in 1.75 if they've been fixed since then.

OK, understood. Let us leave this issue status suspended and low priority. I hope I will be able to check in a few weeks time. Perhaps the problem is in the optware build, because it offen differs from the vanila linux distros. Perhaps this problems will not repeat itselft either.

[krx]

Replying to charles:

TBH I'm not interested on any testing reports that aren't from a fresh build of Transmission. There's no point in tracking down bugs in 1.75 if they've been fixed since then.

Still happens @1.92 in optware :-(

This happens when the transmission crashes, or after the crash, just when starting 1st time.

I will try to lookup if this is A or B, if there will be more crashes.

[charles]

Please answer these questions:

• Is this reproducible?
• If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

[krx]

Replying to charles:

Please answer these questions:

• Is this reproducible?

In my situation - yes, 100% of the time.

• If so, what specific steps should we take to recreate this bug?

1. Get ASUS WL-500GPv2.
2. Flash with DD-WRT:

DD-WRT v24-sp2 mega (c) 2009 NewMedia?-NET GmbH Release: 10/10/09 (SVN revision: 13064)

3. Install optware on some flash stick on 1st USB port, add swap partition on that stick. (now I use some generic 1 GB stick, swap is 128 MB). Atach USB hard disk for the torrents/files storage to the second port.
4. Add many torrents - ~40 at least, and at least a few in download mode.
5. Start everything. If at least one is in "Verifying" status, system loads starts to rise, memory usage increases, then kicks-in paging. If all are OK, wait for the some external event, which will make any of the downloading torrents files dirty (mains power off is the main culprit).
6. The last messages you get from the foreground running Transmission daemon are like this:

[20:12:16.548] Saved "/mmc/transmission/config/resume/fordworkshop.iso.6d1598c6866ad4c7.resume" (bencode.c:1645)
[20:12:16.605] Saved "/mmc/transmission/config/stats.json" (bencode.c:1645)

(please have in mind, these lines are not generated at the same moment, when the crash occurs, it is only the last lines of the normal daemon working output)

and THEN:

"Segmentation fault" in the output, while dmesg notes this:

__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
journal_write_metadata_buffer: ENOMEM at get_unused_buffer_head, trying again.
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
ENOMEM in journal_alloc_journal_head, retrying.
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
journal_write_metadata_buffer: ENOMEM at get_unused_buffer_head, trying again.
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

• I know, that this is of little use. But I do not have any debug tools or the required skills to debug in this platform, sory :-( Only post-mortem evidence, thats all.

Daemon process closes, torrents which were in the download mode now have dirty files, if you start everything at once - repeat from step 5. If you stop everyting, except one (by-one) Verify tasks, after each of these finishes, everything works OK.

I do not know if the problem is in the Transmission, or DD-WRT, or memory shortage (not designed to run with 32MB RAM), or etc., but the problem is there. It seems, that I/O overabundance while verifying is the killer. I only see workaround for the time being - ​http://trac.transmissionbt.com/ticket/3087.

From my POV, workaround would be logical - if the system bottleneck is I/O bound, it is much more efective to do sequential read&hash on the startup, neglecting any parallel I/O, and only after this task is finished, start parallel I/O for normal seed/leach mode.

Regards, and hope this helps.

[charles]

I've given more thought to this ticket, but am still unsure what to do with it. In the year since the ticket was opened, nobody else has reported this bug. I don't have any experience with DD-WRT, and it appears that DD-WRT doesn't have the debug tools for you to add more diagnosis. (Your summary so far has been very descriptive BTW.)

If you upgrade your DD-WRT system and Transmission software to their latest versions, does the problem persist? :)

[charles]

krx: ping?

[charles]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future.