Bug 255676 - www/grafana7 fails to start for a second time
Summary: www/grafana7 fails to start for a second time
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Bartek Rutkowski
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-07 07:15 UTC by Simeon Simeonov
Modified: 2021-05-18 08:03 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (robak)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simeon Simeonov 2021-05-07 07:15:20 UTC
After installing grafana from the ports collection (make install clean), starting it with the default grafana.conf, changing the admin password, it fails to start again. syslog gives me the following message:

May  7 09:04:56 SagaBOX grafana[7879]: panic: error getting work directory: stat .: permission denied
May  7 09:04:56 SagaBOX grafana[7879]: 
May  7 09:04:56 SagaBOX grafana[7879]: goroutine 1 [running]:
May  7 09:04:56 SagaBOX grafana[7879]: gopkg.in/macaron%2ev1.init.1()
May  7 09:04:56 SagaBOX grafana[7879]: 	/usr/ports/www/grafana7/work/grafana-7.5.1/vendor/gopkg.in/macaron.v1/macaron.go:317 +0x110
Comment 1 Simeon Simeonov 2021-05-07 08:01:48 UTC
Installing grafana7 from the package repo (pkg install grafana7) doesn't seem to make any difference.
Comment 2 Simeon Simeonov 2021-05-09 11:24:46 UTC
The problem didn't seem to exist when booting the system. Only when issuing (one)start.

Removing: /usr/bin/env ${grafana_env} from command_args in /usr/local/etc/rc.d/grafana seems to fix the problem for me.
Comment 3 Zach Leslie freebsd_committer 2021-05-12 18:19:11 UTC
I am seeing this also.  If the `daemon` command is executed outside of `/root`, everything seems to run correctly.  Perhaps a code release in grafana upstream has started trying to read the local directory.  I've built up a new jail to confirm this is an issue outside of the first instance that I observed this.  I've messaged the maintainer on the subject as well, but have not heard back yet.
Comment 4 Simeon Simeonov 2021-05-18 08:03:58 UTC
Great observation.
The daemon fails when executed within /root for me as well,
but if I set f.i. chmod 755 /root ... the daemon executes from /root (cwd).