Opened 12 years ago

Closed 10 years ago

#156 closed defect (fixed)

Bad TMPDIR in mindi.conf causes 'mv /* mondo_tmp'

Reported by: cummings Owned by: bruno
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)

diff.mindi.handle_bad_tempdir (1.6 KB) - added by cummings 12 years ago.
patch to mindi
mindi_erase_bin_etc.png (78.2 KB) - added by cummings 12 years ago.
shows mktemp failing and MINDI_TMP=null
mindi_erase_bin_etc.2.png (73.1 KB) - added by cummings 12 years ago.
mv /* to a temp directory

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by cummings

patch to mindi

Changed 12 years ago by cummings

shows mktemp failing and MINDI_TMP=null

Changed 12 years ago by cummings

mv /* to a temp directory

comment:1 Changed 12 years ago by cummings

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 Changed 12 years ago by bruno

  • Milestone set to 3.0.2
  • Severity changed from major to 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 Changed 10 years ago by bruno

  • Milestone changed from 3.0.2 to 2.2.9
  • Resolution set to fixed
  • Status changed from new to 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])

comment:4 follow-up: Changed 10 years ago by cummings

  • Resolution fixed deleted
  • Status changed from closed to 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 in reply to: ↑ 4 Changed 10 years ago by bruno

  • Resolution set to fixed
  • Status changed from reopened to 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! (Does rm -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.

Note: See TracTickets for help on using tickets.