On 2016-06-19 10:08, Cy Schubert wrote: > In message <4e985ab9-0d98-a160-bdad-fa4924ddc...@freebsd.org>, Niclas > Zeising w > rites: >> On 2016-06-19 07:12, Cy Schubert wrote: >>> In message <CAJ-VmonLqPNaN_CMO+dwyiTw4ULSnridcREF6NGkLU5QohoMew@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
