mgetty in ttys hoses system

2003-03-02 Thread Christoph Kukulies

I installed the /usr/ports/comms/mgetty+sendfax to get my
new servers functions completed and found after installing the
port and giving a kill -HUP 1 - the port adds the
line 
cuaa0 /usr/local/sbin/mgetty unknown on insecure
to /etc/ttys.

After that the system was hosed. After rebooting
the system seemed to got hung in multi user mode.
No vtys and I booted into single user.

Found that /etc/ttys contained passwd entries instead, totally
hosed. It never happended to me that I got FS corruption
like this before.

I took out the mgetty entry and live without fax at the moment
but hope to find a solution soon.

Just install the mgetty+sendfax port in a -current system
answer all the questions in the setup dialog with defaults
and kill -HUP 1 and you'll be left with a hosed system.


--
Chris Christoph P. U. Kukulies [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: mgetty in ttys hoses system

2003-03-02 Thread Terry Lambert
Christoph Kukulies wrote:
 I installed the /usr/ports/comms/mgetty+sendfax to get my
 new servers functions completed and found after installing the
 port and giving a kill -HUP 1 - the port adds the
 line
 cuaa0 /usr/local/sbin/mgetty unknown on insecure
 to /etc/ttys.
 
 After that the system was hosed. After rebooting
 the system seemed to got hung in multi user mode.
 No vtys and I booted into single user.
 
 Found that /etc/ttys contained passwd entries instead, totally
 hosed. It never happended to me that I got FS corruption
 like this before.


This is a well-known FreeBSD VM bug, having to do with writes
to COW pages for objects mapped read-only.

It happens when you modify the contents of the data areas returned
by getpwent().

We had the same problem with Vixie cron on the InterJet; it would
spam the crontab with a page of data from the passwd database.

No one ever fixed it, because no one after Dyson has really bothered
to fully understand the VM system, before making changes to it.

You can work around it by modifying the program to copy the pwent
contents (or use it's own pwent structure) instead of modifying the
returned data areas.  This avoids triggering the COW, where the
dirty buffer gets attached to the wrong vnode.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message