Summary: | rc.subr: limits(1) is unavailable before /usr is mounted | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Jean-Sébastien Pédron <dumbbell> | ||||||
Component: | conf | Assignee: | Adrian Chadd <adrian> | ||||||
Status: | Closed FIXED | ||||||||
Severity: | Affects Only Me | CC: | citrin+pr, cy, gonzo, kevans, rgrimes | ||||||
Priority: | --- | Keywords: | patch | ||||||
Version: | CURRENT | ||||||||
Hardware: | Any | ||||||||
OS: | Any | ||||||||
Attachments: |
|
Description
Jean-Sébastien Pédron
2016-01-15 14:21:01 UTC
Over to committer of 288291. eep, uhm, not sure what to do here. Hm. Suggestions? (Could attempt to only run limits if it's found..) Yes, I thought about that too. I don't know what other parts of rc do about this. (In reply to Adrian Chadd from comment #3) That's what my first patch did. The problem is, as you stated, that makes differing system behaviour depending on whether /usr is found or not. The other option, which I prefer over my first suggestion in the email thread, is to use $start_cmd in rc.d scripts that execute prior to mountcritlocal, which is assigned at line 999 in rc.subr and executed at line 1005. The limits command is only executed if $start_cmd is not specified and the defaults are used. Essentially, This is differing system behaviour depending on whether $start_cmd is specified in the rc.d script or not. Scanning through the rc.d scripts that execute prior to FILESYSTEMS, only ddb and var do not specify $start_cmd. The var script executes directly, it's not executed by rc.subr. The ddb script doesn't specify start_cmd and is the only script affected by this. If ddb did specify $start_cmd, it would avoid the code in rc.subr that attempts and fails to execute limits(1). I think adding $start_cmd to either run a function in /etc/rc.d/ddb or run /sbin/ddb directly would circumvent this ticket. Just a thought. Going the function route is probably simpler. I'll upload my two patches for the record and may the best one, or some other patch, be used. Created attachment 171592 [details]
Possible rc.subr patch to only add limit to command string if it can be executed.
Created attachment 171593 [details]
Possible rc.d/ddb patch to circumvent default start behaviour in rc.subr.
This is preferred over the rc.subr approach. Both could be used, with the rc.subr patch used as a relief valve.
Ping. Can either of these patches be committed This bug needs triage back onto a public list, as it stands it is hidden from nag reports. I would add it, but I am not sure which list would be appropriate. A commit references this bug: Author: kevans Date: Thu Apr 19 15:02:54 UTC 2018 New revision: 332773 URL: https://svnweb.freebsd.org/changeset/base/332773 Log: Fix ddb rc script r288291 added a call to limits(1), which isn't available before partitions are mounted. This broke the ddb rc script, which does not provide its own start_cmd. Alleviate the situation here by providing a start_cmd. We still have other problems with diskless setups that need to be considered, but this is a start. PR: 206291 Submitted by: cy Discussed with: rgrimes MFC after: 3 days Changes: head/etc/rc.d/ddb A commit references this bug: Author: kevans Date: Sun Apr 22 00:26:35 UTC 2018 New revision: 332864 URL: https://svnweb.freebsd.org/changeset/base/332864 Log: MFC r332773: Fix ddb rc script r288291 added a call to limits(1), which isn't available before partitions are mounted. This broke the ddb rc script, which does not provide its own start_cmd. Alleviate the situation here by providing a start_cmd. We still have other problems with diskless setups that need to be considered, but this is a start. PR: 206291 Changes: _U stable/11/ stable/11/etc/rc.d/ddb There is a commit referencing this PR, but it's still not closed and has been inactive for some time. Closing the PR as fixed but feel free to re-open it if the issue hasn't been completely resolved. Thanks |