Bug 227205 - Adapting the "${name}_limits" variable of various database service scripts to the recent changes in rc.subr (r328331)
Summary: Adapting the "${name}_limits" variable of various database service scripts to...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Mateusz Piotrowski
Depends on: 226907 227215 227216 227217 227218 227219 227221 227223 227224 227225 227226 227227 227228 227229 227230 227231 227232 227233 227234 227235 227236 227434 227435
  Show dependency treegraph
Reported: 2018-04-02 15:51 UTC by Mateusz Piotrowski
Modified: 2018-11-03 22:04 UTC (History)
11 users (show)

See Also:

Patch adding an entry to UPDATING (1.50 KB, patch)
2018-04-02 21:27 UTC, Mateusz Piotrowski
no flags Details | Diff
An entry to UPDATING about the new ${name}_limits behavior on 12-CURRENT (revision: 2) (1.29 KB, text/plain)
2018-04-11 12:54 UTC, Mateusz Piotrowski
no flags Details
An entry to UPDATING about the new ${name}_limits behavior on 12-CURRENT (revision: 3) (1.30 KB, text/plain)
2018-04-11 17:30 UTC, Mateusz Piotrowski
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mateusz Piotrowski freebsd_committer 2018-04-02 15:51:18 UTC
Due to the changes in rc.subr introduced by r328331[1] some of the
database services are unable to start (service ${name} start) on FreeBSD 12-CURRENT. Here's an example for databases/mongodb36:

> Starting mongod.
> limits: NO: No such file or directory
> /usr/local/etc/rc.d/mongod: WARNING: failed to start mongod

Before r328331 some database services defined a bool variable
`${name}_limits`. When it was set to YES it triggered limits(1) to run
before a daemon was started.

Revision 328331 introduced a standard mechanism to do it. As a result
daemon maintainers/developers no longer have to roll out their own
solutions. The problem is that the semantics of the new common
mechanism is not compatible with many service files. `${name}_limits`
used to be a bool variable whereas now it is a string of extra flags to
be passed to limits(1).

The following command reveals a list of potentially affected ports:

    $ cd /usr/ports
    $ find . -mindepth 4 -maxdepth 4 -type f ! -name '*patch*' \
    -exec grep -l _limits {} \+ | \
    awk -v FS=/ -v OFS=/ '{print $2,$3}' - | sort | uniq


I confirm that the problem exists in all those ports.

Initially, I thought that this bug is related only to the
databases/mongodb36 port but it turned out that it is a bigger issue.
The issue on Bugzilla for monogodb36 is here[2].

FWIW, I've submitted an update to the rc.subr manual to improve the
documentation of that new ${name}_limits variable.[3]

This is a meta-issue of this problem. I'll open issues for all the affected ports to notify maintainers and request individual feedback.

We need to remember that we cannot simply switch to the new mechanism as it is only available in 12-CURRENT and soon in 11-STABLE (and 11.2). 

[1]: https://svnweb.freebsd.org/base?view=revision&revision=r328331
[2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226907
[3]: https://reviews.freebsd.org/D14928
Comment 1 Mateusz Piotrowski freebsd_committer 2018-04-02 21:27:48 UTC
Created attachment 192120 [details]
Patch adding an entry to UPDATING

I'm submitting the first version of an entry for the UPDATING file so that it could be reviewed and improved before all the service file patches are ready.
Comment 2 Mateusz Piotrowski freebsd_committer 2018-04-09 15:57:01 UTC
Please do not merge those patches just yet. Although the patches are fine if one's building from source it is not a good solution for prebuilt packages installable via pkg. FreeBSD machines building packages for pkg are going to run 11.1 for at least 2 months, which results in the legacy _limits behavior in rc scripts. As a result packages installed via pkg will always try to use the legacy behavior even if you're running a system with the new _limits behavior (11-STABLE, 12-CURRENT and soon 11.2).

The solution is to detect which _limits behavior to use during runtime. We are working on this together with kevans@.
Comment 3 Mahdi Mokhtari freebsd_committer freebsd_triage 2018-04-09 16:24:04 UTC
(In reply to Mateusz Piotrowski from comment #2)
Hey, I had a fix before merging this on https://svnweb.freebsd.org/ports?view=revision&revision=461217 for mysql56-server...
Can it help in the case?
[Let me know if it's fine I'd revert the current patch on mysql that I already merged `:D, ppl reported issue on 11-Stable]
Comment 4 Mateusz Piotrowski freebsd_committer 2018-04-10 23:54:24 UTC
(In reply to Mahdi Mokhtari from comment #3)

We discussed it with kevans@ and concluded that we should aim for a more maintainable solution than hacking those poor rc scripts :) . The current state of affairs is as follows:

 * The change introducing the new behavior was reverted from 11-STABLE. 
 * A patch is still required to adapt those database ports to the new behavior, which is present on 12-CURRENT. The new patches will be uploaded in a matter of minutes.
Comment 5 Mateusz Piotrowski freebsd_committer 2018-04-11 12:54:51 UTC
Created attachment 192435 [details]
An entry to UPDATING about the new ${name}_limits behavior on 12-CURRENT (revision: 2)

Update the entry:
 * Update the list of affected FreeBSD versions.
 * Improve the description of the problem.
Comment 6 Mateusz Piotrowski freebsd_committer 2018-04-11 17:30:14 UTC
Created attachment 192437 [details]
An entry to UPDATING about the new ${name}_limits behavior on 12-CURRENT (revision: 3)

Minor changes to the previous patch as discussed with kevans@:
 * This issue affects 12-CURRENT only. This is why the information about affected FreeBSD versions was moved to the top of the UPDATING entry.