LocalLog.Info("Waiting for the notification goroutine to finish")

[phit42]

Is there a reason why this message goes to stdout (or stderr)?

watchtower/pkg/notifications/shoutrrr.go

Line 188 in aa02d8d

LocalLog.Info("Waiting for the notification goroutine to finish")

It is the only stdout/stderr output from watchtower when started in a bash script with the following command and notifications settings:

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e TZ=Europe/Berlin \
  --env-file /volume1/docker/containerdata/watchtower/watchtower_notifications_settings.env_file \
  containrrr/watchtower:latest \
  --run-once \
  sabnzbd \
  --stop-timeout 300s

WATCHTOWER_NOTIFICATIONS=shoutrrr
WATCHTOWER_NOTIFICATION_URL=smtp://...  pushbullet://...
WATCHTOWER_NOTIFICATION_TEMPLATE={{range .}}{{.Time.Format "2006-01-02 15:04:05"}} ({{.Level}}): {{.Message}}{{println}}Data: {{ range $key, $value := .Data }}{{ $key }}: {{ $value }}{{println}}{{ end }}{{println}}{{end}}
WATCHTOWER_NOTIFICATION_EMAIL_DELAY=2
WATCHTOWER_NOTIFICATIONS_LEVEL=info
WATCHTOWER_NO_STARTUP_MESSAGE=true

[piksel]

The message confirms that the exit of the app has been received, but telling what it's waiting for before actually exiting.
It is the only message if there are no updates, and you have turned off startup message. edit: Maybe this was true at some point, but I don't know when, it's not what happens in v1.3.0 or v.1.4.0 at least.

Since it's related to the notification service itself, it's not being sent using the service (hence the LocalLog, which just means "no notification").

[phit42]

Thank you for the explanation.
Would it be possible to turn it off in a run-once situation, or not send it to stdout or least not to log level info?

[piksel]

I guess the --no-startup-message could change this as well. Could you explain your use case?

[phit42]

Thank you. In my use case, I am using the watchtower command in a shell script triggered by a task. The shell script checks some pre-conditions and performs watchtower only when the pre-conditions are met.
On execution, the resulting stdout log information is stored and sent to me if and only if not empty, so in expectation if and only if any error occurs ( - any actual update information would go out via according notification settings). This little line goes out to stdout or stderr of the shell, thus resulting in an "error" message on each run.

It could be linked to the --no-startup-message flag, however this flag modifies the notification behaviour, not the log behaviour. Maybe it could be linked to the --debug flag. Would make it "cleaner" from my point of view, but just my 2cents...

[piksel]

the resulting stdout log information is stored and sent to me if and only if not empty

That is what the notifications are doing right now. Why are they not an option?
The additional information printed "locally" is for the lifetime of the process itself. I don't consider that debugging information, but especially useful for understanding what watchtower is doing when things went wrong (and either we tell all users to always run with debug logging always enabled, or we get issues with logs that doesn't tell the relevant information).

If you only want the logs that actually gets sent via the notifications, you can simply pipe it through grep -v notify=no, or if this is the only message you want to emit: grep -v "notification goroutine"

[phit42]

Sorry, maybe I am not explaining it very well. The content of the notifications and they way they are sent is fine and they work. In my scenario, I am looking at the log of the whole shell script, which is always empty when without error, as stdout should be - expect this line.
And it makes sense that additional info about the process itself would be printed "locally", particularly when things go wrong. Only, nothing expect this line IS printed "locally" every time and nothing goes/went wrong, so this is like a status update of what watchtower is doing right now. But the only one (on stdout).
If I still couldn't explain it any better, don't worry, and thank you for taking an interest in the topic and the discussion, piksel.

[piksel]

This is the current output when running with --no-startup-message using the latest release (v1.4.0):

$ ./watchtower --monitor-only --run-once --no-startup-message
INFO[0001] Watchtower 1.4.0                              notify=no
INFO[0001] Using no notifications                        notify=no
INFO[0001] Checking all containers (except explicitly disabled with label)  notify=no
INFO[0001] Running a one time update.                    notify=no
INFO[0002] Session done                                  Failed=0 Scanned=1 Updated=0 notify=no
INFO[0002] Waiting for the notification goroutine to finish  notify=no

So I am not sure what version you are actually running... But like I said, if you just do:

$ ./watchtower --monitor-only --run-once --no-startup-message 2>&1 | grep -v notify=no
$

the output is the same as the messages being sent as notifications (none, when there are no updates or errors).