svn commit: r288291 - head/etc

[Allan Jude]

On 2016-06-19 10:08, Cy Schubert wrote:
> In message <4e985ab9-0d98-a160-bdad-fa4924ddc5b3 at freebsd.org>, Niclas 
> Zeising w
> rites:
>> On 2016-06-19 07:12, Cy Schubert wrote:
>>> In message <CAJ-VmonLqPNaN_CMO+dwyiTw4ULSnridcREF6NGkLU5QohoMew at mail.gmail.
>> c
>>> om>
>>> , Adrian Chadd writes:
>>>> i think that's fine for -11. I'd like to just move limits to /bin for
>>>> 12. (I mean, it's 2016, why are you splitting / and /usr again? But..)
>>>>
>>>> I don't want to see differing system behaviour between limits but it's
>>>> likely unavoidable for 11 and could do with some errata notice so
>>>> people know what to expect.
>>>
>>> There aren't any daemons started prior to critical local filesystems being 
>>> mounted. I suppose one day there could be but none at this point in time. 
>>> Setting limits before filesystems are mounted is practically a NOP anyway. 
>>> (Except it could negatively affect fsck of huge UFS filesystems some day.)
>>>
>>>
>>
>> This is wrong, and how I discovered it.  ddb (/etc/rc.d/ddb) starts
>> before disks, and currently refuses to start on my systems with this
>> issue.  This means no crash dumps, unless I remember to manually start
>> it later in the boot process, so this is an issue.
> 
> ddb isn't a daemon. It's an interface into the kernel that configures DDB 
> properties. It runs and completes. And, yes, it is affected by limits not 
> being found in the path.
> 
> My point is, since there are no daemons, as per the definition of a daemon 
> (processes that become daemons and run in the background) prior to the 
> filesystems being run, to say that there would be differing systems 
> behavior before and after filesystems are started is presently false 
> (though technically true because one day we might have daemons started 
> before critical filesystems are mounted).
> 
> I can see Adrian's point but not in the present day. In the future, 
> possibly.
> 
> Another option might be to move ddb after filesytems are mounted or this 
> should circumvent the problem too:
> 

I think you still want ddb early, because it configures crash dumps, and
another daemon or process that starts might cause a crash.

-- 
Allan Jude