Opened 17 years ago
Closed 15 years ago
#156 closed defect (fixed)
Bad TMPDIR in mindi.conf causes 'mv /* mondo_tmp'
| Reported by: | Scott Cummings | Owned by: | Bruno Cornec |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.2.9 |
| Component: | mindi | Version: | 2.2.1 |
| Severity: | minor | Keywords: | |
| Cc: |
Description
I got a chance to appreciate having a mondo backup (and some practice using it) this way. :)
First, I might have assumed from 'man mindi' that putting a 'TMPDIR' in mindi.conf would be used in mondo, so maybe it should note that mondo supplies it's own tmpdir. I was just looking around for all ways to put temp files on my bigger disk and not overflow my small disk. Now, I realize mindi probably doesn't put that many files out there, but wasn't as smart at first. (maybe include an indication in man mindi of the rough size of stuff put in TMPDIR?).
Anyhow, I moved some mountpoints around and forgot to update TMPDIR in mindi.conf. Then when I ran mondo it reached the running mindi part and things all stopped since /bin and so on were all moved to mondo_tmp.
I have a screen capture of the qemu session where I reproduced this (haven't set up moving files from qemu to main, yet) that I'll see if I can add.
I also wrote a patch - please modify as you see fit. (I see as I was thinking about it the many ways unintended consequences can creep in here.)
Attachments (3)
Change History (8)
by , 17 years ago
| Attachment: | diff.mindi.handle_bad_tempdir added |
|---|
by , 17 years ago
| Attachment: | mindi_erase_bin_etc.png added |
|---|
shows mktemp failing and MINDI_TMP=null
comment:1 by , 17 years ago
P.S. A couple of other thoughts as I was thinking about the patch above were that mindi could just check that the MINDI_TMP creation was successful, but since mindi doesn't use it when called by mondo, I tried to avoid it failing needlessly. (Although, maybe, this check would be best.)
Also, If someone got tricky they could create a 'MINDI_TMP' in mindi.conf and I didn't want that to cause the same problem (this may be stretching things too far).
Doing a 'mv' of the files is certainly better than removing needed files, so I did worry if there was any way the rmdir could do worse damage. I was counting on rmdir not doing anything if the directory was non-empty.
I added the check on MINDI_TMP existence at the end to try to check the that the final MINDI_TMP setting was good to go. (not necessary to solving this particular problem.)
comment:2 by , 17 years ago
| Milestone: | → 3.0.2 |
|---|---|
| Severity: | major → minor |
I never implied that mindi.conf was usable in 2.2.x in fact. Mistake on my side. I've removed its existence from the an page, meaning this is not supported.
The real introduction is for 3.x. Probably some of the problems you mention will still be true, But I want to postpone that for now.
Thanks for your feedback.
comment:3 by , 15 years ago
| Milestone: | 3.0.2 → 2.2.9 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Indeed we ran into the same issue as you last week, with a full FS /tmp leading to the same problem. So it's not something I can difer anymore and I've made a ptch to avoid that issue (rev [2150])
follow-up: 5 comment:4 by , 15 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Hi Bruno,
Thanks for the update. I have one comment on the change. Of course the first part takes care of the problem, but I suggest "paranoid mode" (see second half of rev [2150]) is even more important to this line:
mv $MINDI_TMP/* $MINDI_TMP/.??* $MONDO_TMP 2>> $LOGFILE
If MINDI_TMP = "", this line is the problem! (Does rm -Rf "" cause a problem?)
I suggest removing this line. When we arrive at this point I don't see anyone having written anything into this brand new temporary directory.
What do you think?
comment:5 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Replying to cummings:
Hi Bruno,
Thanks for the update. I have one comment on the change. Of course the first part takes care of the problem, but I suggest "paranoid mode" (see second half of rev [2150]) is even more important to this line:
mv $MINDI_TMP/* $MINDI_TMP/.??* $MONDO_TMP 2>> $LOGFILE
Well at that point MINDI_TMP is safe now. So the only remaining issue could be that MONDO_TMP is wrong. I have indeed added control for that. But this one is really minor now. (Cf: rev [2153])
If
MINDI_TMP = "", this line is the problem! (Doesrm -Rf ""cause a problem?)
Yes but now MINDI_TMP = "" is NOT possible anymore.
I suggest removing this line. When we arrive at this point I don't see anyone having written anything into this brand new temporary directory.
No. We need to transfer what has been created up to now under the temp of mondo if called by mondo.
patch to mindi