We sometimes want customers to be able to restart services (like ldap) running on non-standard and non-privileged ports. With the new unconditional call to "limits" in the rc.subr start function, this fails: $ sh /usr/local/etc/rc.d/slapd start Starting slapd. limits: setrlimit datasize: Operation not permitted I suggest a change like the following: --- /etc/rc.subr.orig 2019-01-22 10:40:13.973245000 +0100 +++ /etc/rc.subr 2019-01-22 09:51:18.058288000 +0100 @@ -1073,7 +1073,9 @@ fi # Prepend default limits - _doit="$_cd limits -C $_login_class $_doit" + if [ `/usr/bin/id -u` -eq 0 ]; then + _doit="$_cd limits -C $_login_class $_doit" + fi # run the full command # and the same service can now be maintained by a non privileged user: $ sh /usr/local/etc/rc.d/slapd start Starting slapd. Kind regards, Markus
Thank you for the report and patch Markus. Could you please include your patch as an attachment?
Created attachment 201326 [details] patch to allow non-root bypass of call to limits Here's the patch as attachment.
This change comes with the caveat that services started by non-privileged users will silently have different, non-default limits which may impact the function of the service.
(In reply to Conrad Meyer from comment #3) services started by non privileged users will inherit the limits of those users, which at least in my understanding is working as intended. An alternative approach would be to have a generic _limit_enable variable per service, in the same spirit as services such as apache used to have before there was central support for service limits. My approach was the one with the least amount of needed changes and potential impact to existing setups (considering that there was no central limits support previously).
I think that I've accidentally discovered a hack/workaround: $ limits -C default echo ok limits: setrlimit datasize: Operation not permitted $ limits -C nonexistent echo ok login class 'nonexistent' non-existent, using default limits: setrlimit datasize: Operation not permitted $ limits -C me echo ok login class 'me' non-existent, using current settings ok It turns out that setting the login class to "me" causes limits(1) to only print a warning, instead of failing. I am not sure why it is so. Please note that I do in fact have a "me" entry in my ~/.login_conf.
Another workaround that works on recent 14.0-CURRENT is to redefine limits(1) in the service script as follows: limits() { shift 2 "$@" }
I'm trying to land a patch to address this issue: https://reviews.freebsd.org/D33381