Custom Query (684 matches)

After mondobackup complete, we are seeing this mount get left behind. It's small and tends to be over 90% full, which causes our monitoring software to create a ticket.

SLES 12 SP1

# rpm -qa | grep -i mondo
mondo-3.2.2-1.sles12.x86_64
perl-MondoRescue-3.2.2-1.sles12.noarch

# rpm -qa | grep -i mindi
mindi-busybox-1.21.1-1.sles12.x86_64
mindi-3.0.2-1.sles12.x86_64

# df | grep loop
/dev/loop0                                 110766  100996      9770  92% /tmp/syslinux.mnt.10184.0

I've never seen this behavior before. Help?

I'm running Mondo 2.2.0-2 on a modded RH linux 9 box (2.6.17.13 kernel)

For some reason, mondo mounts /dev/shm to a tmp.mondo.[0-9] directory at only 350 megs.

...ran just fine. :-)
Archiving regular files to media
Archiving regular files
                        [TH=5563]
libmondo-archive.c->create_afio_files_in_background#1186:

[5563:0] - EXATing 0...
                        [TH=5563]
libmondo-files.c->find_home_of_exe#431:
find_home_of_exe () --- Found getfattr at
/usr/bin/getfattr
                        [TH=5582]
libmondo-archive.c->create_afio_files_in_background#1186:

[5582:1] - EXATing 1...
                        [TH=5582]
libmondo-files.c->find_home_of_exe#431:
find_home_of_exe () --- Found getfattr at
/usr/bin/getfattr
                        [TH=5582]
libmondo-files.c->find_home_of_exe#431:
find_home_of_exe () --- Found getfacl at
/usr/bin/getfacl
        [TH=5582] libmondo-filelist.c->get_acl_list#620:
libmondo-filelist.c, get_acl_list, 620: getfacl
--all-effective -P //tmp.mondo.114/filelist.1 2>>
/var/log/mondo-archive.log | gzip -c1 >
//tmp.mondo.114/acl_list.1.gz 2>> /var/log/mondo-archive.log
getfacl: Removing leading '/' from absolute path names
                        [TH=5582]
libmondo-archive.c->create_afio_files_in_background#1195:
[5582:1] - archiving 1...
afio: "//tmp.mondo.114/tmpfs/1.afio.bz2" [offset 349m+768k+0]: No
space left on device

df confirms, /dev/shm is mounted at 350 megs and is full. I've seen several posts about this on sourceforge, but know one seems to have a solution.

Any ideas?

The box has 2G of ram.

fstab contains:

none                    /dev/shm                tmpfs   noexec,nosuid
 0 0

mount verifies it is mounted and rw:

none on /dev/shm type tmpfs (rw,noexec,nosuid)

df says:

none                 1015M     0 1015M   0% /dev/shm

I think I found a bug in the mdstat raidlevel parser. For md0, the raidlevel is merged with the device name of the last raid member, resulting in an illegal 'raid1ed1' raidlevel name.

mondoarchive v2.0.8-666
RHEL4 rpm under CENTOS 4.3.
mdadm - v1.6.0 - 4 June 2004
kernel 2.6.9-34.0.2.ELsmp

[root@magrathea /]# cat /proc/mdstat
Personalities : [raid1] [raid5]
md1 : active raid1 hdi3[2] hdg3[1] hde3[0]
10008384 blocks [3/3] [UUU]

md2 : active raid5 hdi4[2] hdg4[1] hde4[0]
346570112 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md0 : active raid1 hdi1[2] hdg1[1] hde1[0]
10008384 blocks [3/3] [UUU]

unused devices: <none>

relevant part of mondo-archive.log:

running: parted2fdisk -l | grep -i raid > /tmp/mondo-run-prog-thing.tmp 2> /tmp/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
/dev/hde1 * 1 1246 10008463+ fd Linux raid autodetect
/dev/hde3 1497 2742 10008495 fd Linux raid autodetect
/dev/hde4 2743 24315 173285122+ fd Linux raid autodetect
/dev/hdg1 * 1 1246 10008463+ fd Linux raid autodetect
/dev/hdg3 1497 2742 10008495 fd Linux raid autodetect
/dev/hdg4 2743 24315 173285122+ fd Linux raid autodetect
/dev/hdi1 * 1 1246 10008463+ fd Linux raid autodetect
/dev/hdi3 1497 2742 10008495 fd Linux raid autodetect
/dev/hdi4 2743 24315 173285122+ fd Linux raid autodetect
--------------------------------end of output------------------------------
...ran just fine. :-)
You have RAID partitions but no /etc/raidtab - creating one from /proc/mdstat
[Main] libmondo-raid.c->parse_mdstat#1100: Unknown RAID level 'raid1ed1'.

Sorry, cannot read /proc/mdstat
Done.