Re: DUMP: fopen on /dev/tty fails: Device not configured
On Aug 22 10:54:38, h...@stare.cz wrote: > On Aug 22 00:34:49, guent...@gmail.com wrote: > > On Mon, 22 Aug 2016, Jan Stary wrote: > > > Occasionally, this what tha daily dump of my 5.9-beta/i386 says: > > ... > > > > > > DUMP: Volume 1 started at: Mon Aug 22 01:30:25 2016 > > > > DUMP: dumping (Pass III) [directories] > > > > DUMP: dumping (Pass IV) [regular files] > > > > DUMP: End of tape detected > > ... > > > The daily.local is below - basically just a wrapper > > > around the dumps and tars. The dump call itself is > > > > > > dump -$l -a -u -f - $fs > $f 2> $BKPLOG > > > > The "End of tape detected" message means write() failed or repeatedly > > refused to write the full output. For a disk file like you're using, that > > probably means one of these errors: > > - ENOSPC: file system full (out of disk blocks) > > - EDQUOT: reached user's disk quota > > - EFBIG: reached the file size limit (ala ulimit -f) > > - EIO: disk is dying > > > > If you're sure that it *can't* be any of those, then I suppose you could > > hack dump to report the exact error... > > Ah, I forgot I had this problem before: > https://www.mail-archive.com/misc@openbsd.org/msg135224.html > > I tend to think now it's the disk space. This was a Monday morning dump, > when the /backup is "most full" with the previous week's dumps.[0-6]. > I rm(1) them before doing the fresh dump, but that space probably > only becomes available a bit later due to softdeps (I think). ... and so dump(8) wants to ask about the next volume, but there is no terminal, as this is a crin job - resulting in the err msg.
Re: DUMP: fopen on /dev/tty fails: Device not configured
On Aug 22 00:34:49, guent...@gmail.com wrote: > On Mon, 22 Aug 2016, Jan Stary wrote: > > Occasionally, this what tha daily dump of my 5.9-beta/i386 says: > ... > > > > DUMP: Volume 1 started at: Mon Aug 22 01:30:25 2016 > > > DUMP: dumping (Pass III) [directories] > > > DUMP: dumping (Pass IV) [regular files] > > > DUMP: End of tape detected > ... > > The daily.local is below - basically just a wrapper > > around the dumps and tars. The dump call itself is > > > > dump -$l -a -u -f - $fs > $f 2> $BKPLOG > > The "End of tape detected" message means write() failed or repeatedly > refused to write the full output. For a disk file like you're using, that > probably means one of these errors: > - ENOSPC: file system full (out of disk blocks) > - EDQUOT: reached user's disk quota > - EFBIG: reached the file size limit (ala ulimit -f) > - EIO: disk is dying > > If you're sure that it *can't* be any of those, then I suppose you could > hack dump to report the exact error... Ah, I forgot I had this problem before: https://www.mail-archive.com/misc@openbsd.org/msg135224.html I tend to think now it's the disk space. This was a Monday morning dump, when the /backup is "most full" with the previous week's dumps.[0-6]. I rm(1) them before doing the fresh dump, but that space probably only becomes available a bit later due to softdeps (I think). I will see whether it happens other then Mondays. Thanks for the hints. Jan > > ... > > > DUMP: fopen on /dev/tty fails: Device not configured > > > DUMP: The ENTIRE dump is aborted. > ... > > I wonder how exactly does dump find /dev/tty "not configured". Is the > > redirection of stdout what makes dump deal with tty in the first place? > > When I log into the machine an run sh /etc/daily.local manually, > > everything goes fine. Most nights, the daily.local cronjob goes fine too. > > When a process opens /dev/tty, the kernel (mostly) acts like it opened its > controlling terminal device, whichever that is. If it doesn't have a > controlling terminal then you get that error. c.f. cttyopen() and the > cttyvp() macro in sys/kern/tty_tty.c > > > Philip Guenther
Re: DUMP: fopen on /dev/tty fails: Device not configured
On Mon, 22 Aug 2016, Jan Stary wrote: > Occasionally, this what tha daily dump of my 5.9-beta/i386 says: ... > > DUMP: Volume 1 started at: Mon Aug 22 01:30:25 2016 > > DUMP: dumping (Pass III) [directories] > > DUMP: dumping (Pass IV) [regular files] > > DUMP: End of tape detected ... > The daily.local is below - basically just a wrapper > around the dumps and tars. The dump call itself is > > dump -$l -a -u -f - $fs > $f 2> $BKPLOG The "End of tape detected" message means write() failed or repeatedly refused to write the full output. For a disk file like you're using, that probably means one of these errors: - ENOSPC: file system full (out of disk blocks) - EDQUOT: reached user's disk quota - EFBIG: reached the file size limit (ala ulimit -f) - EIO: disk is dying If you're sure that it *can't* be any of those, then I suppose you could hack dump to report the exact error... ... > > DUMP: fopen on /dev/tty fails: Device not configured > > DUMP: The ENTIRE dump is aborted. ... > I wonder how exactly does dump find /dev/tty "not configured". Is the > redirection of stdout what makes dump deal with tty in the first place? > When I log into the machine an run sh /etc/daily.local manually, > everything goes fine. Most nights, the daily.local cronjob goes fine too. When a process opens /dev/tty, the kernel (mostly) acts like it opened its controlling terminal device, whichever that is. If it doesn't have a controlling terminal then you get that error. c.f. cttyopen() and the cttyvp() macro in sys/kern/tty_tty.c Philip Guenther
DUMP: fopen on /dev/tty fails: Device not configured
Occasionally, this what tha daily dump of my 5.9-beta/i386 says:
On Aug 22 01:31:17, r...@gw.stare.cz wrote:
> OpenBSD 5.9-beta (GENERIC) #1462: Wed Dec 23 18:11:06 MST 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
>
> 1:31AM up 152 days, 14:26, 0 users, load averages: 2.74, 0.92, 0.39
>
> Running daily.local:
>
> Backing up into /backup/gw.stare.cz
>
> errors dumping /var/log:
> DUMP: Date of this level 0 dump: Mon Aug 22 01:30:24 2016
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /dev/rwd0g (/var/log) to standard output
> DUMP: mapping (Pass I) [regular files]
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 118923 tape blocks.
> DUMP: Volume 1 started at: Mon Aug 22 01:30:25 2016
> DUMP: dumping (Pass III) [directories]
> DUMP: dumping (Pass IV) [regular files]
> DUMP: End of tape detected
> DUMP: Volume 1 completed at: Mon Aug 22 01:31:00 2016
> DUMP: Volume 1 took 0:00:35
> DUMP: Volume 1 transfer rate: 3213 KB/s
> DUMP: Change Volumes: Mount volume #2
> DUMP: fopen on /dev/tty fails: Device not configured
> DUMP: The ENTIRE dump is aborted.
The daily.local is below - basically just a wrapper
around the dumps and tars. The dump call itself is
dump -$l -a -u -f - $fs > $f 2> $BKPLOG
I wonder how exactly does dump find /dev/tty "not configured".
Is the redirection of stdout what makes dump deal with tty in the first place?
When I log into the machine an run sh /etc/daily.local manually,
everything goes fine. Most nights, the daily.local cronjob goes fine too.
Jan
#!/bin/sh
umask 077
err() {
echo $@ >&2
}
# We distinguish two kinds of backups:
# BKPDUMP are dump(8)s of entire filesystems - level 0
# on Monday mornings, incerementals during the week.
# These are typically very big, and we store them to
# a dedicated backup disk; typically nfs:/backup
# BKPTAR are tarballs of certain directories (/etc),
# that are tupically much smaller and we rotate them.
# TODO: rotate the old ones out of existence.
# If BKPSCP is defined, we also scp them there. This
# requires an unattended login via a ssh key.
BKPUSR=hans
BKOGRP=wheel
BKPLOG=/tmp/dump.$$.log
BKPDIR=/backup/`hostname`
BKPDMP="/ /var /var/log /home"
BKPTAR="/root /etc /var/backups"
BKPSCP="h...@stare.cz:$BKPDIR"
#BKPSCP="h...@biblio.stare.cz:$BKPDIR"
bkpdmp() {
# $1 is the dump level
l=$1
for fs in $BKPDMP; do
[ "$fs" = "/" ] && fsname=".root" || fsname=`echo $fs | tr / .`
[ "x$l" = "x0" ] && \
rm -f $BKPDIR/dump$fsname.?
f=$BKPDIR/dump$fsname.$l
> $f && chown $BKPUSR:$BKPGRP $f && chmod 600 $f
dump -$l -a -u -f - $fs > $f 2> $BKPLOG \
|| { err errors dumping $fs: ; cat $BKPLOG >&2 ; }
rm -f $BKPLOG
done
{ cd $BKPDIR ; ls -lh dump.* ; }
}
bkptar() {
for dir in $BKPTAR; do
f=$BKPDIR/`echo ${dir#/} | tr / -`-`date +%Y%m%d%H%M`.tar.gz
> $f && chown $BACKUPUSR:$BACKUPGRP $f && chmod 600 $f
tar czf $f $dir 2> /dev/null
# TODO: md5
{ cd $BKPDIR ; ls -lh ${f##*/} ; }
scp -q $f $BKPSCP
done
}
if test -d $BKPDIR ; then
echo; echo Backing up into $BKPDIR; echo
bkpdmp $((`date +%u` - 1))
bkptar
else
err Backup directory $BKPDIR does not exist
fi
