Date: Fri, 28 Oct 2016 15:39:14 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 213857] databases/influxdb: directory /var/run/influxdb not created at service start time (only at installation time) Message-ID: <bug-213857-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213857 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@FreeBSD.org Reporter: Mark.Martinec@ijs.si CC: cheffo@freebsd-bg.org Flags: maintainer-feedback?(cheffo@freebsd-bg.org) CC: cheffo@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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D https://lists.freebsd.org/pipermail/freebsd-ports/2016-August/104631.html > Ephemeral /var/run and creating port-specific subdir at service startup t= ime > Mark Martinec Mark.Martinec+freebsd at ijs.si=20 > 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=20 > /run on Debian GNU/Linux for sysvinit (/var/run on tmpfs essentially),=20 > we had to audit every package and ensure that all packages created the=20 > directories they needed if they weren't present. We retained the=20 > cleaning of /var/run on boot to ensure a clean slate, so having it on=20 > tmpfs was never mandatory, but if you did then it would just work.=20 > However, we did have boot-time cleaning of /var/run for a while before=20 > we introduced the tmpfs, so I can't recall doing anything but a handful=20 > of minor tweaks. > > Doing the same for FreeBSD wouldn't be too hard if you can automatically= =20 > scan the ports tree or build package contents to identify and fix any=20 > packages which are providing static files. > > Regards, > Roger --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-213857-13>