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
Re: DUMP: fopen on /dev/tty fails
On Mon, Jan 05, 2015 at 12:19:13PM +0100, Otto Moerbeek wrote: On Mon, Jan 05, 2015 at 11:33:13AM +0100, Jan Stary wrote: On Jan 05 10:58:02, o...@drijf.net wrote: On Mon, Jan 05, 2015 at 10:19:54AM +0100, Jan Stary wrote: This is a daily mail from my Alix router. I do a dump in daily.local (see below) and most of the time it works just fine. Occasionaly though, the DUMP fails saying DUMP: End of tape detected DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015 DUMP: Volume 1 took 0:00:07 DUMP: Volume 1 transfer rate: 2101 KB/s DUMP: Change Volumes: Mount volume #2 DUMP: fopen on /dev/tty fails: Device not configured DUMP: The ENTIRE dump is aborted. That puzzles me, as I dump to stdout, redirecting to a file (see below). (I vaguely remember that the reason I switched from dump -f file.dump ... to dump -f - ... file.dump was that I was advised her by a developer about the tape legacy of dump, but I forgot what exactly was the problem then and can't find it in archives.) Why would dump -f - ... file.dump think that it reached an end of tape? Because dump is a bit dumb. You need to use -a, see man page. But I do, see the code below. Hmm indeed, then it's my guess you are running out of disk. The numbers do not seems to warrant that, though. So I have no real clue. Or did you play with tunefs -m ? -Otto How about using the -n flag to find out what dump wants by being logged on as a user in group 'operator' while dump runs? / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: DUMP: fopen on /dev/tty fails
On Mon, Jan 05, 2015 at 10:19:54AM +0100, Jan Stary wrote:
This is a daily mail from my Alix router.
I do a dump in daily.local (see below)
and most of the time it works just fine.
Occasionaly though, the DUMP fails saying
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
That puzzles me, as I dump to stdout,
redirecting to a file (see below).
(I vaguely remember that the reason I switched from
dump -f file.dump ... to dump -f - ... file.dump
was that I was advised her by a developer about
the tape legacy of dump, but I forgot what exactly
was the problem then and can't find it in archives.)
Why would dump -f - ... file.dump think
that it reached an end of tape?
Because dump is a bit dumb. You need to use -a, see man page.
-Otto
On Jan 05 01:31:08, r...@gw.stare.cz wrote:
OpenBSD 5.3-current (GENERIC) #2: Thu Jun 13 00:04:14 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
1:31AM up 1 day, 16:35, 0 users, load averages: 1.61, 0.66, 0.34
Running daily.local:
Backing up into /backup/gw.stare.cz
errors dumping /var/log:
DUMP: Date of this level 0 dump: Mon Jan 5 01:30:31 2015
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 31599 tape blocks.
DUMP: Volume 1 started at: Mon Jan 5 01:30:37 2015
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
-rw--- 1 hans wheel 4.5M Jan 5 01:30 dump.home.0
-rw--- 1 hans wheel 53.1M Jan 5 01:30 dump.root.0
-rw--- 1 hans wheel 7.7M Jan 5 01:30 dump.var.0
-rw--- 1 hans wheel 14.3M Jan 5 01:30 dump.var.log.0
-rw--- 1 hans wheel 820K Jan 5 01:30 dump.var.spool.0
-rw--- 1 root wheel 5.2K Jan 5 01:30 root-201501050130.tar.gz
-rw--- 1 root wheel 1.3M Jan 5 01:31 etc-201501050130.tar.gz
-rw--- 1 root wheel 481K Jan 5 01:31
var-backups-201501050131.tar.gz
-rw--- 1 root wheel 4.2K Jan 5 01:31 var-named-201501050131.tar.gz
Checking subsystem status:
disks:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 204542 5374014057628%/
/dev/wd0d 60868619058038767233%/usr
/dev/wd0e 251822 2825821097412%/usr/local
/dev/wd0f 251822 701023 3%/var
/dev/wd0g 251822 3215620707613%/var/log
/dev/wd0h 1024526 2973298 0%/tmp
/dev/wd0i 299054 4212279890 1%/home
/dev/wd0j 102452679513017817082%/backup
Last dump(s) done (Dump '' file systems):
/dev/rwd0a( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0f( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0g( ) Last dump: Level 6, Date Sun Jan 4 01:30
/dev/rwd0i( ) Last dump: Level 0, Date Mon Jan 5 01:30
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.
# 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`
BKPTAR=/etc /var/backups
BKPSCP=h...@biblio.stare.cz:$BKPDIR
BKPDMP=/ /var /var/mysql /var/postgresql /var/www /home
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
Re: DUMP: fopen on /dev/tty fails
On Mon, Jan 05, 2015 at 11:33:13AM +0100, Jan Stary wrote:
On Jan 05 10:58:02, o...@drijf.net wrote:
On Mon, Jan 05, 2015 at 10:19:54AM +0100, Jan Stary wrote:
This is a daily mail from my Alix router.
I do a dump in daily.local (see below)
and most of the time it works just fine.
Occasionaly though, the DUMP fails saying
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
That puzzles me, as I dump to stdout,
redirecting to a file (see below).
(I vaguely remember that the reason I switched from
dump -f file.dump ... to dump -f - ... file.dump
was that I was advised her by a developer about
the tape legacy of dump, but I forgot what exactly
was the problem then and can't find it in archives.)
Why would dump -f - ... file.dump think
that it reached an end of tape?
Because dump is a bit dumb. You need to use -a, see man page.
But I do, see the code below.
Hmm indeed, then it's my guess you are running out of disk. The
numbers do not seems to warrant that, though. So I have no real clue.
Or did you play with tunefs -m ?
-Otto
Jan
On Jan 05 01:31:08, r...@gw.stare.cz wrote:
OpenBSD 5.3-current (GENERIC) #2: Thu Jun 13 00:04:14 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
1:31AM up 1 day, 16:35, 0 users, load averages: 1.61, 0.66, 0.34
Running daily.local:
Backing up into /backup/gw.stare.cz
errors dumping /var/log:
DUMP: Date of this level 0 dump: Mon Jan 5 01:30:31 2015
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 31599 tape blocks.
DUMP: Volume 1 started at: Mon Jan 5 01:30:37 2015
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
-rw--- 1 hans wheel 4.5M Jan 5 01:30 dump.home.0
-rw--- 1 hans wheel 53.1M Jan 5 01:30 dump.root.0
-rw--- 1 hans wheel 7.7M Jan 5 01:30 dump.var.0
-rw--- 1 hans wheel 14.3M Jan 5 01:30 dump.var.log.0
-rw--- 1 hans wheel 820K Jan 5 01:30 dump.var.spool.0
-rw--- 1 root wheel 5.2K Jan 5 01:30 root-201501050130.tar.gz
-rw--- 1 root wheel 1.3M Jan 5 01:31 etc-201501050130.tar.gz
-rw--- 1 root wheel 481K Jan 5 01:31
var-backups-201501050131.tar.gz
-rw--- 1 root wheel 4.2K Jan 5 01:31
var-named-201501050131.tar.gz
Checking subsystem status:
disks:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 204542 5374014057628%/
/dev/wd0d 60868619058038767233%/usr
/dev/wd0e 251822 2825821097412%/usr/local
/dev/wd0f 251822 701023 3%/var
/dev/wd0g 251822 3215620707613%/var/log
/dev/wd0h 1024526 2973298 0%/tmp
/dev/wd0i 299054 4212279890 1%/home
/dev/wd0j 102452679513017817082%/backup
Last dump(s) done (Dump '' file systems):
/dev/rwd0a( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0f( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0g( ) Last dump: Level 6, Date Sun Jan 4 01:30
/dev/rwd0i( ) Last dump: Level 0, Date Mon Jan 5 01:30
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.
# 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`
BKPTAR=/etc /var/backups
BKPSCP=h...@biblio.stare.cz:$BKPDIR
BKPDMP=/ /var /var/mysql /var/postgresql /var/www /home
bkpdmp() {
# $1
Re: DUMP: fopen on /dev/tty fails
On Jan 05 10:58:02, o...@drijf.net wrote:
On Mon, Jan 05, 2015 at 10:19:54AM +0100, Jan Stary wrote:
This is a daily mail from my Alix router.
I do a dump in daily.local (see below)
and most of the time it works just fine.
Occasionaly though, the DUMP fails saying
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
That puzzles me, as I dump to stdout,
redirecting to a file (see below).
(I vaguely remember that the reason I switched from
dump -f file.dump ... to dump -f - ... file.dump
was that I was advised her by a developer about
the tape legacy of dump, but I forgot what exactly
was the problem then and can't find it in archives.)
Why would dump -f - ... file.dump think
that it reached an end of tape?
Because dump is a bit dumb. You need to use -a, see man page.
But I do, see the code below.
Jan
On Jan 05 01:31:08, r...@gw.stare.cz wrote:
OpenBSD 5.3-current (GENERIC) #2: Thu Jun 13 00:04:14 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
1:31AM up 1 day, 16:35, 0 users, load averages: 1.61, 0.66, 0.34
Running daily.local:
Backing up into /backup/gw.stare.cz
errors dumping /var/log:
DUMP: Date of this level 0 dump: Mon Jan 5 01:30:31 2015
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 31599 tape blocks.
DUMP: Volume 1 started at: Mon Jan 5 01:30:37 2015
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
-rw--- 1 hans wheel 4.5M Jan 5 01:30 dump.home.0
-rw--- 1 hans wheel 53.1M Jan 5 01:30 dump.root.0
-rw--- 1 hans wheel 7.7M Jan 5 01:30 dump.var.0
-rw--- 1 hans wheel 14.3M Jan 5 01:30 dump.var.log.0
-rw--- 1 hans wheel 820K Jan 5 01:30 dump.var.spool.0
-rw--- 1 root wheel 5.2K Jan 5 01:30 root-201501050130.tar.gz
-rw--- 1 root wheel 1.3M Jan 5 01:31 etc-201501050130.tar.gz
-rw--- 1 root wheel 481K Jan 5 01:31
var-backups-201501050131.tar.gz
-rw--- 1 root wheel 4.2K Jan 5 01:31
var-named-201501050131.tar.gz
Checking subsystem status:
disks:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 204542 5374014057628%/
/dev/wd0d 60868619058038767233%/usr
/dev/wd0e 251822 2825821097412%/usr/local
/dev/wd0f 251822 701023 3%/var
/dev/wd0g 251822 3215620707613%/var/log
/dev/wd0h 1024526 2973298 0%/tmp
/dev/wd0i 299054 4212279890 1%/home
/dev/wd0j 102452679513017817082%/backup
Last dump(s) done (Dump '' file systems):
/dev/rwd0a ( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0f ( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0g ( ) Last dump: Level 6, Date Sun Jan 4 01:30
/dev/rwd0i ( ) Last dump: Level 0, Date Mon Jan 5 01:30
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.
# 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`
BKPTAR=/etc /var/backups
BKPSCP=h...@biblio.stare.cz:$BKPDIR
BKPDMP=/ /var /var/mysql /var/postgresql /var/www /home
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
DUMP: fopen on /dev/tty fails
This is a daily mail from my Alix router.
I do a dump in daily.local (see below)
and most of the time it works just fine.
Occasionaly though, the DUMP fails saying
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
That puzzles me, as I dump to stdout,
redirecting to a file (see below).
(I vaguely remember that the reason I switched from
dump -f file.dump ... to dump -f - ... file.dump
was that I was advised her by a developer about
the tape legacy of dump, but I forgot what exactly
was the problem then and can't find it in archives.)
Why would dump -f - ... file.dump think
that it reached an end of tape?
On Jan 05 01:31:08, r...@gw.stare.cz wrote:
OpenBSD 5.3-current (GENERIC) #2: Thu Jun 13 00:04:14 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
1:31AM up 1 day, 16:35, 0 users, load averages: 1.61, 0.66, 0.34
Running daily.local:
Backing up into /backup/gw.stare.cz
errors dumping /var/log:
DUMP: Date of this level 0 dump: Mon Jan 5 01:30:31 2015
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 31599 tape blocks.
DUMP: Volume 1 started at: Mon Jan 5 01:30:37 2015
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
-rw--- 1 hans wheel 4.5M Jan 5 01:30 dump.home.0
-rw--- 1 hans wheel 53.1M Jan 5 01:30 dump.root.0
-rw--- 1 hans wheel 7.7M Jan 5 01:30 dump.var.0
-rw--- 1 hans wheel 14.3M Jan 5 01:30 dump.var.log.0
-rw--- 1 hans wheel 820K Jan 5 01:30 dump.var.spool.0
-rw--- 1 root wheel 5.2K Jan 5 01:30 root-201501050130.tar.gz
-rw--- 1 root wheel 1.3M Jan 5 01:31 etc-201501050130.tar.gz
-rw--- 1 root wheel 481K Jan 5 01:31 var-backups-201501050131.tar.gz
-rw--- 1 root wheel 4.2K Jan 5 01:31 var-named-201501050131.tar.gz
Checking subsystem status:
disks:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 204542 5374014057628%/
/dev/wd0d 60868619058038767233%/usr
/dev/wd0e 251822 2825821097412%/usr/local
/dev/wd0f 251822 701023 3%/var
/dev/wd0g 251822 3215620707613%/var/log
/dev/wd0h 1024526 2973298 0%/tmp
/dev/wd0i 299054 4212279890 1%/home
/dev/wd0j 102452679513017817082%/backup
Last dump(s) done (Dump '' file systems):
/dev/rwd0a ( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0f ( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0g ( ) Last dump: Level 6, Date Sun Jan 4 01:30
/dev/rwd0i ( ) Last dump: Level 0, Date Mon Jan 5 01:30
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.
# 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`
BKPTAR=/etc /var/backups
BKPSCP=h...@biblio.stare.cz:$BKPDIR
BKPDMP=/ /var /var/mysql /var/postgresql /var/www /home
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 $BKPLOG \
|| { err errors tarring $dir: ; cat $BKPLOG 2 ; }
# TODO: md5
Re: DUMP: fopen on /dev/tty fails
On Jan 05 12:19:13, o...@drijf.net wrote:
On Mon, Jan 05, 2015 at 11:33:13AM +0100, Jan Stary wrote:
On Jan 05 10:58:02, o...@drijf.net wrote:
On Mon, Jan 05, 2015 at 10:19:54AM +0100, Jan Stary wrote:
This is a daily mail from my Alix router.
I do a dump in daily.local (see below)
and most of the time it works just fine.
Occasionaly though, the DUMP fails saying
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
That puzzles me, as I dump to stdout,
redirecting to a file (see below).
(I vaguely remember that the reason I switched from
dump -f file.dump ... to dump -f - ... file.dump
was that I was advised her by a developer about
the tape legacy of dump, but I forgot what exactly
was the problem then and can't find it in archives.)
Why would dump -f - ... file.dump think
that it reached an end of tape?
Because dump is a bit dumb. You need to use -a, see man page.
But I do, see the code below.
Hmm indeed, then it's my guess you are running out of disk. The
numbers do not seems to warrant that, though.
Hm. This is dump of level 0, on a Monday morning,
when I rm the previous dumps and start anew
- could it be that the free space made by rm
only becomes available a _bit_ late due to softdep?
[ 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
Because that happens, right? Create a few huge files
on a softdep FS, then remove them; the free space
only appears a bit later.
I will try to add a sync in between the rm and the dump -0
So I have no real clue.
Or did you play with tunefs -m ?
No.
Jan
On Jan 05 01:31:08, r...@gw.stare.cz wrote:
OpenBSD 5.3-current (GENERIC) #2: Thu Jun 13 00:04:14 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
1:31AM up 1 day, 16:35, 0 users, load averages: 1.61, 0.66, 0.34
Running daily.local:
Backing up into /backup/gw.stare.cz
errors dumping /var/log:
DUMP: Date of this level 0 dump: Mon Jan 5 01:30:31 2015
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 31599 tape blocks.
DUMP: Volume 1 started at: Mon Jan 5 01:30:37 2015
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: End of tape detected
DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015
DUMP: Volume 1 took 0:00:07
DUMP: Volume 1 transfer rate: 2101 KB/s
DUMP: Change Volumes: Mount volume #2
DUMP: fopen on /dev/tty fails: Device not configured
DUMP: The ENTIRE dump is aborted.
-rw--- 1 hans wheel 4.5M Jan 5 01:30 dump.home.0
-rw--- 1 hans wheel 53.1M Jan 5 01:30 dump.root.0
-rw--- 1 hans wheel 7.7M Jan 5 01:30 dump.var.0
-rw--- 1 hans wheel 14.3M Jan 5 01:30 dump.var.log.0
-rw--- 1 hans wheel 820K Jan 5 01:30 dump.var.spool.0
-rw--- 1 root wheel 5.2K Jan 5 01:30 root-201501050130.tar.gz
-rw--- 1 root wheel 1.3M Jan 5 01:31 etc-201501050130.tar.gz
-rw--- 1 root wheel 481K Jan 5 01:31
var-backups-201501050131.tar.gz
-rw--- 1 root wheel 4.2K Jan 5 01:31
var-named-201501050131.tar.gz
Checking subsystem status:
disks:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 204542 5374014057628%/
/dev/wd0d 60868619058038767233%/usr
/dev/wd0e 251822 2825821097412%/usr/local
/dev/wd0f 251822 701023 3%/var
/dev/wd0g 251822 3215620707613%/var/log
/dev/wd0h 1024526 2973298 0%/tmp
/dev/wd0i 299054 4212279890 1%/home
/dev/wd0j 102452679513017817082%/backup
Last dump(s) done (Dump '' file systems):
/dev/rwd0a ( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0f ( ) Last dump: Level 0, Date Mon Jan 5 01:30
/dev/rwd0g ( ) Last dump: Level 6, Date Sun Jan 4 01:30
/dev/rwd0i ( ) Last dump: Level 0, Date Mon Jan 5 01:30
Jan
#!/bin/sh
umask 077
err() {
echo $@ 2
}
# We distinguish two kinds of backups:
# BKPDUMP
Re: DUMP: fopen on /dev/tty fails
Jan Stary h...@stare.cz writes: On Jan 05 12:19:13, o...@drijf.net wrote: On Mon, Jan 05, 2015 at 11:33:13AM +0100, Jan Stary wrote: On Jan 05 10:58:02, o...@drijf.net wrote: On Mon, Jan 05, 2015 at 10:19:54AM +0100, Jan Stary wrote: This is a daily mail from my Alix router. I do a dump in daily.local (see below) and most of the time it works just fine. Occasionaly though, the DUMP fails saying DUMP: End of tape detected DUMP: Volume 1 completed at: Mon Jan 5 01:30:44 2015 DUMP: Volume 1 took 0:00:07 DUMP: Volume 1 transfer rate: 2101 KB/s DUMP: Change Volumes: Mount volume #2 DUMP: fopen on /dev/tty fails: Device not configured DUMP: The ENTIRE dump is aborted. That puzzles me, as I dump to stdout, redirecting to a file (see below). (I vaguely remember that the reason I switched from dump -f file.dump ... to dump -f - ... file.dump was that I was advised her by a developer about the tape legacy of dump, but I forgot what exactly was the problem then and can't find it in archives.) Why would dump -f - ... file.dump think that it reached an end of tape? Because dump is a bit dumb. You need to use -a, see man page. But I do, see the code below. Hmm indeed, then it's my guess you are running out of disk. The numbers do not seems to warrant that, though. Hm. This is dump of level 0, on a Monday morning, when I rm the previous dumps and start anew - could it be that the free space made by rm only becomes available a _bit_ late due to softdep? [ 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 Because that happens, right? Create a few huge files on a softdep FS, then remove them; the free space only appears a bit later. I will try to add a sync in between the rm and the dump -0 I have had this type of message when dump asks some question to the operator. I don't remember what the issue was and cannot reproduce. It was on level 1 dump too. -- Manuel Giraud
