database-backup-and-maintenance.sh creates output on success

[tribut]

Because /etc/cron.d/packetfence runs database-backup-and-maintenance.sh, a mail is generated every night even if no errors occured. Example output:

/root/backup/ , folder already created. 

tar: Removing leading `/' from member names
tar: /usr/local/pf/var/run/radiusd.sock: socket ignored
tar: /usr/local/pf/var/run/pfconfig.sock: socket ignored
tar: /usr/local/pf/var/run/radiusd-load_balancer.sock: socket ignored
tar: /usr/local/pf/var/run/redis_cache.sock: socket ignored
tar: /usr/local/pf/var/run/collectd-unixsock: socket ignored
tar: /usr/local/pf/var/run/radiusd-acct.sock: socket ignored
tar: /usr/local/pf/var/run/redis_queue.sock: socket ignored
packetfence-files-dump have been created in  /root/backup/ 

packetfence-files-dump older than 30 days have been removed. 

Apr 22 00:31:22 : Deleting 0 entries from locationlog in 1 runs batching 500 at the time waiting 0.5     seconds between runs. 
Apr 22 00:31:23 : Deleting 0 entries from iplog_history in 1 runs batching 500 at the time waiting 0.5 seconds between runs. 
Apr 22 00:31:24 : Deleting 0 entries from radacct in 1 runs batching 500 at the time waiting 0.5 seconds between runs. 
Apr 22 00:31:25 : Deleting 0 entries from radacct_log in 1 runs batching 500 at the time waiting 0.5 seconds between runs. 
Apr 22 00:31:26 : Deleting 0 entries from auth_log in 1 runs batching 500 at the time waiting 0.5 seconds between runs. 
Apr 22 00:31:27 : Deleting 0 entries from radius_audit_log in 1 runs batching 500 at the time waiting 0.5 seconds between runs. 

(Also see #1404)

[dwlfrth]

Hello @tribut
How is this "an issue" ?
That's the standard behavior of cron to send a "report" once a task is completed.
You could append "> /dev/null" at the end of the command lines you don't want to receive the output.

[tribut]

Are you saying it's intended behavior that a cron job which is installed by default generates a mail every night?
Because cron generates a mail if any output occurs, cronjobs normally use something like a --quiet option where only error messages are printed. And I would argue that is "the right thing to do".

[dwlfrth]

Well, from what I know (I may be wrong, it sometimes happens ;)), by default cron jobs sends a email to the user account executing the cronjob if there's an error or of the job generates an output.

The following "> /dev/null" will discard any output from the job (which means, no email) but a mail will be sent in the case something is going to stderr ...

[louismunro]

I think the issue is one of expectations.
We can certainly force the cron job to be quiet.
But then how will the user know that the backups are running?
Admittedly that is what logs are for.

I am inclined to side with @tribut

[tribut]

@dwlfrth True, but tar writes its warnings to stderr, so >/dev/null would not be enough to silence the cronjob, while 2>&1 /dev/null would also prevent errors from being sent out.

[julsemaan]

Well the errors are sockets being backed up in /usr/local/pf/var/run
No need to backup the content of that directory as it contains PID files and sockets that can't be restored anyway.

So silencing tar and mkdir should do it, and the cleanup will be moved out of that in 6.1 anyway

[julsemaan]

The var/run isn't part of the tar anymore so the sockets message should be gone.

I still believe we should keep the remaining of the output so we know what happened

My 2 cents. Lets see if others who disagrees

[dwlfrth]

Let's see as @julsemaan says.
Also probably going to retire that script sooner or later...

[julsemaan]

Lets give some love to that script in 8.1

[Yannik]

I have opened #7754 to remove the stderr output generated by tar. This should be a major step forward in this. Together with chronic, cron emails can now be suppressed for all non-error cases.