Opened 14 years ago

Closed 14 years ago

#446 closed defect (fixed)

mondoarchive performs mv command on an excluded path

Reported by: hblanco Owned by: Bruno Cornec
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 14 years ago.
mondoarchive.log (124.3 KB ) - added by hblanco 14 years ago.

Download all attachments as: .zip

Change History (9)

by hblanco, 14 years ago

Attachment: mindi.log added

by hblanco, 14 years ago

Attachment: mondoarchive.log added

comment:1 by hblanco, 14 years ago

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 by hblanco, 14 years ago

Priority: normalhighest
Severity: normalcritical

comment:3 by hblanco, 14 years ago

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 by hblanco, 14 years ago

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 by Bruno Cornec, 14 years ago

Status: newassigned

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.

in reply to:  5 comment:6 by hblanco, 14 years ago

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 by Bruno Cornec, 14 years ago

Component: mondomindi
Resolution: fixed
Status: assignedclosed

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.