The /usr/bin/backup<number>-now scripts are duplicated at each container restart

[Oni]

Summary

Every time I restart the container, the scripts at /usr/bin/backup<number>-now are duplicated. f I try to run backup-now the backups are done multiple times.

Steps to reproduce

1. Restart the container multiple times;
2. Run cat /usr/bin/backup01-now;
3. The content is duplicated at each restart:

#!/bin/bash
source /assets/functions/00-container
PROCESS_NAME=db-backup01
print_info "Starting Manual Backup for db-backup01"
#/var/run/s6/legacy-services/dbbackup-01/run now
/etc/services.available/dbbackup-01/run now

#!/bin/bash
source /assets/functions/00-container
PROCESS_NAME=db-backup01
print_info "Starting Manual Backup for db-backup01"
#/var/run/s6/legacy-services/dbbackup-01/run now
/etc/services.available/dbbackup-01/run now

#!/bin/bash
source /assets/functions/00-container
PROCESS_NAME=db-backup01
print_info "Starting Manual Backup for db-backup01"
#/var/run/s6/legacy-services/dbbackup-01/run now
/etc/services.available/dbbackup-01/run now

#!/bin/bash
source /assets/functions/00-container
PROCESS_NAME=db-backup01
print_info "Starting Manual Backup for db-backup04"
#/var/run/s6/legacy-services/dbbackup-01/run now
/etc/services.available/dbbackup-01/run now

What is the expected correct behavior?

If I restart the container multiple times, backup-now should do a single backup per database

Environment

Deployed with docker-compose:

services:
  db_dumper:
    container_name: db_dumper
    image: ghcr.io/tiredofit/docker-db-backup:4.1.17
    environment:
      USER_DBBACKUP: 1030 # user id allowed to access volumes
      GROUP_DBBACKUP: 101 # PUID group allowed to access volumes
      TIMEZONE: Europe/Rome
      CONTAINER_ENABLE_MONITORING: 'FALSE'
      BACKUP_JOB_CONCURRENCY: 1        # Only run one job at a time

      DEFAULT_CHECKSUM: NONE           # Don't create checksums
      DEFAULT_COMPRESSION: NONE        # Don't compress
      DEFAULT_BACKUP_BEGIN: 30 1 * * 0 # Start backing up at 1:30 sunady night
      DEFAULT_CLEANUP_TIME: 8640       # Cleanup backups after 6 days
      DEFAULT_SCRIPT_LOCATION_POST: /assets/scripts/post/

      DB01_TYPE: pgsql
      DB01_HOST: REDACTED
      DB01_NAME: REDACTED
      DB01_USER: REDACTED
      DB01_PASS: REDACTED

      DB02_TYPE: pgsql
      DB02_HOST: REDACTED
      DB02_NAME: REDACTED
      DB02_USER: REDACTED
      DB02_PASS: REDACTED

      ...
    volumes:
      - ./volumes/dumps:/backup
      - ./volumes/scripts:/assets/scripts
    networks:
      - db_dumper
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

networks:
  db_dumper:
    driver: bridge
    name: db_dumper

Possible fixes

The image entrypoint shouldn't append stuff to /usr/bin/backup<number>-now, but should replace them instead.

[tiredofit]

Interesting. Can you give me the commands that you're doing to restart your container? I think what it is is actually you are restarting the container but the state is still there so the file system is not getting Reset so that makes sense as to why the script keeps duplicating or more.

Does the same thing happen if you entirely remove the container from your system when stopping it?

[Oni]

I restart the container using portainer "restart" button. But I've just tested that docker container stop db_dumper and docker container start db_dumper triggers the issue.

Of course docker container rm db_dumper and docker-compose up resets the whole container FS.

That's the expected bahaviour for Docker: stopping and starting the container doesn't reset its FS. If you want to start anew you have to remove the container ad recreate it.

The workflow I have for all other docker services is:

1. Make docker-compose.yml;
2. Run docker-compose up;
3. Tweak env vars or config files;
4. Restart the container or run docker-compose up again.

I assume it's the standard "docker way". Rebuilding the container at every change seems a bit overkill to me.

But I can live with that.

[tiredofit]

Ahh portainer, yes I am aware how it does the restarts and have come up against it. I am not sure why it needs to build anything on startup if you are relying on the prebuilt images, but that could be another portainer thing.

I have traps in place that refresh the file system if restarted in other containers, so I'll have to work that into a future release - this is an annoyance for sure.

[Oni]

I'm not sure it's a portainer issue, since plain docker container stop and docker container start trigger the issue too.

Perhaps the culprit is here?

I guess it should be:

cat <<EOF > /usr/bin/backup"${instance}"-now

Instead of:

cat <<EOF >> /usr/bin/backup"${instance}"-now

In the meantime I'll just delete the container and docker-compose up again.

[tiredofit]

Have a peek at 4.1.19 if you could and this release should overwrite the files and stop duplication.

I don't have the routines in place in this image to check if the container has ever been turned on without wiping its state - I've simply forced it to overwrite the scripts which I can't remember my decision to not in the past, so much for memory.

At some point in future there is a new image in the wings that uses a different base that solves workarounds due to some of the design decisions from 7 years back...

[Oni]

Yay! Fixed! Thank you!