search

linuxserver / docker-nzbget

GNU General Public License v3.0
149 stars 83 forks source link

Can't stop the container, can't kill it, can't rm it #70

Closed leonroy closed 5 years ago

leonroy commented 5 years ago

Having lots of reliability issues with the nzbget container.

Host OS: Ubuntu 18.04 LTS Create: docker-compose up -d Conf:

version: "2"
services:
  nzbget:
    image: linuxserver/nzbget
    container_name: nzbget
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
    volumes:
      - /docker/nzbget:/config
      - /mnt/downloads/Usenet:/downloads
    ports:
      - 6790:6789
    restart: unless-stopped

Log output below.

Volume is running over cifs mounted in host.

When running docker-compose kill:

compose.parallel.feed_queue: Pending: {<Container: nzbget (ad702b)>}
compose.parallel.feed_queue: Starting producer thread for <Container: nzbget (ad702b)>
compose.cli.verbose_proxy.proxy_callable: docker kill <- ('ad702b6a12fc17dfedafcd2379aa72a329a202263d327e4b6c42aac851cb5985', signal=None)

compose.parallel.feed_queue: Pending: set()
...
...
compose.parallel.parallel_execute_iter: Failed: <Container: nzbget (ad702b)>
compose.parallel.feed_queue: Pending: set()

ERROR: for nzbget  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)
ERROR: compose.cli.errors.log_timeout_error: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

I cannot stop/start/rm or destroy the container in any way.

NZBget also behaves unreliably.

Any thoughts appreciated.

j0nnymoe commented 5 years ago

Which volumes? or both?

leonroy commented 5 years ago

@j0nnymoe just the /mnt/downloads/Usenet:/downloads folder.

j0nnymoe commented 5 years ago

Sounds like something to do with either your fstab arguements for that mount or the share settings as there are no issues when working with local file systems.

leonroy commented 5 years ago

thanks, any suggestion on how I would determine the cause? also surely Docker should stop the container rather than leaving it in an indeterminate state?

leonroy commented 5 years ago

turns out it was related to SMB Opportunistic Locking. Turning it off resolved the issue completely.