bad state after failure / nonworking mail server

[Chris Rees]

On 2 November 2011 18:08, Ion-Mihai Tetcu <itetcu at freebsd.org> wrote:
> On Wed, 2 Nov 2011 17:48:34 +0000
> Chris Rees <utisoft at gmail.com> wrote:
>
>> On 2 November 2011 17:37, Ion-Mihai Tetcu <itetcu at freebsd.org> wrote:
>> > On Fri, 28 Oct 2011 22:39:08 +0100
>> > Chris Rees <utisoft at gmail.com> wrote:
>> >
>> >> On 28 October 2011 18:55, Ion-Mihai Tetcu <itetcu at freebsd.org>
>> >> wrote:
>> >> > On Fri, 28 Oct 2011 17:52:37 +0200
>> >> > John Marino <marcuscom at marino.st> wrote:
>> >> >
>> >> >> On 10/28/2011 5:44 PM, Ion-Mihai Tetcu wrote:
>> >> >> > On Fri, 28 Oct 2011 14:52:41 +0200
>> >> >> > John Marino <marcuscom at marino.st> wrote:
>> >> >> >
>> >> >> > If you're seeing this generally, then no, it doesn't happen
>> >> >> > with stock tindy.
>> >> >> >
>> >> >> > Are you using NFS or nullfs?
>> >> >> >
>> >> >>
>> >> >> nullfs.
>> >> >> DragonFly's default filesystem is HAMMER, and you can't use NFS
>> >> >> mounts directly on it (you need to null mount it somewhere else
>> >> >> first, so you might as well just use nullfs only).
>> >> >
>> >> > Depending if you actually store things locally or not ...
>> >> >
>> >> >> So I had to add a modification to detect HAMMER and use nullfs
>> >> >> unless NFS specifically requested.
>> >> >
>> >> > IMO nullfs should be the default anyway.
>> >> >
>> >> >>  Specifically requesting NFS mounts on hammer is a good way to
>> >> >> look up your system, or at least make that mount point unusable
>> >> >> until the next reboot...
>> >> >
>> >> > About the only time I saw tindy really stuck was on NFS; with a
>> >> > few exceptions, but those were actually ports getting stuck while
>> >> > building (port's fault, not tindy's).
>> >> > Tindy's "timeout" (after which it will just kill that build) is
>> >> > very high, IMO.
>> >> >
>> >>
>> >> Are you sure? Some ports (mentioning no names, libreoffice) are
>> >> real monsters... On a slow-ish machine, we wouldn't want pnohang
>> >> creating 'errors' when it's all going fine.
>> >
>> > Well, yeh, I know, on pointy the biggest "offender" was OOo.
>> > Perhaps this timeout interval should be turned into a config
>> > setting.
>> >
>>
>> I can see what you mean, but this is guaranteed to be a nice way to
>> get horribly confused about why a port is failing to build from a
>> developer's point of view; 'Why has this suddenly stopped working???
>> [hack hack and retry building for several hours] Oops, I changed the
>> timeout :('
>>
>> Or am I the only person idiotic enough to forget my config settings
>> like that? :)
>
> The benefits greatly outweigh the potential trouble, IMO, as build time
> for a given port on a given machine is pretty much constant. The
> current value is very conservative for today's hardware.
> And we also can add a pattern for this ....

Adding a pattern is a good idea. I withdraw my objection.

Chris