From winfried@spitfire.303.krakow.pl  Fri Jun 28 18:44:24 2002
Return-Path: <winfried@spitfire.303.krakow.pl>
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BCB7937B405
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 28 Jun 2002 18:44:24 -0700 (PDT)
Received: from spitfire.303.krakow.pl (spitfire.303.krakow.pl [62.233.208.97])
	by mx1.FreeBSD.org (Postfix) with SMTP id 7541243E06
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 28 Jun 2002 18:44:23 -0700 (PDT)
	(envelope-from winfried@spitfire.303.krakow.pl)
Received: (qmail 73790 invoked by uid 1001); 29 Jun 2002 01:44:16 -0000
Message-Id: <20020629014416.73606.qmail@spitfire.303.krakow.pl>
Date: 29 Jun 2002 01:44:16 -0000
From: Jan Srzednicki <winfried@303.krakow.pl>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: vi recovery halting boot process
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         39976
>Category:       conf
>Synopsis:       vi recovery halting boot process
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jun 28 18:50:02 PDT 2002
>Closed-Date:    Sat Mar 05 13:40:04 EST 2011
>Last-Modified:  Sat Mar 05 13:40:04 EST 2011
>Originator:     Jan Srzednicki
>Release:        FreeBSD 4.6-RC i386
>Organization:
Dywizjonet
>Environment:
System: FreeBSD spitfire.303.krakow.pl 4.6-RC FreeBSD 4.6-RC #5: Tue May 21 23:07:20 CEST 2002 root@spitfire.303.krakow.pl:/usr/obj/usr/src/sys/GRABKI i386


	
>Description:

In some cirtumstances, the "vi recovery" thing started at boot time
fails to work and the system just freezes on that point. Hitting Ctrl-C
usually helps, but not always; it's quite irritating, especially when one
does not use vi at all.
I thing a solution would be putting some new option into rc.conf (like
vi_recovery_enable="YES/NO"), which would control starting or not
the vi recovery thing.
	
>How-To-Repeat:

I'm not sure why it happens; none of my servers seem to be affected,
but my workstation is.
	
>Fix:

As stated above.
	


>Release-Note:
>Audit-Trail:

From: Peter Pentchev <roam@ringlet.net>
To: Jan Srzednicki <winfried@303.krakow.pl>
Cc: bug-followup@FreeBSD.org
Subject: Re: conf/39976: vi recovery halting boot process
Date: Mon, 1 Jul 2002 14:27:57 +0300

 The 'vi recovery' code in the startup scripts searches for files in the
 /var/tmp/vi.recovery/ directory named recover.*; if any such files are
 found, it attempts to e-mail the user whose editing session crashed.
 The fact that the recovery code is attempting to do something would seem
 to imply that the startup scripts have found such recover.* files, which
 would mean that maybe somebody *was* actually using vi(1) or something
 else that generated that kind of files :)
 
 Thus, the most probable reason for the 'vi recovery' taking a long time
 would be some misconfiguration of that machine's mail server/client.
 The startup scripts attempt to send mail using the 'sendmail' command,
 so a properly set up /etc/mail/mailer.conf file in addition to a mail
 server or a null-mailer running on that machine, should work fine.
 
 > I thing a solution would be putting some new option into rc.conf (like
 > vi_recovery_enable="YES/NO"), which would control starting or not
 > the vi recovery thing.
 
 If you are really, really sure that no one would be using vi, and that
 no notification of crashed sessions is necessary, you could add a simple
 shell script in /usr/local/etc/rc.d/, named, say, remove-recover.sh,
 which would execute a 'rm -rf /var/tmp/vi.recovery/recover.*' command :)
 
 > I'm not sure why it happens; none of my servers seem to be affected,
 > but my workstation is.
 
 Configure your workstation's mail server, maybe to a simple mail relay
 (null-mailer)?
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net	roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 This sentence claims to be an Epimenides paradox, but it is lying.
State-Changed-From-To: open->closed 
State-Changed-By: eadler 
State-Changed-When: Sat Mar 5 13:40:03 EST 2011 
State-Changed-Why:  
look at virecover_enable=YES 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39976 
>Unformatted:
