[Bug 213857] databases/influxdb: directory /var/run/influxdb not created at service start time (only at installation time)

[bugzilla-noreply at freebsd.org]

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

            Bug ID: 213857
           Summary: databases/influxdb: directory /var/run/influxdb not
                    created at service start time (only at installation
                    time)
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs at FreeBSD.org
          Reporter: Mark.Martinec at ijs.si
                CC: cheffo at freebsd-bg.org
             Flags: maintainer-feedback?(cheffo at freebsd-bg.org)
                CC: cheffo at freebsd-bg.org

Using influxdb-1.0.2 on 11.0-RELEASE

A directory /var/run/influxdb is assumed to exist at the influxd service
start time (to receive its pid file), yet the /usr/local/etc/rc.d/influxd
startup script does not insure existence of this directory.
Instead, it relies on the package installation to create it.

This results in an influxd service failing to start if /var/run
is cleaned at machine boot time, or if it resides on an ephemeral
file system (like tmpfs), which is re-created at boot time.

Reliance on the installation script to create a directory on /var/run
is unlike most other ports, which populate the /var/run with whatever
they need during service startup time.

Please update the 'databases/influxdb' port so that its
/usr/local/etc/rc.d/influxd script will create /var/run/influxdb
directory (if missing) at service startup time.



Background:
===========

https://lists.freebsd.org/pipermail/freebsd-ports/2016-August/104631.html

> Ephemeral /var/run and creating port-specific subdir at service startup time
>   Mark Martinec Mark.Martinec+freebsd at ijs.si 
>   Wed Aug 31 23:12:53 UTC 2016
>
> I prefer to have a /var/run file system reside on a tmpfs
> as its contents is small and ephemeral in its nature (like
> pid files, lock files, sockets), need not be preserved across
> reboots, and should not have to depend on any physical disk.
>
> The problem is that some programs/services/ports like to create
> their own subdirectory under /var/run. This works fine if such
> subdirectory is created (when missing) by their rc.d script,
> such as salt, dbus, jenkins, clamav-clamd, isc-dhcpd, kibana.
>
> Unfortunately there are other ports which create a subdirectory
> under /var/run at the installation time (pkg install). In this
> case their subdirectory is missing on a reboot when /var/run
> is re-created afresh, and they fail to start.
>
> So my question is: are such ports (like influxdb)
> which do not create their subdirectory at a startup time
> in error and a bug report is warranted, or am I wrong in
> expecting that /var/run may be ephemeral and is such a setup
> (as is common in Linux) unsupported?
>
>    Mark

https://lists.freebsd.org/pipermail/freebsd-ports/2016-August/104632.html
>   Roger Leigh rleigh at codelibre.net
>   Wed Aug 31 23:24:57 UTC 2016
>
> I can't speak for FreeBSD policies, but as the person who implemented 
> /run on Debian GNU/Linux for sysvinit (/var/run on tmpfs essentially), 
> we had to audit every package and ensure that all packages created the 
> directories they needed if they weren't present.  We retained the 
> cleaning of /var/run on boot to ensure a clean slate, so having it on 
> tmpfs was never mandatory, but if you did then it would just work. 
> However, we did have boot-time cleaning of /var/run for a while before 
> we introduced the tmpfs, so I can't recall doing anything but a handful 
> of minor tweaks.
>
> Doing the same for FreeBSD wouldn't be too hard if you can automatically 
> scan the ports tree or build package contents to identify and fix any 
> packages which are providing static files.
>
> Regards,
> Roger

-- 
You are receiving this mail because:
You are the assignee for the bug.