Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transmission fails to start #2484

Closed
GulyFMG opened this issue Feb 1, 2019 · 16 comments
Closed

Transmission fails to start #2484

GulyFMG opened this issue Feb 1, 2019 · 16 comments
Assignees
Labels
Solution available 🥂 Definite solution has been done
Milestone

Comments

@GulyFMG
Copy link

GulyFMG commented Feb 1, 2019

ADMIN EDIT

Solution: #2484 (comment)


Required Information:

DietPi version | #!/bin/bash
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=20
G_DIETPI_VERSION_RC=6
G_GITBRANCH=master
G_GITOWNER=Fourdee

Distro version | 9.6

Kernel version | Linux blacksun 4.14.80-v7+ #1161 SMP Mon Nov 12 18:51:43 GMT 2018 armv7l GNU/Linux

SBC device | RPi 3 Model B+ (armv7l)

Power supply used 5V

SDcard used | SanDisk 16Gb

Additional Information (if applicable):

Software title | Transmission

Steps to reproduce:

Fresh install of transmission

Expected behaviour:
after boot transmission daemon should start
Actual behaviour:
Transmission daemon Fails
Extra details:

[FAILED] DietPi-Services | transmission-daemon failed (Result: exit-code) since Fri 2019-02-01 03:06:47 WET; 9s ago
● transmission-daemon.service - Transmission BitTorrent Daemon
Loaded: loaded (/lib/systemd/system/transmission-daemon.service; disabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/transmission-daemon.service.d
└─dietpi-group.conf
Active: failed (Result: exit-code) since Fri 2019-02-01 03:06:47 WET; 9s ago
Process: 1486 ExecStop=/bin/kill -s STOP $MAINPID (code=exited, status=1/FAILURE)
Process: 1484 ExecStart=/usr/bin/transmission-daemon -f --log-error (code=exited, status=1/FAILURE)
Main PID: 1484 (code=exited, status=1/FAILURE)

Feb 01 03:06:47 blacksun systemd[1]: Starting Transmission BitTorrent Daemon...
Feb 01 03:06:47 blacksun transmission-daemon[1484]: [2019-02-01 03:06:47.957] JSON parse failed in /var/lib/transmission-daemon/.config/transmission-daemon/settings.json at pos 468: STRAY_TOKEN -- remaining text ""cache-size-mb":"
Feb 01 03:06:47 blacksun transmission-daemon[1484]: [2019-02-01 03:06:47.957] transmission-daemon Error loading config file -- exiting. (daemon.c:693)
Feb 01 03:06:47 blacksun systemd[1]: transmission-daemon.service: Main process exited, code=exited, status=1/FAILURE
Feb 01 03:06:47 blacksun systemd[1]: transmission-daemon.service: Control process exited, code=exited status=1
Feb 01 03:06:47 blacksun systemd[1]: Failed to start Transmission BitTorrent Daemon.
Feb 01 03:06:47 blacksun systemd[1]: transmission-daemon.service: Unit entered failed state.
Feb 01 03:06:47 blacksun systemd[1]: transmission-daemon.service: Failed with result 'exit-code'.

@Fourdee Fourdee added this to the v6.21 milestone Feb 1, 2019
@Fourdee Fourdee self-assigned this Feb 1, 2019
@Fourdee
Copy link
Collaborator

Fourdee commented Feb 1, 2019

@GulyFMG

/var/lib/transmission-daemon/.config/transmission-daemon/settings.json at pos 468: STRAY_TOKEN -- remaining text ""cache-size-mb":"

Many thanks for the report 👍

Test RPi 3B+:

  • 🈯️ Fresh install
  • 🈯️ Reinstall

Unable to replicate our end.

Lets fix the file manually:

  • Edit file
nano /var/lib/transmission-daemon/.config/transmission-daemon/settings.json
  • Find the entry cache-size-mb and replace the line with "cache-size-mb": 97,
  • Save changes with CTRL+X then Y, then enter
  • Restart services with dietpi-services restart

@GulyFMG
Copy link
Author

GulyFMG commented Feb 1, 2019

Humm that's strange, just to put in context after the error i uninstall transmission via dietpi software and delete the folder /var/lib/transmission-daemon/ just to make sure i search for the file settings.json and none was found, after i installed again transmission and it failed again, already solved on my end i just delete the file and let transmission recreate it again and change the value from there.

If you guys can reproduce it maybe we can close the issue. Thanks for this.

Did a new reinstall and had the same error again:

root@blacksun:/# dietpi-services status
[ OK ] DietPi-Services | Root access verified.

DietPi-Services
─────────────────────────────────────────────────────
Mode: status

[ OK ] DietPi-Services | avahi-daemon active (running) since Fri 2019-02-01 19:53:37 WET; 1min 47s ago
[ OK ] DietPi-Services | nmbd active (running) since Fri 2019-02-01 19:53:37 WET; 1min 47s ago
[ OK ] DietPi-Services | smbd active (running) since Fri 2019-02-01 19:53:37 WET; 1min 46s ago
[FAILED] DietPi-Services | transmission-daemon failed (Result: exit-code) since Fri 2019-02-01 19:53:38 WET; 1min 46s ago
● transmission-daemon.service - Transmission BitTorrent Daemon
Loaded: loaded (/lib/systemd/system/transmission-daemon.service; disabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/transmission-daemon.service.d
└─dietpi-group.conf
Active: failed (Result: exit-code) since Fri 2019-02-01 19:53:38 WET; 1min 46s ago
Process: 9452 ExecStop=/bin/kill -s STOP $MAINPID (code=exited, status=1/FAILURE)
Process: 9450 ExecStart=/usr/bin/transmission-daemon -f --log-error (code=exited, status=1/FAILURE)
Main PID: 9450 (code=exited, status=1/FAILURE)

Feb 01 19:53:38 blacksun systemd[1]: Starting Transmission BitTorrent Daemon...
Feb 01 19:53:38 blacksun transmission-daemon[9450]: [2019-02-01 19:53:38.031] JSON parse failed in /var/lib/transmission-daemon/.config/transmission-daemon/settings.json at pos 468: STRAY_TOKEN -- remaining text ""cache-size-mb":"
Feb 01 19:53:38 blacksun systemd[1]: transmission-daemon.service: Main process exited, code=exited, status=1/FAILURE
Feb 01 19:53:38 blacksun systemd[1]: transmission-daemon.service: Control process exited, code=exited status=1
Feb 01 19:53:38 blacksun systemd[1]: Failed to start Transmission BitTorrent Daemon.
Feb 01 19:53:38 blacksun systemd[1]: transmission-daemon.service: Unit entered failed state.
Feb 01 19:53:38 blacksun systemd[1]: transmission-daemon.service: Failed with result 'exit-code'.

Again if you cant replicate it just close the issue.

@Fourdee
Copy link
Collaborator

Fourdee commented Feb 2, 2019

@GulyFMG

Please can you send me a bug report? I'd like to check the dietpi-software script and system settings.

dietpi-bugreport

@GulyFMG
Copy link
Author

GulyFMG commented Feb 2, 2019

Absolutely, here you have the reference code 0f9fd083-6309-4a19-8582-bdea43b3c0b9.
If there is anything more I can do to help just ask.

@Fourdee
Copy link
Collaborator

Fourdee commented Feb 7, 2019

@GulyFMG

Many thanks, apologies for delay, will check when I can.

@GulyFMG
Copy link
Author

GulyFMG commented Feb 7, 2019

@Fourdee if you need anything more just ask, like i said before, on my side is already solved, running and backed up. 👍

@Fourdee Fourdee modified the milestones: v6.21, v6.22 Feb 7, 2019
@Fourdee
Copy link
Collaborator

Fourdee commented Feb 8, 2019

@GulyFMG

Very stange, code in your bug report matches current install code.

I was unable to find any reason why this occurring, however, I did find a potential hardware failure with your external harddrive:

[  169.079134] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Finalizer: bg 9940: bad block bitmap checksum
[  169.201923] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Finalizer: bg 9941: bad block bitmap checksum
[  169.203157] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Finalizer: bg 9942: bad block bitmap checksum
[  169.204296] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Finalizer: bg 9943: bad block bitmap checksum
[  315.351445] EXT4-fs (sda1): error count since last fsck: 1162
[  315.351460] EXT4-fs (sda1): initial error at time 1531903834: ext4_validate_block_bitmap:389
[  315.351473] EXT4-fs (sda1): last error at time 1549108974: ext4_validate_block_bitmap:387
[ 1601.470181] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm transmission-da: bg 128: bad block bitmap checksum
[ 1601.806753] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm transmission-da: bg 543: bad block bitmap checksum
[ 1601.829876] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm transmission-da: bg 560: bad block bitmap checksum
[ 5005.585647] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Thread Pool Wor: bg 9921: bad block bitmap checksum
[ 5005.586055] EXT4-fs error (device sda1) in ext4_free_blocks:4977: Filesystem failed CRC
[ 5005.586976] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:101: comm Thread Pool Wor: Corrupt inode bitmap - block_group = 9921, inode_bitmap = 325058577
[ 5005.587524] EXT4-fs error (device sda1) in ext4_free_inode:363: Filesystem failed CRC
[ 6082.549930] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Thread Pool Wor: bg 9922: bad block bitmap checksum
[ 6082.550429] EXT4-fs error (device sda1) in ext4_free_blocks:4977: Filesystem failed CRC

You can use dietpi-drive_manager to run a check and repair on the disk.


The only thing it may be, is a failed update, where the dietpi-software script was not correctly updated. We did have issues with updates in v6.20 which are now resolved in v6.21.
I can only suggest trying to update to v6.21, then see if the issue reoccurs after reinstall.

@GulyFMG
Copy link
Author

GulyFMG commented Feb 9, 2019

Thanks for the tip... Already did a drive check and it looks everything is OK now... Do you guys have anything baked in dietpi to check logs? Something like drive manager or dietpi software?

I'm gonna skip this update it breaks a kodi addon for me and it doesn't add anything important.

@GulyFMG GulyFMG closed this as completed Feb 9, 2019
@MichaIng
Copy link
Owner

MichaIng commented Feb 9, 2019

@GulyFMG

Do you guys have anything baked in dietpi to check logs? Something like drive manager or dietpi software?

Nope, journalctl and dmesg provide everything required, doing a good job actually 😃.

I'm gonna skip this update it breaks a kodi addon for me and it doesn't add anything important.

You mean v6.21 does this?? Then it must be some APT package update, since really v6.21 does not change more than fixing a update bug, introduced with v6.20 in some cases.
Might you tell us which Kodi addon it is? Then we might be able to do something about it 🙂.

@GulyFMG
Copy link
Author

GulyFMG commented Feb 10, 2019

PVR IPTV simple client... Yeah dmseg is pretty solid... Started using on my early days of Linux... Thanks for the tip journalctl ready found some more things to tweak.

I did some digging and the addon as updated for a new version and to support kodi 18... Updating kodi now...

@antonionardella
Copy link

The comma is missing in the line before
"upload-limit-enabled": 0
should be
"upload-limit-enabled": 0,
an then remove the last comma from
"umask": 7,
to
"umask": 7

this solves the issue.

@MichaIng
Copy link
Owner

MichaIng commented Mar 5, 2019

Good point. The json parser is very strict. All lines in /etc/transmission-daemon/settings.json require an ending comma and the last lime must not have one. I just replicated the error by removing comma in last line:

root@VM-Stretch:~# journalctl -u transmission-daemon
-- Logs begin at Tue 2019-03-05 00:44:30 CET, end at Tue 2019-03-05 00:53:32 CET. --
Mar 05 00:53:31 VM-Stretch systemd[1]: Stopping Transmission BitTorrent Daemon...
Mar 05 00:53:32 VM-Stretch transmission-daemon[3131]: [2019-03-05 00:53:32.882] JSON parse failed in /var/lib/transmission-daemon/.config/transmission-daemon/settings.json at pos 2272: TRAILING_COMMA -- remaining text "}
Mar 05 00:53:32 VM-Stretch transmission-daemon[3131]: " (variant-json.c:95)
Mar 05 00:53:32 VM-Stretch transmission-daemon[3131]: [2019-03-05 00:53:32.882] Couldn't save temporary file "/etc/transmission-daemon/settings.json.tmp.UhTJk5": Permission denied (variant.c:1280)
Mar 05 00:53:32 VM-Stretch systemd[1]: Stopped Transmission BitTorrent Daemon.
Mar 05 00:53:32 VM-Stretch systemd[1]: Starting Transmission BitTorrent Daemon...
Mar 05 00:53:32 VM-Stretch systemd[1]: transmission-daemon.service: Main process exited, code=exited, status=1/FAILURE
Mar 05 00:53:32 VM-Stretch systemd[1]: transmission-daemon.service: Control process exited, code=exited status=1
Mar 05 00:53:32 VM-Stretch systemd[1]: Failed to start Transmission BitTorrent Daemon.
Mar 05 00:53:32 VM-Stretch systemd[1]: transmission-daemon.service: Unit entered failed state.
Mar 05 00:53:32 VM-Stretch systemd[1]: transmission-daemon.service: Failed with result 'exit-code'.

@GulyFMG
This indeed is/was also the reason in your case as your log as well shows:

Error loading config file -- exiting. (daemon.c:693)

On fresh install the error does not show up (Stretch) since the touched/changed settings are not the last line and are all added with comma. But I enhance the way we add these settings. If they do not exist, they should be added to the top (after {) to assure they really require the comma.
Done: f080a30

@MichaIng MichaIng added Solution available 🥂 Definite solution has been done and removed Unable to replicate ☕ labels Mar 5, 2019
@Drew80
Copy link

Drew80 commented Apr 5, 2019

@MichaIng
I was having the same issue as listed above. I followed Fourdee procedure listed above from Feb 1

@Fourdee
Lets fix the file manually:

  • Edit file
nano /var/lib/transmission-daemon/.config/transmission-daemon/settings.json
  • Find the entry cache-size-mb and replace the line with "cache-size-mb": 97,
  • Save changes with CTRL+X then Y, then enter
  • Restart services with dietpi-services restart

and still had a failure with the transmission-daemon.

I then tried what what GulyFMG had done

@GulyFMG
... already solved on my end i just delete the file and let transmission recreate it again and change the value from there.

Deleting the file did solve my issue and I am sorry I did not create a bug report so I am not even sure it is completely the same issue. However I did noice there were some permission changes from the file that was installed to the file that was recreated after I deleted the first file.

Permissions from dietpi-software install

root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# ls -l
total 12
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 blocklists
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 resume
lrwxrwxrwx 1 root                root                  38 Jan 12  2018 settings.json -> /etc/transmission-daemon/settings.json
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 torrents

I then made a backup of the settings.json file, removed the old file and then restarted dietpi-services and the new settings.json file was created with different user and group and permissions. Maybe something is messed up in the dietpi-software changing it over. I have no clue, but I thought it may still be causing grief somewhere along the line. Here's my code start to finish

root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# ls -l
total 12
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 blocklists
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 resume
lrwxrwxrwx 1 root                root                  38 Jan 12  2018 settings.json -> /etc/transmission-daemon/settings.json
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 torrents
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# cp settings.json settings.json-old
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# rm settings.json
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# ls -l
total 16
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 blocklists
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 resume
-rw------- 1 root                root                2333 Apr  4 20:01 settings.json-old
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 torrents
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# dietpi-services restart
[  OK  ] DietPi-Services | Root access verified.

 DietPi-Services
─────────────────────────────────────────────────────
 Mode: restart

[  OK  ] DietPi-Services | restart : avahi-daemon
[  OK  ] DietPi-Services | restart : transmission-daemon
[  OK  ] DietPi-Services | restart : sabnzbd
[  OK  ] DietPi-Services | restart : sonarr
[  OK  ] DietPi-Services | restart : radarr
[  OK  ] DietPi-Services | restart : htpc-manager
[  OK  ] DietPi-Services | restart : cron
[ SUB1 ] DietPi-Process_tool > Apply
[  OK  ] DietPi-Process_tool | Avahi Daemon (2307) : Nice      0
[  OK  ] DietPi-Process_tool | Avahi Daemon (2307) : Affinity  0-3
[  OK  ] DietPi-Process_tool | Avahi Daemon (2307) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | Avahi Daemon (2308) : Nice      0
[  OK  ] DietPi-Process_tool | Avahi Daemon (2308) : Affinity  0-3
[  OK  ] DietPi-Process_tool | Avahi Daemon (2308) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | Cron (2379) : Nice      0
[  OK  ] DietPi-Process_tool | Cron (2379) : Affinity  0-3
[  OK  ] DietPi-Process_tool | Cron (2379) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | DHCP Client (794) : Nice      0
[  OK  ] DietPi-Process_tool | DHCP Client (794) : Affinity  0-3
[  OK  ] DietPi-Process_tool | DHCP Client (794) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | Dropbear (900) : Nice      0
[  OK  ] DietPi-Process_tool | Dropbear (900) : Affinity  0-3
[  OK  ] DietPi-Process_tool | Dropbear (900) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | Dropbear (1607) : Nice      0
[  OK  ] DietPi-Process_tool | Dropbear (1607) : Affinity  0-3
[  OK  ] DietPi-Process_tool | Dropbear (1607) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | HTPC Manager (2369) : Nice      0
[  OK  ] DietPi-Process_tool | HTPC Manager (2369) : Affinity  0-3
[  OK  ] DietPi-Process_tool | HTPC Manager (2369) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | Radarr (2356) : Nice      0
[  OK  ] DietPi-Process_tool | Radarr (2356) : Affinity  0-3
[  OK  ] DietPi-Process_tool | Radarr (2356) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | SABnzbd (2333) : Nice      0
[  OK  ] DietPi-Process_tool | SABnzbd (2333) : Affinity  0-3
[  OK  ] DietPi-Process_tool | SABnzbd (2333) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | Sonarr (2344) : Nice      0
[  OK  ] DietPi-Process_tool | Sonarr (2344) : Affinity  0-3
[  OK  ] DietPi-Process_tool | Sonarr (2344) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | Transmission (2318) : Nice      0
[  OK  ] DietPi-Process_tool | Transmission (2318) : Affinity  0-3
[  OK  ] DietPi-Process_tool | Transmission (2318) : Scheduler SCHED_OTHER 0
[  OK  ] DietPi-Process_tool | Completed
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# ls -l
total 20
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 blocklists
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 resume
-rw------- 1 debian-transmission dietpi              2232 Apr  4 20:01 settings.json
-rw------- 1 root                root                2333 Apr  4 20:01 settings.json-old
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr  2 23:52 torrents
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# nano settings.json
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# dietpi-services restart
[  OK  ] DietPi-Services | Root access verified.

As you can see the user, group and permission on the settings.json file have all be changed.

I also checked this after all of that too...

nano /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

The cache-size-mb line was set at "cache-size-mb": 4

I changed that to "cache-size-mb": 97 and no issues.

For comparison here are my stats on my board. This is a fresh install of everything

root@DietPi:~# cat /DietPi/dietpi/.version 
#!/bin/bash
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=22
G_DIETPI_VERSION_RC=3
G_GITBRANCH=master
G_GITOWNER=Fourdee
root@DietPi:~# echo $G_DISTRO_NAME 
stretch
root@DietPi:~# uname -a
Linux DietPi 4.19.20-sunxi64 #5.75 SMP Fri Feb 8 10:29:25 CET 2019 aarch64 GNU/Linux
root@DietPi:~# echo $G_HW_MODEL_DESCRIPTION 
Pine A64 (aarch64)

Power Supply - 5v 2a
SD Card 16GB AData HC10

Hope this can fix the issue.

@MichaIng
Copy link
Owner

MichaIng commented Apr 7, 2019

@Drew80
Thanks for reporting.

Hmm install works well here. We do not change anything about file permissions or locations from the default APT install.

Failing service can have many reasons, in this case either syntax or content of the config files. Can you please paste the output of:

diff /var/lib/transmission-daemon/.config/transmission-daemon/settings.json /var/lib/transmission-daemon/.config/transmission-daemon/settings.json-old

About permissions note that:

  • The original config file is a symlink to the global config dir, why you see 777 permissions there:
lrwxrwxrwx 1 root                root                  38 Jan 12  2018 settings.json -> /etc/transmission-daemon/settings.json
  • The actual file has these permissions:
root@VM-Stretch:~# l /etc/transmission-daemon/settings.json
-rw------- 1 debian-transmission debian-transmission 2325 Apr  7 14:59 /etc/transmission-daemon/settings.json
  • With cp settings.json settings.json-old you copied the actual file without preserving it's ownership. As you run this command as root users, the backup file now also has root ownership while the permission mode is the same. (To preserve permissions e.g. cp -a works.)
-rw------- 1 root                root                2333 Apr  4 20:01 settings.json-old
  • Then with rm settings.json you removed the symlink (instead of the actual file), so /etc/transmission-daemon/settings.json still exists.
  • The Transmission service then created a new default file with again identical permission mode and similar to your backup ownership of the user+group the service runs as:
-rw------- 1 debian-transmission dietpi              2232 Apr  4 20:01 settings.json

So everything as expected, permissions are all fine 😉.

@Drew80
Copy link

Drew80 commented Apr 8, 2019

@MichaIng

First I'll have to apologize for my lack of Linux knowledge. I know enough to get stuff done, but it may not be done correctly. Thanks for the clarification on a few things.

Here is the output you've requested

root@PineBox:~# diff /var/lib/transmission-daemon/.config/transmission-daemon/settings.json /var/lib/transmission-daemon/.config/transmission-daemon/settings.json-old
15c15,17
<     "download-dir": "/var/lib/transmission-daemon/Downloads",
---
>     "download-dir": "/mnt/dietpi_userdata/downloads",
>     "download-limit": 100,
>     "download-limit-enabled": 0,
17,20c19,22
<     "download-queue-size": 5,
<     "encryption": 1,
<     "idle-seeding-limit": 30,
<     "idle-seeding-limit-enabled": false,
---
>     "download-queue-size": 2,
>     "encryption": 2,
>     "idle-seeding-limit": 1,
>     "idle-seeding-limit-enabled": true,
24c26,27
<     "message-level": 1,
---
>     "max-peers-global": 20,
>     "message-level": 0,
27c30
<     "peer-limit-global": 200,
---
>     "peer-limit-global": 20,
40,41c43,44
<     "ratio-limit": 2,
<     "ratio-limit-enabled": false,
---
>     "ratio-limit": 1.1,
>     "ratio-limit-enabled": true,
43c46
<     "rpc-authentication-required": false,
---
>     "rpc-authentication-required": true,
48c51
<     "rpc-password": "{5c01300fc68c5a8a479b7607bdb8380b640a3b83qkEoV3qE",
---
>     "rpc-password": "diet314"Gl0b"l",
51c54
<     "rpc-username": "",
---
>     "rpc-username": "root",
53c56
<     "rpc-whitelist-enabled": true,
---
>     "rpc-whitelist-enabled": false,
64,66c67,71
<     "trash-original-torrent-files": false,
<     "umask": 18,
<     "upload-slots-per-torrent": 14,
---
>     "trash-original-torrent-files": true,
>     "umask": 7,
>     "upload-limit": 100,
>     "upload-limit-enabled": 0,
>     "upload-slots-per-torrent": 3,

If you need anything let me know

@MichaIng
Copy link
Owner

MichaIng commented Apr 9, 2019

@Drew80
Head on to the end: Double quotes within the password need to be escaped to prevent service start!


Okay going through the individual settings:

  • "download-dir" from default to dietpi_userdata is fine
  • "download-limit-enabled" and "download-limit" is not touched by our installer, so that must come from default APT package install and should be fine as well, and is disabled anyway: EDIT: legacy as well, so not sure why default APT install still ships this settings... Doesn't come from us as mentioned!
    • The same is true for "upload-limit" + "upload-limit-enabled": Legacy but shipped by APT package and not touched by us.
  • "download-queue-size" reduced from 5 to 2 on ARM devices which should be fine
  • "encryption" set to 2 which forces encryption instead of just preferring it. But should not affect service start.
  • "idle-seeding-limit" enabled and set to 1 which means seeding is stopped after being 1 minute in idle. Should be fine and not affect service start.
  • "message-level" set to 0 to not show any messages by default. Should be fine but of course in case of error level 1 would be good to investigate.
  • "max-peers-global" set to 20, so no more than 20 peers overall which should be fine on ARM. But I see now that this is a legacy option, replaced by "peer-limit-global". But at least on my system it does not lead to a service start. However I will replace that in code: https://github.com/transmission/transmission/wiki/Editing-Configuration-Files
  • We set "peer-limit-global" as well so this was doubled. Setting is deprecated since v1.4 and even on Jessie v2.84 is shipped. So safe to skip this.

Could you try to add "max-peers-global": 20, somewhere into the middle of your settings.json and see if service (re)start fails with this? Perhaps Raspbian ships a newer version which indeed does not allow this setting anymore.

Further:

  • "rpc-authentication-required" shipped as true by APT package but defaults to false when removing the shipped configuration. Makes sense generally to force authentication and does not lead to service failure in my tests but could affect it in general I think. Could be tested if setting this to true again leads to failure or not on your case.
  • Of course it could be disabled completely when only using the web interface via: "rpc-enabled": false,
  • "trash-original-torrent-files" we enable this to remove torrent files after imported from watch-dir. Of course this requires write permissions to the watch dir but that one is disabled by default anyway and we do not enable it. Should should not play any role.
  • "umask": 18, btw means no write permissions for group members. So when you leave this, e.g. Sonarr or media players won't be able to write to the downloaded files (or remove them after imported e.g.). We set this to 2 which allows write permissions for the whole dietpi group, so all our software. This makes life easier if e.g. you want to move files via Sonarr or add/change metadata with media players and such.

Okay now I think I found the reason why your daemon failed to start: "rpc-password": "diet314"Gl0b"l",
Your global password contains double quotes but those are not allowed, at least not without being escaped, possibly by backslash. You current config states that this is added hashed by the web UI, so we should do that as well.

Jep could replicate. Adding the password as diet314\"Gl0b\"l works well, skipping the backslashes leads to service failure. I change our code to replace every " with \" 👍.

Actually it would be best if we hash the password ourself or tell Transmission to do so. This would prevent any special character issue as well. From what I read it should hash the password automatically, but it doesn't: https://superuser.com/a/113652
Since I don't how which hash method it uses I can't add this now. Requires further investigation. However I will leave it with the above fix for now.

PR up and merged: #2706

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Solution available 🥂 Definite solution has been done
Projects
None yet
Development

No branches or pull requests

5 participants