Opened 9 years ago

Closed 9 years ago

#446 closed defect (fixed)

mondoarchive performs mv command on an excluded path

Reported by: hblanco Owned by: bruno
Priority: highest Milestone: 2.2.9.5
Component: mindi Version: 2.2.9.4
Severity: critical Keywords:
Cc:

Description

During a mondoarchive operation a mv command was performed on an excluded path. I have attached the mindi.log and mondoarchive.log.

Attachments (2)

mindi.log (36.5 KB) - added by hblanco 9 years ago.
mondoarchive.log (124.3 KB) - added by hblanco 9 years ago.

Download all attachments as: .zip

Change History (9)

Changed 9 years ago by hblanco

Changed 9 years ago by hblanco

comment:1 Changed 9 years ago by hblanco

Running this on another server with similar directory structure and this did not happen. The only difference was that /tmp was write protected read-only on the bad server.

comment:2 Changed 9 years ago by hblanco

  • Priority changed from normal to highest
  • Severity changed from normal to critical

comment:3 Changed 9 years ago by hblanco

I have just reproduced the issue on another server. Ran mondoarchive with /tmp as RW and ISO was generated with no issues. As soon as I made /tmp RO mondoarchive started to move files out of /bin and other directories eventually hosing the system. Please help in identifying this bug.

comment:4 Changed 9 years ago by hblanco

Looks like a lockfile is trying to be created in /tmp ???

Waiting for external binary to start

[Main] libmondo-fork.c->run_program_and_log_to_screen#406: Waiting for lockfile /mondo/l-esx-1-2010-09-15/temp/mondo.tmp.Ljn68O/mojo-jojo.bla.bla to exist

mktemp: cannot make temp dir /tmp/mindi.zbrtH29084: Read-only file system

Is this mindi fault???

comment:5 follow-up: Changed 9 years ago by bruno

  • Status changed from new to assigned

While I recognize that mondo/mindi could be more friendly when encountering this ro /tmp and not screw up the system, it's the first time I see a Unix based system wihtout a writable /tmp in 23+ years !!

Could you mention the Distribution/version/architecture you are using ? I may just announce we are not supporting such systems as well.

comment:6 in reply to: ↑ 5 Changed 9 years ago by hblanco

Replying to bruno:

While I recognize that mondo/mindi could be more friendly when encountering this ro /tmp and not screw up the system, it's the first time I see a Unix based system wihtout a writable /tmp in 23+ years !!

Could you mention the Distribution/version/architecture you are using ? I may just announce we are not supporting such systems as well.

The server is running RHEL 5.5 x86_64 and the reason that /tmp went RO was because the filesystem got corrupted and could only be restored by formatting. fsck couldn't even fix it. By looking at /usr/sbin/mindi it looks like the script should go to the Die() function and abort??? Is my assumption wrong ???

comment:7 Changed 9 years ago by bruno

  • Component changed from mondo to mindi
  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in mindi rev [2685] where declaring Die function earlier will allow mindi to indeed exit in very weird cases such as /tmp ro Will be fixed as of 2.0.7.6

Note: See TracTickets for help on using tickets.