search

linuxserver / docker-transmission

GNU General Public License v3.0
577 stars 179 forks source link

[BUG] No informational logs #240

Closed PHLAK closed 1 year ago

PHLAK commented 1 year ago

Is there an existing issue for this?

Current Behavior

Informational application logs are not shown when running docker [compose] logs <container_name> and message-level is greater than or equal to 2. 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 of 2 (or higher) in settings.json.

Run an instance of linuxserver/transmission.

Inspect the logs (docker [compose] logs <container_name>).

Environment

- OS: Arch Linux
- How docker service was installed: pacman

CPU architecture

x86-64

Docker creation

transmission:
  image: linuxserver/transmission
  depends_on:
    - wireguard
  env_file: config/transmission.env
  environment:
    PUID: 1000
    PGID: 2003
    TZ: America/Phoenix
  network_mode: service:wireguard
  volumes:
    - ./volumes/transmission:/config
    - /storage/downloads:/downloads
  restart: unless-stopped

Container logs

transmission-1  | [migrations] started
transmission-1  | [migrations] no migrations found
transmission-1  | ───────────────────────────────────────
transmission-1  | 
transmission-1  |       ██╗     ███████╗██╗ ██████╗ 
transmission-1  |       ██║     ██╔════╝██║██╔═══██╗
transmission-1  |       ██║     ███████╗██║██║   ██║
transmission-1  |       ██║     ╚════██║██║██║   ██║
transmission-1  |       ███████╗███████║██║╚██████╔╝
transmission-1  |       ╚══════╝╚══════╝╚═╝ ╚═════╝ 
transmission-1  | 
transmission-1  |    Brought to you by linuxserver.io
transmission-1  | ───────────────────────────────────────
transmission-1  | 
transmission-1  | To support LSIO projects visit:
transmission-1  | https://www.linuxserver.io/donate/
transmission-1  | 
transmission-1  | ───────────────────────────────────────
transmission-1  | GID/UID
transmission-1  | ───────────────────────────────────────
transmission-1  | 
transmission-1  | User UID:    1000
transmission-1  | User GID:    2003
transmission-1  | ───────────────────────────────────────
transmission-1  | 
transmission-1  | [custom-init] No custom files found, skipping...
transmission-1  | [ls.io-init] done.

No informational logs are ever shown, only occasional error logs.

github-actions[bot] commented 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.

PHLAK commented 1 year ago

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
fetzu commented 1 year ago

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.

github-actions[bot] commented 1 year ago

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.

firasdib commented 1 year ago

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.

drizuid commented 1 year ago

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.

firasdib commented 1 year ago

@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.

drizuid commented 1 year ago

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.

firasdib commented 1 year ago

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?

PHLAK commented 1 year ago

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

Steps to Reproduce

  1. Created a new docker-compose.yaml file with the contents shown above
  2. Ran docker compose up -d
  3. Verified that message-level was set to 2 in the config/settings.json file that was created
  4. Run docker compose logs --follow --tail 20 transmission
  5. Added a torrent (specifically the Arch Linux ISO from the magnet link at https://archlinux.org/download/)
  6. Observed that no additional logs are being generated aside from the LSIO banner
PHLAK commented 1 year ago

For the record, according to the Transmission docs log level 2 should show informational logs.

drizuid commented 1 year ago

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

drizuid commented 1 year ago

OK sorry, am back, got distracted by diablo4. here is a paste with the first half being message-level: 1, then message-level: 2

https://hastebin.com/share/wiqosatape.yaml

firasdib commented 1 year ago

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.

drizuid commented 1 year ago

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.

firasdib commented 1 year ago

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?

PHLAK commented 1 year ago

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.

drizuid commented 1 year ago

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 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.

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?

firasdib commented 1 year ago

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.

drizuid commented 1 year ago

I am travelling until friday, when i get home ill spin up something on a different box and see what happens.

geeooff commented 1 year ago

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.

PHLAK commented 1 year ago

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:

drizuid commented 1 year ago

ill engage the team and see if anyone has ideas.

sbrudenell commented 1 year ago

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.

PHLAK commented 1 year ago

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

I will PR this change to the docs.

drizuid commented 1 year ago

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!