[BUG] Cron doesn't run after container created until container stopped then started again

[cmd430]

Describe the bug
When creating and starting the latest (0.8.1 omnibus) of Scrutiny Cron does not run until I stop the container then start it again, after this Cron runs as expected

Expected behavior
Cron should run without having to stop and start the container after creation

Screenshots
N/A

Log Files
N/A

Extra
I am using podman not docker, so it could be an issue with podman?

The container is created with the following commands

# For testing CRON schedule is set to every minute

$ sudo podman volume create scrutinyInfluxdb 
$ sudo podman container run \
  --detach \
  --replace \
  --name scrutiny \
  --env 'COLLECTOR_CRON_SCHEDULE=* * * * *' \
  --volume /configs/scrutiny:/opt/scrutiny/config:Z \
  --volume /run/udev:/run/udev:ro \
  --mount type=volume,src=scrutinyInfluxdb,dst=/opt/scrutiny/influxdb \
  --publish 8085:8080/tcp \
  --device /dev/sda:/dev/sda:rwm \
  --device /dev/sdb:/dev/sdb:rwm \
  --device /dev/sdc:/dev/sdc:rwm \
  --device /dev/sdd:/dev/sdd:rwm \
  --device /dev/sde:/dev/sde:rwm \
  --device /dev/sdf:/dev/sdf:rwm \
  --device /dev/sdg:/dev/sdg:rwm \
  --device /dev/sdh:/dev/sdh:rwm \
  --device /dev/sdi:/dev/sdi:rwm \
  --device /dev/nvme0:/dev/nvme0:rwm \
  --cap-add SYS_RAWIO \
  --cap-add SYS_ADMIN \
  --restart always \
  --pull newer \
  ghcr.io/analogj/scrutiny:master-omnibus

[Twilek-de]

I am seeing that as well.

[twigley]

I noticed this with a recent update too. I think you can force it on by setting the environment variable:

COLLECTOR_CRON_SCHEDULE="0 0 * * *"

or whatever schedule you want.

[reacocard]

I too have encountered this, and I think it's to do with the >/proc/1/fd/1 2>/proc/1/fd/2 in /etc/cron.d/scrutiny - under podman redirection to these files doesn't seem to work:

% sudo podman exec -it scrutiny sh -c 'echo boo > /proc/1/fd/2'
sh: 1: cannot create /proc/1/fd/2: No such device or address

The files do exist and are marked writable, so i assume this is some quirk of how podman implements the container stdout/stderr:

% sudo podman exec -it scrutiny ls -l /proc/1/fd
total 0
lr-x------ 1 root root 64 Sep 20 02:52 0 -> /dev/null
lrwx------ 1 root root 64 Sep 20 02:52 1 -> 'socket:[103841033]'
lrwx------ 1 root root 64 Sep 20 02:48 2 -> 'socket:[103841033]'
l-wx------ 1 root root 64 Sep 20 02:52 3 -> /run/service/.s6-svscan/lock
lr-x------ 1 root root 64 Sep 20 02:52 5 -> /run/service/.s6-svscan/control
l-wx------ 1 root root 64 Sep 20 02:52 6 -> /run/service/.s6-svscan/control
lrwx------ 1 root root 64 Sep 20 02:52 7 -> 'anon_inode:[signalfd]'

And indeed if i remove that redirect with sudo podman exec -it scrutiny sed -i 's:>/proc/1/fd/1 2>/proc/1/fd/2::' /etc/cron.d/scrutiny cron now executes as expected until the next container restart.

[AnalogJ]

oh interesting. I don't use podman myself, so I never ran into this issue. Does podman expose the STDOUT/STDERR file descriptors at a different path? Might be an easy fix.

[kinghat]

oh interesting. I don't use podman myself, so I never ran into this issue. Does podman expose the STDOUT/STDERR file descriptors at a different path? Might be an easy fix.

i dont run podman and my scrutiny doesnt run unless the system/container is restarted:

services:
  scrutiny:
    image: ghcr.io/analogj/scrutiny:latest
    container_name: scrutiny
    cap_add:
      - SYS_RAWIO
    environment:
      - COLLECTOR_CRON_SCHEDULE="0 * * * *"
    volumes:
      - /run/udev:/run/udev:ro
      - ./config:/opt/scrutiny/config
      - ./influxdb:/opt/scrutiny/influxdb
    devices:
      - /dev/sda:/dev/sda
      - /dev/sdb:/dev/sdb
      - /dev/sdc:/dev/sdc
    ports:
      - 8181:8080
    restart: unless-stopped
    ```