From owner-freebsd-questions Sat Jan 15 8:47: 3 2000 Delivered-To: freebsd-questions@freebsd.org Received: from cc1017255-a.srst1.fl.home.com (cc1017255-a.srst1.fl.home.com [24.3.122.197]) by hub.freebsd.org (Postfix) with ESMTP id 869D614D3A for ; Sat, 15 Jan 2000 08:47:00 -0800 (PST) (envelope-from hg@cally.south.mpcs.com) Received: from cally.south.mpcs.com (cally [172.16.0.6]) by cc1017255-a.srst1.fl.home.com (Postfix) with ESMTP id 12E831E5A; Sat, 15 Jan 2000 11:46:59 -0500 (EST) Received: by cally.south.mpcs.com (Postfix, from userid 1000) id A20DA23B; Sat, 15 Jan 2000 11:46:57 -0500 (EST) From: hgoldste@mpcs.com To: maret@atrada.de Cc: freebsd-questions@freebsd.org Subject: Re: Amanda Problems In-Reply-To: <58A002A02C5ED311812E0050044517F00D2487@erlangen01.atrada.de> References: <58A002A02C5ED311812E0050044517F00D2487@erlangen01.atrada.de> Reply-To: hgoldste@bbs.mpcs.com Message-Id: <20000115164657.A20DA23B@cally.south.mpcs.com> Date: Sat, 15 Jan 2000 11:46:57 -0500 (EST) Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In mpc.lists.freebsd.questions, you wrote: : But meanwhile I solved a part of my problem as described in my 2. posting. : Unfortunately I now get an exit status of 0x100 from amandad. : As I searched arround in the mail archives I saw that many people have : problems with daemons exiting 0x100 when they are started by inetd. : : Perhaps this is not a amandad problem but a problem of inetd. I think you may be on to something. I still get stuff like this ocassionally: cally:~$ zgrep inetd /var/log/messages.* /var/log/messages.2.gz:Dec 21 03:15:08 cally /kernel: pid 39434 (inetd), uid 0: exited on signal 11 /var/log/messages.2.gz:Dec 21 03:15:01 cally inetd[189]: /usr/local/libexec/amanda/amandad[38936]: exit status 0xb ... (actual order in my messages log despite the decreasing timestamp) I realize this is a different exit status than what you were seeing. Can you work around it by killing and restarting inetd? Telnetting to the amandidx port on the troubled client was for me a fast way to test whether the problem was temporarily resolved. I had a similar problem with crond on an 8mb under 3.1R through the earliest 3.3-STABLEs, with it either segving or yielding malloc() complaints. Just assumed there was still some vm bitrot introduced in 3.x. Lest that come out sounding too negative the kernel gurus have made tremendous progress in the later 3.3-STABLEs where the vm is far stabler under low RAM situations than it used to be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message