Closed PHLAK closed 1 year ago
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
After a little more troubleshooting I got the following error message to show up (with message-level
at 2
) but still no informational messages. Updated original issue to reflect this.
transmission-1 | [2023-03-24 13:01:46.358] ERR net.cc:318 Couldn't bind port 51413 on 10.2.0.2: Address not available (99) (net.cc:318)
transmission-1 | setsockopt IP_MULTICAST_IF: Address not available
transmission-1 | bind: Address not available
Hey @PHLAK, I have been struggling with the same issue today. In my case, it was due to "bind-address-ipv4" being set to an IP in my settings.json.
Try changing the "bind-address-ipv4" to "0.0.0.0" ("bind-address-ipv4": "0.0.0.0",) in the settings.json and restart the docker container. Hope this helps !
EDIT: I'm an idiot and didn't see what your issue was actually about. Nevermind.
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
I second this. I've tried everything, cannot get any meaningful logs out of this container at all, and the maintainers seem reluctant to add the necessary parameters to the container.
I am a bit confused about the issue. If i am message-level 1 i don't get much, if i set to message-level 2, i get spammed to hell with updates. In the case of PHLAK, i wouldn't expect any logs beyond what is there because the container doesn't look like it's running correctly due to some host side conflicts with the container.
fireasdib claims some necessary parameters are missing but provides no useful information or pull requests to add these "necessary parameters." Without someone reproducing this issue in a working setup and providing the relevant information, there is simply nothing we can do. We are not reluctant to do anything aside from make wild guesses that would impact the hundreds of thousands of users we have to MAYBE fix a problem that is most likely only on the user's end.
That said, I am happy to be proven wrong if one of you wants to step up and actually do some work in providing meaningful info.
@drizuid No matter what message level I use, I get nothing (only what you see in the original post by @PHLAK). If I use level 3, I get some odd warnings here and there, but nothing else. The output is very lacking.
If I modify the docker files and re-launch the process with --log-info --logfile /config/transmission.log
I start getting all the useful information I needed in the log file.
What I would love is for this to be included by default in the image. I've searched the issues for this problem, and it seems very common. If there is anything I can do on my end to troubleshoot why its happening, please tell me.
Unless we can reproduce this issue (we can't) or someone shows us the code causing the purported issue and the subsequent fix, there is nothing we can do. Much as I hate to say this, it's working fine for us and it would be silly for us to push a change for one user. The op's container has other issues caused by their host so they do not factor in.
I'm confused what possible issued could be caused by their host? Can you show a snippet of the logs you see on your end?
The op's container has other issues caused by their host so they do not factor in.
What other host issues are you referring to here?
I just tried to run a new container from a different host with the docker-compose.yaml
file below and "message-level": 2
in my settings.json
file and am still not getting any informational messages.
version: '3.4'
services:
transmission:
image: linuxserver/transmission
environment:
PUID: 1000
PGID: 1000
ports:
- 9091:9091
- 51413:51413
- 51413:51413/udp
volumes:
- ./config:/config
restart: unless-stopped
docker-compose.yaml
file with the contents shown abovedocker compose up -d
message-level
was set to 2
in the config/settings.json
file that was createddocker compose logs --follow --tail 20 transmission
For the record, according to the Transmission docs log level 2
should show informational logs.
The logs from the original OP clearly should a lack of binding due to a host port conflict. Either way, we are unable to reproduce any of these issues. I had a completely silent container log, i changed message-level to 2, i got spammed to hell with logs, set back to 1, nice and quiet. We can't fix what we can't reproduce.
that said, in the "steps to reproduce" shown above, that wouldn't work because that isn't how you modify the settings.json. As stated in the readme, you must stop the container to modify settings.json, so step 2 followed by 3 is a clear lack of following direction which WOULD result in the change not going into effect and thus, no change.
For more info when we attempted to reproduce the issue, these were the steps.
1) check logs docker compose logs -tf --tail="50" transmission
see only LSIO startup procedure
2) docker compose down transmission
3) modify message-level
from 1 to 2 in settings.json
4) docker compose up -d transmission
5) docker compose logs -tf --tail="50" transmission
6) get spammed with tracker announcements and other information
7) docker compose down transmission
8) modify message-level
from 2 to 1 in settings.json
9) docker compose up -d transmission
10) docker compose logs -tf --tail="50" transmission
verified only LSIO startup procedure
We are not opposed to assisting, but we've had 2 users, EVER, mention this issue (both in this thread), and in none of our attempts could we reproduce it.
In case this is useful here is my test environment setup
transmission:
image: lscr.io/linuxserver/transmission
container_name: transmission
healthcheck:
test: curl --fail curl --fail http://driz:${TRANSPASS}@localhost:9091 || exit 1
interval: 20s
retries: 5
start_period: 20s
timeout: 10s
networks:
servarr:
ipv6:
ipv6_address: 2600:<removed>
environment:
- PUID=1006
- PGID=996
- TZ=America/New_York
- USER=driz
- PASS=${TRANSPASS}
- S6_KILL_GRACETIME=30000
volumes:
- ${BDDIR}/docker/transmission:/config
- ${BDDIR}/BT:/downloads
- /etc/localtime:/etc/localtime:ro
ports:
- 9091:9091
- 51413:51413
- 51413:51413/udp
mem_limit: "2097152000"
restart: unless-stopped
lsio-dev ~ # uname -mr
5.10.0-23-amd64 x86_64
lsio-dev ~ # docker version
Client: Docker Engine - Community
Version: 24.0.1
API version: 1.43
Go version: go1.20.4
Git commit: 6802122
Built: Fri May 19 18:06:34 2023
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 24.0.1
API version: 1.43 (minimum version 1.12)
Go version: go1.20.4
Git commit: 463850e
Built: Fri May 19 18:06:34 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.21
GitCommit: 3dce8eb055cbb6872793272b4f20ed16117344f8
runc:
Version: 1.1.7
GitCommit: v1.1.7-0-g860f061
docker-init:
Version: 0.19.0
GitCommit: de40ad0
lsio-dev ~ # docker compose version
Docker Compose version v2.18.1
yes, i need to update my docker ce :( i just noticed -- i just noticed the request to see my logs, i started updating docker but i will provide them soon
OK sorry, am back, got distracted by diablo4. here is a paste with the first half being message-level: 1, then message-level: 2
Thank you for your detailed posts.
My compose looks identical to yours, so I’m unsure what the issue could be on my end. Folder and file permissions all look fine.
Jusging by your log sample, I’m not sure you’re getting the correct logs, either. It should write a lot more informational logs about what torrents you have, their status, etc etc.
I can investigate this further next week when I’m back home.
It should write a lot more informational logs about what torrents you have, their status, etc etc.
I only ran for a couple seconds before I cancelled and changed logging back to 1. Perhaps it's not getting all the details, but it's getting individual torrent info from trackers which didn't happen on level 1. I'm down to assist once you're back home though.
My logs look identical to OPs:
[migrations] started
[migrations] no migrations found
usermod: no changes
───────────────────────────────────────
██╗ ███████╗██╗ ██████╗
██║ ██╔════╝██║██╔═══██╗
██║ ███████╗██║██║ ██║
██║ ╚════██║██║██║ ██║
███████╗███████║██║╚██████╔╝
╚══════╝╚══════╝╚═╝ ╚═════╝
Brought to you by linuxserver.io
───────────────────────────────────────
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID: 1000
User GID: 1000
───────────────────────────────────────
ln: failed to create symbolic link '/transmissionic/index.html': File exists
ln: failed to create symbolic link '/combustion-release/index.html': File exists
ln: failed to create symbolic link '/flood-for-transmission/index.html': File exists
ln: failed to create symbolic link '/kettu/index.html': File exists
ln: failed to create symbolic link '/transmission-web-control/index.html': File exists
[custom-init] No custom files found, skipping...
[ls.io-init] done.
lack of binding due to a host port conflict What does this mean? How can I resolve this?
in the "steps to reproduce" shown above, that wouldn't work because that isn't how you modify the settings.json. As stated in the readme, you must stop the container to modify settings.json, so step 2 followed by 3 is a clear lack of following direction which WOULD result in the change not going into effect and thus, no change.
I understand this procedure, however, when I said "verified that message-level
was set to 2
" I meant that the message-level
was set to 2
by default on container instantiation. Perhaps that's part of the problem? I'll try going through changing the level using the full procedure later and see if this makes a difference.
lack of binding due to a host port conflict What does this mean? How can I resolve this?
You dont have the error that OP showed in https://github.com/linuxserver/docker-transmission/issues/240#issuecomment-1483352301 though yours definitely looks like mine did on level 1.
I understand this procedure, however, when I said "verified that
message-level
was set to2
" I meant that themessage-level
was set to2
by default on container instantiation. Perhaps that's part of the problem? I'll try going through changing the level using the full procedure later and see if this makes a difference.
Gotcha, I was just trying to be thorough. You may be on to something, try using the procedure i listed and change to 1, bring it up, then stop, change to 2, bring it up and check?
lack of binding due to a host port conflict What does this mean? How can I resolve this?
You dont have the error that OP showed in #240 (comment) though yours definitely looks like mine did on level 1.
Right, this is what I have in my settings.json
:
cat /docker/torrent-tools/transmission/config/settings.json | grep 'message-level'
"message-level": 2,
And I have verified this is the correct settings.json
since if I stop the container, remove it, and start again, a new one is created in its place. And even with that one, I get no logs.
I am travelling until friday, when i get home ill spin up something on a different box and see what happens.
Same problem here, no log produced. I don't know if this matters but I'm using Podman, not Docker Engine, on Ubuntu 22.04.02 LTS.
I'll try going through changing the level using the full procedure later and see if this makes a difference.
Tried and still no logs. :confused:
ill engage the team and see if anyone has ideas.
Just encountered this and I think the issue is transmission's docs are out of date.
Docs say:
message-level: Number (0 = None, 1 = Error, 2 = Info, 3 = Debug, default = 2) Set verbosity of Transmission's log messages.
But the header file implies different values:
enum tr_log_level
{
// No logging at all
TR_LOG_OFF,
// Errors that prevent Transmission from running
TR_LOG_CRITICAL,
// Errors that could prevent a single torrent from running, e.g. missing
// files or a private torrent's tracker responding "unregistered torrent"
TR_LOG_ERROR,
// Smaller errors that don't stop the overall system,
// e.g. unable to preallocate a file, or unable to connect to a tracker
// when other trackers are available
TR_LOG_WARN,
// User-visible info, e.g. "torrent completed" or "running script"
TR_LOG_INFO,
// Debug messages
TR_LOG_DEBUG,
// High-volume debug messages, e.g. tracing peer protocol messages
TR_LOG_TRACE
};
I used "message-level": 4,
and now I get info messages.
I think the issue is transmission's docs are out of date
OH MY GOD! That was it! Changing message-level
to 4
showed informational logs (and 5
debug logs)!
So that means the following values for message-level
should be
0
: Off (no logs)1
: Critical2
: Errors3
: Warnings4
: Informational5
: Debugging6
: TraceI will PR this change to the docs.
Great effort guys, thanks a bunch to @PHLAK and @sbrudenell for submitting the PR and figuring out the issue! I was seeing so much data at 2 (the logs showed errors and this makes more sense now) that I couldn't wrap my head around there possibly being MORE data than that!
Is there an existing issue for this?
Current Behavior
Informational application logs are not shown when running
docker [compose] logs <container_name>
andmessage-level
is greater than or equal to2
. Only the LSIO banner and limited initial information are show (see Container logs section below).Expected Behavior
Informational application logs should be shown as they are generated.
Steps To Reproduce
Set
message-level
to a value of2
(or higher) insettings.json
.Run an instance of
linuxserver/transmission
.Inspect the logs (
docker [compose] logs <container_name>
).Environment
CPU architecture
x86-64
Docker creation
Container logs
No informational logs are ever shown, only occasional error logs.