Bug 255593 - sysutils/fluent-bit: doesn't start
Summary: sysutils/fluent-bit: doesn't start
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Palle Girgensohn
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-04 13:02 UTC by Christopher Beppler
Modified: 2021-09-02 23:35 UTC (History)
3 users (show)

See Also:


Attachments
updated fluent_bit rc file (1.16 KB, application/x-shellscript)
2021-05-04 13:02 UTC, Christopher Beppler
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Beppler 2021-05-04 13:02:32 UTC
Created attachment 224660 [details]
updated fluent_bit rc file

I have the issue that fluent-bit doesn't start anymore when using the sample config. It might be related to an upstream change, though.

However, if I change /usr/local/etc/rc.d/fluent_bit to the attached file it works.

Hope that helps,
Christopher
Comment 1 bgdnlp 2021-07-16 06:31:19 UTC
I'll add some detail here, not sure if it's the same issue but seems to be.

Fluent-bit 1.7.9, installed from packages, doesn't start in daemon mode. Simple way to reproduce:

```
# fluent-bit -d -s 40000 -i random -o stdout
Fluent Bit v1.7.9
* Copyright (C) 2019-2021 The Fluent Bit Authors
* Copyright (C) 2015-2018 Treasure Data
* Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
* https://fluentbit.io

[2021/07/16 06:28:08] [ info] switching to background mode (PID=59754)
```

Checking if the process exists will show that it doesn't. Truss produces this (shortened) output:

```
# truss fluent-bit -d -s 40000 -i random -o stdout
(...)
write(2,"* Fluent Bit is a CNCF sub-proje"...,65) = 65 (0x41)
* https://fluentbit.io

write(2,"* https://fluentbit.io\n\n",24)         = 24 (0x18)
sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
fork()                                          [2021/07/16 06:27:47] [ info] switching to background mode (PID=59732)
 = 59732 (0xe954)
sigprocmask(SIG_SETMASK,{ },0x0)                 = 0 (0x0)
exit(0x0)
process exit, rval = 0
```

I'm guessing this should be reported upstream?
Comment 2 Christopher Beppler 2021-08-26 08:41:26 UTC
I just updated to 1.8.3 of fluent-bit and it did overwrite my rc.d script resulting in fluent-bit not starting.

Am I the only one that experiences issues with fluent-bit when using the default configuration? If not, I'd like to bump this issue once more.

Thanks
Comment 3 commit-hook freebsd_committer freebsd_triage 2021-09-02 22:38:06 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=2b5d5148c0f32f81380555f1ade6269cd04ce716

commit 2b5d5148c0f32f81380555f1ade6269cd04ce716
Author:     Palle Girgensohn <girgen@FreeBSD.org>
AuthorDate: 2021-09-02 22:27:32 +0000
Commit:     Palle Girgensohn <girgen@FreeBSD.org>
CommitDate: 2021-09-02 22:37:18 +0000

    sysutils/fluent-bit: fix problems running the fluent-bit

    There is a known problem with the default coro_stack_size being too
    small. Double it to avoid failing to start. [1]

    Since the daemon option seems to be somewhat funky [2], use daemon to
    wrap the fluent-bit binary when running from the rc.d script.

    [1] https://github.com/fluent/fluent-bit/issues/3716
    PR:     255593 [2]

 sysutils/fluent-bit/Makefile                         |  1 +
 sysutils/fluent-bit/files/fluent-bit.in              | 20 +++++++++++++++++---
 .../files/patch-conf__fluent-bit.conf (new)          | 20 ++++++++++++++++++++
 .../patch-include__fluent-bit__flb_coro.h (new)      | 11 +++++++++++
 4 files changed, 49 insertions(+), 3 deletions(-)
Comment 4 Palle Girgensohn freebsd_committer freebsd_triage 2021-09-02 23:35:41 UTC
I'm not sure it doesn't start in daemon mode.
It seems to depend on the last option for daemon that is added, so if we d

--daemon --config-file ...


and the config file has Daemon Off, there will be no daemon mode. A simple fix would have been

--config-file ... --daemon

but since there was also an issue that the log is sent to stdout, I chose to use the daemon(8) as suggeted in this PR, with some minor mods.

Thanks! Committed!