On Wednesday, 4. May 2005 23:42, Hubert Feyrer wrote:
> On Wed, 4 May 2005, Klaus Klein wrote:
> > I believe this would really make the matter more complicated than
> > it needs to be; if the daemon chroot is mounted nodev, then what
> > next?
> 
> No idea what next.
> 
> But I think if someone asks a daemon to run on a filesystem with 
> inapprorpiate mountflags, we can try and warn. Other operating systems to 
> that, too, see Solaris' /etc/init.d/sendmail for an example.

So the fstab examples make an inconsiderate recommendation the
startup script would error on/warn about if followed?

(I concede that having such a check would be a user-friendly
feature; however, it shouldn't examine /var (as suggested) but
the actual /dev instance of the chroot cage.  But this is
orthogonal to the change that kicked off the discussion.)

> > Also, a point gone missing here is thatm with the clock accuracy you
> > get from the typical COTS machine, you're very likely to end up
> > running ntpd, and in that case the suggested mount option will bite
> > you.
> 
> I don't know what you mean here.

If you really don't know at this point then it reflects that the
change was made without prior awareness of a typical setup, of the
workings of the rc.d chroot mechanism, and the consequences of that
change.  The paraphrasing below is consistent with that.

> I have the feeling this is evolving into a bikeshed discussion.
> ``oh my god, he dared documenting an option which may lead people into
>    problems, let's quick undo the documentation instead of fixing this
>    properly.''

You're not "documenting" the option; it's been very well
documented in mount(8) for more than a decade.  By putting
this into the examples set you're essentially making a
recommendation, and one that is likely to hurt users.  The
example rc.conf is another source of recommendations. They
weren't inconsistent until you made them so, and having a
warning printed if both are implemented  does not constitute
a proper fix.



- Klaus