run exec on cron script carefully

wolfdogg · 2014-01-06 18:40:36

i would like to change permissions of a file after rsync backups a file in my cron script, i was going to append an exec command to this command line, but i would like to know how to do it carefully so im not blowing up any other files.

rsync -a --delete /home/backup/sqldumps /mnt/smb/backup/ &> /dev/null

i was considering something like

rsync -a --delete /home/backup/sqldumps /mnt/smb/backup/ &> /dev/null && -exec chmod 550 {} \;

but i was fearing that it might exec on the entire root, and or not run at the right time on the right file.
im having a hard time finding documentation on the latter portion of the exec command to know what the {} and \; does again. i forget..... im assuming that part may not be needed and causes recursion.

im going about it a bit lazy as well, and to keep the overhead lower, otherwise i would just run the rsync command first, then on the 2nd line do a find exec for a matching file for some criteria.

can anyone shed some light on this?

Last edited by wolfdogg (2014-01-06 18:41:41)

berbae · 2014-01-07 09:52:38

Does not the '--chmod=CHMOD' option of rsync do what you want?

Trilby · 2014-01-07 12:58:07

wolfdogg wrote:

im having a hard time finding documentation on the latter portion of the exec command to know what the {} and \; does again.

There is no `-exec` command. There is an -exec option to the `find` command, but you are not running find. Unless the current man page is out of date, rsync has no -exec option like that.

Further, if you put it after the && you would not be passing an -exec option to rsync. Instead you'd be trying to run /usr/bin/-exec, or an -exec somewhere else in your path.

The '{}' and \; are documented in the find man page as (again) they are specific to the syntax for find's -exec flag. They are not a separate command or shell option.

fukawi2 · 2014-01-07 13:39:48

man rsync wrote:

--chmod
This option tells rsync to apply one or more comma-separated “chmod” strings to the permission of the files in the transfer. The result-
ing value is treated as though it was the permissions that the sending side supplied for the file, which means that this option can seem
to have no effect on existing files if --perms is not enabled.

So you would use:

rsync -a --delete --chmod=ug=rx,o= /home/backup/sqldumps /mnt/smb/backup/

And please don't use `&> /dev/null`. It kills unicorns.

wolfdogg · 2014-01-07 23:25:43

ok great, that was my misunderstanding, to assume exec was a command, yes your right, its part of find, and that makes sense why i wasnt finding what i was looking for. thanks for clearning that up for me. ok, so chmod looks like it is what i want to do, thanks for that info. i probably overlooked it in the man since i didnt know i needed it at the time.

fukawi2, are you serious about not using &> /dev/null, so that any errors arent squelched, otherwise that is a witty joke.

fukawi2 · 2014-01-07 23:47:41

wolfdogg wrote:

fukawi2, are you serious about not using &> /dev/null, so that any errors arent squelched, otherwise that is a witty joke.

Absolutely - they are errors, which usually mean something hasn't worked. I assume you're not scripting this just so cron has something to do, and actually care about the result?

Of course, if you have another way of monitoring the success/failure then great, but far too often people just dump all output (errors or not) to /dev/null and then get surprised 3 months later when things haven't been going according to plan.

wolfdogg · 2014-01-10 02:11:48

yeah good point. i had that removed for testing only, but was following the wiki so wasnt sure how that would work as ran from a cron job. i expected it was because errors would show up on screen, possible even when typing a command, so i was trusting the wiki in that case. Now that you mentioned it, it makes me guess that the errors instead go to journalctl? if thats the case then yet i want them.

fukawi2 · 2014-01-10 02:29:49

Usually cron captures the output and sends it in an email -- either to the MAILTO= address in your crontab, or to the user who the crontab is executing for, in which case you should setup forwarding for the user. For example, if you are using postfix, edit /etc/aliases or create a ~/.forward file to forward to your real email address.

Alternatively, without forwarding it will just be dumped into /var/spool/mail/<user> in plain text.

The rsync command you're using doesn't have any verbose or debug flags, so it will only generate output if there is an error.

Arch Linux

#1 2014-01-06 18:40:36

run exec on cron script carefully

#2 2014-01-07 09:52:38

Re: run exec on cron script carefully

#3 2014-01-07 12:58:07

Re: run exec on cron script carefully

#4 2014-01-07 13:39:48

Re: run exec on cron script carefully

#5 2014-01-07 23:25:43

Re: run exec on cron script carefully

#6 2014-01-07 23:47:41

Re: run exec on cron script carefully

#7 2014-01-10 02:11:48

Re: run exec on cron script carefully

#8 2014-01-10 02:29:49

Re: run exec on cron script carefully

Board footer