cron update error about docker-transmission HOT 17 CLOSED

@TimVNL is this still an issue for you?

from docker-transmission.

Same issue here, over and over, every minute. On Synology DS1817+ DSM 6.1.1-15101 Update 2

01:10:00 crond[226]: wakeup dt=60
01:10:00 crond[226]: file root:
01:10:00 crond[226]:  line run-parts /etc/periodic/15min
01:10:00 crond[226]:  line run-parts /etc/periodic/hourly
01:10:00 crond[226]:  line run-parts /etc/periodic/daily
01:10:00 crond[226]:  line run-parts /etc/periodic/weekly
01:10:00 crond[226]:  line run-parts /etc/periodic/monthly
01:10:00 crond[226]:  line /config/blocklist-update.sh 2>&1
01:11:00 crond[226]: wakeup dt=60
<etc>

run-parts is busybox, running, of course, run-parts, which executes everything in the folders provided as args.

Not sure why it happens every minute. root's crontab is:

root@transmission:/etc/periodic$ crontab -l
# do daily/weekly/monthly maintenance
# min   hour    day     month   weekday command
*/15    *       *       *       *       run-parts /etc/periodic/15min
0       *       *       *       *       run-parts /etc/periodic/hourly
0       2       *       *       *       run-parts /etc/periodic/daily
0       3       *       *       6       run-parts /etc/periodic/weekly
0       5       1       *       *       run-parts /etc/periodic/monthly

# run daily blocklist update
0 3 * * * /config/blocklist-update.sh 2>&1

Except that those folders are empty on my docker image:

root@transmission:/etc/periodic$ ls -la *
15min:
total 0
drwxr-xr-x 1 root root  0 May 13 07:08 .
drwxr-xr-x 1 root root 58 May 13 07:08 ..

daily:
total 0
drwxr-xr-x 1 root root  0 May 13 07:08 .
drwxr-xr-x 1 root root 58 May 13 07:08 ..

hourly:
total 0
drwxr-xr-x 1 root root  0 May 13 07:08 .
drwxr-xr-x 1 root root 58 May 13 07:08 ..

monthly:
total 0
drwxr-xr-x 1 root root  0 May 13 07:08 .
drwxr-xr-x 1 root root 58 May 13 07:08 ..

weekly:
total 0
drwxr-xr-x 1 root root  0 May 13 07:08 .
drwxr-xr-x 1 root root 58 May 13 07:08 ..

There are some other processes running. This one caught my eye:

  226 root       0:00 /usr/sbin/crond -f -S -l 0 -c /etc/crontabs

What's in /etc/crontabs? Oh, it's just the cron import file for the jobs above.

What's /usr/sbin/crond .. it's crond via busybox

Usage: crond -fbS -l N -d N -L LOGFILE -c DIR

	-f	Foreground
	-b	Background (default)
	-S	Log to syslog (default)
	-l N	Set log level. Most verbose:0, default:8
	-d N	Set log level, log to stderr
	-L FILE	Log to FILE
	-c DIR	Cron dir. Default:/var/spool/cron/crontabs

So, in foreground, log most verbosely to syslog, and use the provided dir to search for crontabs. OK, checking the man page this is the actual daemon that determines when to run jobs in all user's crontabs, if they exist, but only one (root) exists.

If the /etc/periodic folders are empty, do we need to insert the jobs? Or do they do something special?

I'm not sure syslog is running on this containers. Can anyone tell me where the log is?

thanks
James

from docker-transmission.

I'm still having this issue in April 2018, anyone got to a solution before?

from docker-transmission.

This is still an issue

from docker-transmission.

I suspect this is a niche issue with Nas devices - I'm going to test this at some point on my unraid box and also on my Qnap and I'll report back. Does the issue show up instantly?

from docker-transmission.

Yes, it appears immediately in a new container. It may very well be a NAS issue, mine arises on a Synology NAS, haven't tried it on desktop linux.

from docker-transmission.

This is still an issue.

from docker-transmission.

@onedr0p what setup/configuration/etc are you experiencing this issue on?

from docker-transmission.

Just spun this container up on my Ubuntu Mate VM - so far no cron errors.
I will leave this running for a good couple of hours to see if anything shows up.

from docker-transmission.

Update: I got this by chance as I ran the container passing the interactive flag "-t" these devices must be passing this flag to these containers, without it all startup output from crond is suppressed.

I am able to reproduce this by running the command manually in this container:

/usr/sbin/crond -f -S -l 0 -c /etc/crontabs

Investigating what could have changed.

from docker-transmission.

My set up is Ubuntu 18.04 server running Docker 18.03.

from docker-transmission.

Here is my docker-compose.yml:

version: '2'
services:
  transmission:
    image: linuxserver/transmission:latest
    environment:
      PGID: '1000'
      PUID: '1000'
      TZ: America/New_York
      UMASK: '1000'
    stdin_open: true
    volumes:
    - <path_to_config>:/config
    - <path_to_media>:/media
    tty: true
    ports:
    - 51413:51413/tcp
    - 51413:51413/udp
    - 9091:9091/tcp

from docker-transmission.

Drop the tty from that compose and you will stop seeing the spam in your logs .

from docker-transmission.

I understand that, but every other linuxserver container I use doesn't have this problem.

from docker-transmission.

Every other container you use does not have crond running. What advantage do you see with having an interactive shell attached to your container for s6 overlay ?
I have told you how to fix it, if you want to become a hardcore c dev and start working on the Alpine BusyBox package , go for it.

from docker-transmission.

Your fix is really a workaround and I highly doubt it comes down to Alpine or Busybox being the culprit here. Anyways, I've updated my deployment in Rancher to only to be -i instead of -i -t for now.

from docker-transmission.

@onedr0p this is not a blame thing, it is just the state of crond, alpine, and docker. When the binary is run in the foreground without dumping to syslog it would seem that it spams it startup message every iteration.
In order to actually fix it you would need to participate in the development of the baked in crond and add some kind of flag to suppress this behaviour which I am assuming the devs put in for a reason.
It can be made less by changing the log level for crond, but this would then suppress the output for the actual execution of timed cron jobs. In the case of this container that is the execution and output of "blocklist-update.sh".

from docker-transmission.