Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: Leee on February 18, 2022, 04:28:34 PM
-
Are there any "cron" gurus here? I'm curious if I'm misunderstanding how cron works...
<tldr_history> I recently lost data when I rebooted a TinyCore 13.0 (x86_64) box during the update from 13.0a1 to 13.0 without making a backup first. Not like I haven't been doing this for over a decade - I guess I was just having a bad day which, of course, got worse when I realized I'd lost a couple of weeks worth of journals and script updates... and notes relating to closing out my previous job and looking for a new one. Grrr.
So I decided to finally fire up cron and have a backup made on a regular basis every couple of hours, but only if there's something new to include in the backup. I wrote a handy script that checks certain directories for new/modified files, does some logging, preserves the most recent backup, makes new backup etc etc.
</tldr_history>
My script runs great from the command line and simply uses filetool.sh -b to make the backup when needed. Nothing fancy except deciding whether or not to actually make a backup on any given run.
So I scheduled it in the crontab for user tc and it works there, too.
But when cron runs it, mydata.tgz is owned by root:root. This would seem to me to imply that the job actually runs as root:root, not as tc:staff.
So I put a line into my script, right after the backup is made, to chown tc:staff mydata.tgz. But chown failed for lack of permission. This would seem to me to imply that the job does NOT run as root:root. Indeed, the fact that cron finds the script at all (in /home/tc/bin) implies that it's running as tc, not as root.
The simple fix was to change the chown line to sudo chown tc:staff mydata.tgz, which works but begs the question "Why was mydata.tgz owned by root:root in the first place?"
The crontab entry looks like this:
0 */2 * * * autobak -c >>/tmp/autobak.log 2>&1
While the forum won't let me post the shell script in a script tag, suffice it to say there's no fiddling around with user names when invoking filetool.sh - the script just runs it in whatever the current context is.
Any ideas about the ownership of the backup file?
-
Hi Leee,
mydata.tgz is owned by root:root after every filetool.sh -b execution, no matter manual or scripted. So everything is ok with Your crontab script. Don't worry about mydata.tgz ownership, it will be $USER:staff upon the next boot.
Have a nice Core!
-
Hi jazzbiker
That's odd, I just ran a backup using filetool (GUI) and filetool.sh -b. In both cases, ownership remained tc:staff.
-
Hmm...
I just ran filetool.sh -b twice directly at the command line - once with sudo and once without. In both cases mydata.tgz was owned by tc:staff immediately afterward. While it's not terribly important as far as the backup is concerned, it just made me curious as to why it's different when run under cron. I'm certainly not an expert with cron, so it was easy to assume I'd done something iffy.
@Rich: There's a GUI for that!? :) I guess I ought to pay more attention to such things... just like I only recently realized there's a tce-update command. :o
-
Hi Leee
... There's a GUI for that!? ...
Yes there is. From the command line run:
filetool
Or call up the ControlPanel applet and click the Backup/Restore button.
-
Hi jazzbiker
That's odd, I just ran a backup using filetool (GUI) and filetool.sh -b. In both cases, ownership remained tc:staff.
You're right as usual :) The even form of my statement must be:
If You run "filetool.sh -b" for the first time or You are using "-s" option or You applied "safebackup" boot option, then mydata.tgz will be owned by root:root. Otherwise (mydata.tgz is not created but updated) the owner will remain unchanged.
After reading Your and Leee's messages I've got the feeling, that it's enough of "Rick and Morthy" :) I've tested all TC's from 10 to 13 and everywhere I saw root:root. In fact "sudo tar c ..." applies "root:root" only in the case it is really creating the archive. In the case of update it preserves the owner. In filetool.sh [ "$SAFE" ] case is described as "Copying existing backup ..." but instead of "cp" the "mv" is used. I use "safebackup" bootcode in all my installs, while You, guys, appear not to do this :)
I guess the initial Leee's post was caused by the absence of mydata.tgz and tar really created it with "root:root" owner. But later the problem disappeared because tce-setup gives the whole $TCEDIR to $USER:staff.
Small but unexpected trap. It can be corrected, of course, but is it necessary? Of course it is fine to avoid any ambiguities in TC behavior. I think the easiest way will be to change "mv" commands applied to the "$MYDATA".tgz with the "cp" commands in the [ "$SAFE" ] subsection of the [ "$BACKUP" ] section of filetool.sh. Such a decision will leave only initial backup file unaffected. All consequent incarnations of "$MYDATA".tgz will be user-owned.
-
And by the way the topic title seems to appear ambiguous, it may mislead someone. Wouldn't it be better to rename it?
-
Still copying of the file which will be replaced immediately seems to be dumb. Explicit 'sudo chown "$USER":staff' will close all the holes.
-
Hmm...
I just ran filetool.sh -b twice directly at the command line - once with sudo and once without
By the way if I am not mistaken it is not recommended to run filetool.sh as root.
-
The diff for filetool.sh, TC13.0 x86 attached.
-
IIRC there is a problem running filetool.sh as root, then running it as tc.
The temp files will be owned by root and this causes a problem when running as tc.
NOTE: Only tried this on piCore and it was years ago.
-
Hi Greg Erskine,
I got "mydata.tgz" owned by "root:root" running "filetool.sh -b" as tc with "safebackup" bootcode. If You don't apply this bootcode, You can run "filetool.sh -b -s" and obtain the same ownership. Or simply rename Your "mydata.tgz" and run "filetool.sh -b". The key is whether "mydata.tgz" is created or updated.
"tar" in "filetool.sh" is run with "sudo" and naturally create files with corresponding ownership. While updating doesn't affect the ownership.
I have no Raspberries and can not test mentioned above trick on PiCore, it would be interesting to. I suppose the core-scripts are the same. If tar's behavior is the same too, then this ownership games will look the same for PiCore. If it is not difficult for You can You please check?
-
This is fascinating and it explains the ownership issue I noticed. I'm sure I've peeked inside filetool.sh in the deep past but it's been a really long time. I had no idea it was updating mydata.tgz rather than creating a new one each time.
In this case, I explicitly wanted to keep a couple of generations of mydata around, which will eat up some storage. So, in the interest of not gobbling up -too- much space, I used mv to rename mydata.tgz to mydata_$HOSTNAME_$DATETIME.tgz and then dumped the oldest generation -before- making the new back up. That forced creation of a new mydata.tgz, so there it is. At some point, I'll use another cron job to move mydata_$HOSTNAME_$DATETIME.tgz off to another host with a real hard disk (where I'll still rotate out the old ones, of course). The host I'm fooling with now is running off of an 8GB USB stick, which is plenty for what I'm doing with it but small enough I don't want to be -too- wasteful of space. It's an HP thin client and I'm testing now to see if its USB 3.0 port has enough juice to support an actual hard drive.
Regarding By the way if I am not mistaken it is not recommended to run filetool.sh as root.
I think this was the only time I've ever done that and only now trying to track down the ownership issue....
Although... when I think about it... if filetool.sh, run by tc and back up and restore files belonging to root, I don't suppose there should be an issue with root backing up everyone else's files (and of course root restores everything from backup on every reboot). I try not to waste too many brain cells on such thoughts until I'm ready to sit down with the base scripts and really grok the whole process because there are parts that seem counter-intuitive (like why tce-load expclicitly can't be run as root).
-
@jazzbiker
I was referring to the ownership of these temp files.
tc@pCP4B8LMS:/tmp$ la backup_*
-rw-r--r-- 1 root root 0 Feb 21 11:27 backup_done
-rw-r--r-- 1 tc staff 0 Feb 21 11:27 backup_status
tc@pCP4B8LMS:/tmp$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz touch: /tmp/backup_done: Permission denied
Done.
-
@jazzbiker
Without/with the -s option.
tc@pCP4B8LMS:/tmp$ filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz
Done.
tc@pCP4B8LMS:/tmp$ ls -la /mnt/mmcblk0p2/tce/mydata.tgz
-rw-rw-r-- 1 tc staff 290695 Feb 21 11:35 /mnt/mmcblk0p2/tce/mydata.tgz
tc@pCP4B8LMS:/tmp$ sudo filetool.sh -b
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz
Done.
tc@pCP4B8LMS:/tmp$ ls -la /mnt/mmcblk0p2/tce/mydata.tgz
-rw-rw-r-- 1 tc staff 290696 Feb 21 11:36 /mnt/mmcblk0p2/tce/mydata.tgz
tc@pCP4B8LMS:/tmp$ sudo filetool.sh -b -s
Copying existing backup to /mnt/mmcblk0p2/tce/mydatabk.[tgz|tgz.bfe] ..
Done.
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz
Done.
tc@pCP4B8LMS:/tmp$ ls -la /mnt/mmcblk0p2/tce/mydata.tgz
-rw-r--r-- 1 root root 290695 Feb 21 11:38 /mnt/mmcblk0p2/tce/mydata.tgz
tc@pCP4B8LMS:/tmp$ filetool.sh -b -s
Copying existing backup to /mnt/mmcblk0p2/tce/mydatabk.[tgz|tgz.bfe] ..
Done.
Backing up files to /mnt/mmcblk0p2/tce/mydata.tgz
Done.
tc@pCP4B8LMS:/tmp$ ls -la /mnt/mmcblk0p2/tce/mydata.tgz
-rw-r--r-- 1 root root 290703 Feb 21 11:39 /mnt/mmcblk0p2/tce/mydata.tgz
-
@Greg Erskine
Thanks for testing, behavior is the same as for x86. The proposed patch very likely will stabilize mydata.tgz ownership for PiCore too.
I played a little with backup_done and backup_status files. The main idea that I've gathered is that no matter what user is running "filetool.sh -b". The message about permission violation is issued by
t_o_u_c_h /tmp/backup_done
and doesn't affects the backup functionality. Even if You see it (though it is not very pleasant) backup is being performed successfully and exit code is 0. In other words if backup_done was created by root, an attempt of non-privileged user to touch it will fail, but this means that file exists, so the touch goal is reached. I propose simply suppress the error message like:
t_o_u_c_h /tmp/backup_done 2>/dev/null
What's Your opinion?
-
* * * * * su -c "filetool.sh -b" tcJust run the CRON job "as" the TC user - permission issues solved
-
@jazzbiker
I should have mentioned that I tested on piCorePlayer not piCore, but it should the same. Our kernel version usually differ.
As I don't use standard piCore, tinycore, dCore etc it would not be right for me to suggest changes that I haven't tested properly.
For piCorePlayer we just have a function called pcp_backup that handles anomalies.
-
@Greg Erskine
Thanks for the tip! I think kernels difference may have no influence, busybox tar behavior is pace-maker. Anomalies are to fly away :)
Have a nice piCorePlayer :)