[Bug 227205] Adapting the "${name}_limits" variable of various database service scripts to the recent changes in rc.subr (r328331)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205

            Bug ID: 227205
           Summary: Adapting the "${name}_limits" variable of various
                    database service scripts to the recent changes in
                    rc.subr (r328331)
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs at FreeBSD.org
          Reporter: 0mp at FreeBSD.org
                CC: ale at FreeBSD.org, brendan+freebsd at bbqsrc.net,
                    brnrd at freebsd.org, dev at dudu.ro, eric at camachat.org,
                    feld at FreeBSD.org, flo at FreeBSD.org, mmokhi at freebsd.org,
                    numisemis at yahoo.com, proler at gmail.com
        Depends on: 226907
                CC: ale at FreeBSD.org, brendan+freebsd at bbqsrc.net,
                    brnrd at freebsd.org, dev at dudu.ro, eric at camachat.org,
                    feld at FreeBSD.org, flo at FreeBSD.org, mmokhi at freebsd.org,
                    numisemis at yahoo.com, proler at gmail.com

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

    databases/arangodb32
    databases/arangodb33
    databases/clickhouse
    databases/mariadb100-server
    databases/mariadb101-server
    databases/mariadb102-server
    databases/mariadb55-server
    databases/mongodb
    databases/mongodb32
    databases/mongodb34
    databases/mongodb34-rocks
    databases/mongodb36
    databases/mysql55-server
    databases/mysql56-server
    databases/mysql57-server
    databases/mysql80-server
    databases/mysqlwsrep56-server
    databases/mysqlwsrep57-server
    databases/percona55-server
    databases/percona56-server
    databases/percona57-server

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


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226907
[Bug 226907] databases/mongodb36:  failed to start mongod due to "limits: NO:
No such file or directory"
-- 
You are receiving this mail because:
You are the assignee for the bug.