Bug 213857 - databases/influxdb: directory /var/run/influxdb not created at service start time (only at installation time)
Summary: databases/influxdb: directory /var/run/influxdb not created at service start ...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Palle Girgensohn
URL:
Keywords: needs-patch
Depends on:
Blocks:
 
Reported: 2016-10-28 15:39 UTC by Mark.Martinec
Modified: 2016-12-05 14:14 UTC (History)
3 users (show)

See Also:
cheffo: maintainer-feedback+
koobs: merge-quarterly?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark.Martinec 2016-10-28 15:39:14 UTC
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
Comment 1 cheffo 2016-12-01 11:28:27 UTC
Do you know any other port in FreeBSD ports three that do this? 
I do not know if there are any security issues by implementing this manually in the rc.d script, but for sure I do not want to be the first one implementing this in the ports tree.
Comment 2 Matthew Seaman freebsd_committer 2016-12-01 12:18:12 UTC
There certainly is prior art for creating certain directories under /var from an RC-script. See textproc/sphinxsearch for instance.
Comment 3 Mark.Martinec 2016-12-01 13:24:24 UTC
The following search seems to reveal plenty of examples:

  find /usr/ports -name '*.in' -exec egrep -H 'install.*-d.*/var/run' {} \;
Comment 4 Palle Girgensohn freebsd_committer 2016-12-04 22:07:37 UTC
Since the daemon has its own directory under /var/run/influxdb, there is no need to touch the pidfile. It is a trick to set ownership when it is diectly under /var/run.

Some thing like this is cool. Ok to commit?

Index: files/influxd.in
===================================================================
--- files/influxd.in	(revision 427748)
+++ files/influxd.in	(working copy)
@@ -41,7 +41,7 @@
 
 influxd_precmd()
 {
-    install -o ${influxd_user} /dev/null ${influxd_pidfile}
+    install -d -o ${influxd_user}  %%INFLUXD_PIDDIR%%
 }
 
 run_rc_command "$1"
Comment 5 cheffo 2016-12-05 12:29:07 UTC
I'm OK to commit.

Can you please also add:

 do-build:
-       @cd ${WRKSRC}/src/github.com/influxdata/${PORTNAME} && ${SETENV} GOPATH=${WRKSRC} go install ./...
+       @cd ${WRKSRC}/src/github.com/influxdata/${PORTNAME} && ${SETENV} GOPATH=${WRKSRC} go install -ldflags "-X main.version=${DISTVERSION}" ./...

This will make influxdb to report its "distversion" instead of unknown - this btw should work for telegraf and kapacitor also.
Comment 6 commit-hook freebsd_committer 2016-12-05 14:13:48 UTC
A commit references this bug:

Author: girgen
Date: Mon Dec  5 14:13:07 UTC 2016
New revision: 427896
URL: https://svnweb.freebsd.org/changeset/ports/427896

Log:
  Update to latest version.

  PR:	213857

Changes:
  head/databases/influxdb/Makefile
  head/databases/influxdb/distinfo
  head/databases/influxdb/files/influxd.in
Comment 7 Palle Girgensohn freebsd_committer 2016-12-05 14:14:34 UTC
Committed. Thanks!