[GH-ISSUE #1677] Make firejail print to stderr by default (instead of stdout)

gitea-mirror commented

2026-05-05 07:30:50 -06:00

Owner

Originally created by @vn971 on GitHub (Dec 13, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1677

Steps to reproduce:

firejail --noprofile true 1>stdout 2>stderr

Expected: file "stdout" is empty, file "stderr" contains firejail information (Parent pid 4688, child pid 4689 etc)

Actually: file "stdout" contains the info, "stderr" is empty.

Printing additional non-necessary information to stderr by default is a common nice thing in many Linux programs, I suggest to embrace it.
Thoughts?

Originally created by @vn971 on GitHub (Dec 13, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1677 Steps to reproduce: * `firejail --noprofile true 1>stdout 2>stderr` Expected: file "stdout" is empty, file "stderr" contains firejail information (`Parent pid 4688, child pid 4689` etc) Actually: file "stdout" contains the info, "stderr" is empty. Printing additional non-necessary information to stderr by default is a common nice thing in many Linux programs, I suggest to embrace it. Thoughts?

gitea-mirror

2026-05-05 07:30:50 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 07:30:55 -06:00

Author

Owner

@Hocuri commented on GitHub (Dec 13, 2017):

Do you want to separate Firejail's information (Parent pid 4688, child pid 4689 etc) from the sandboxed process' stdout? Maybe there could be an option to toggle this extra information off and just print errors and warnings to stderr.
The disadvantage of stderr is: As far as I know it is assumed that the message is urgent and it is printed without buffering, although I do not know how bad this is on modern computers.

@Hocuri commented on GitHub (Dec 13, 2017): Do you want to separate Firejail's information (Parent pid 4688, child pid 4689 etc) from the sandboxed process' stdout? Maybe there could be an option to toggle this extra information off and just print errors and warnings to stderr. The disadvantage of stderr is: As far as I know it is assumed that the message is urgent and it is printed without buffering, although I do not know how bad this is on modern computers.

gitea-mirror commented

2026-05-05 07:30:56 -06:00

Author

Owner

@vn971 commented on GitHub (Dec 13, 2017):

@Hocceruser what would be the problem to print 2 lines without buffering?

Currently, firejail has the --quiet option, which will remove such info. (Example use case for --quiet is when firejail-ed program output is fed to another tool.) Writing to stderr would fix most usages of --quiet as a bonus.

@vn971 commented on GitHub (Dec 13, 2017): @Hocceruser what would be the problem to print 2 lines without buffering? Currently, firejail has the `--quiet` option, which will remove such info. (Example use case for `--quiet` is when firejail-ed program output is fed to another tool.) Writing to stderr would fix most usages of `--quiet` as a bonus.

gitea-mirror commented

2026-05-05 07:30:58 -06:00

Author

Owner

@Hocuri commented on GitHub (Dec 14, 2017):

Currently, firejail has the --quiet option

Ah yes, I did not see this, sorry.

When I run firejai firefox it is about 10 lines output (6 Reading profile... lines plus 4 lines of other info) but I still do not know if this is a problem.

Would there be any advantage of stderr over stdout apart from not having to write --quiet?

@Hocuri commented on GitHub (Dec 14, 2017): > Currently, firejail has the `--quiet` option Ah yes, I did not see this, sorry. When I run firejai firefox it is about 10 lines output (6 `Reading profile`... lines plus 4 lines of other info) but I still do not know if this is a problem. Would there be any advantage of stderr over stdout apart from not having to write `--quiet`?

gitea-mirror commented

2026-05-05 07:31:00 -06:00

Author

Owner

@vn971 commented on GitHub (Dec 14, 2017):

@Hocceruser yes, as I wrote in the issue description.. It's the standard approach to logging/printing on Linux. It allows firejail-ed program output to be used by other tools, while still not discarging the information.
Just see how all other programs print their "logs" as well as their "primary output".

@vn971 commented on GitHub (Dec 14, 2017): @Hocceruser yes, as I wrote in the issue description.. It's the standard approach to logging/printing on Linux. It allows firejail-ed program output to be used by other tools, while still not discarging the information. Just see how all other programs print their "logs" as well as their "primary output".

gitea-mirror commented

2026-05-05 07:31:02 -06:00

Author

Owner

@reinerh commented on GitHub (Dec 14, 2017):

Isn't stderr supposed to be used for errors? And stdout for normal informational output?

@reinerh commented on GitHub (Dec 14, 2017): Isn't stderr supposed to be used for errors? And stdout for normal informational output?

gitea-mirror commented

2026-05-05 07:31:03 -06:00

Author

Owner

@Ferroin commented on GitHub (Dec 14, 2017):

@reinerh It really depends on what you are talking about. If you're designing a program that's supposed to only be used interactively and will never be involved in a shell pipeline, then yes that's the standard practice. The moment you start talking about non-interactive or pipeline usage though, the standard becomes printing everything except actual program output on stderr (note that in this case, logged messages are not actual program output), and once you're talking about a wrapper program like firejail (or more concretely looking at existing examples, like parallel, socksify, datefudge, fakeroot, and similar), everything that isn't from the wrapped program has to go to stderr so that you don't interfere with the output of the wrapped program.

@Hocceruser I'm pretty sure there's no such 'rule' about having no buffering on stderr (at least, if there is, it's not part of the ANSI C standard, and I'm pretty sure it's not part of C89 or C99 either). The only practical difference lies in handling of redirection in the shell (you can more easily redirect stdout than stderr, and stdout is what gets captured to be sent to the next stage in a pipeline). The whole original point was to segregate output being sent to another program with informational output, but back then informational output only meant errors, thus the usage of the name 'stderr'.

@Ferroin commented on GitHub (Dec 14, 2017): @reinerh It really depends on what you are talking about. If you're designing a program that's supposed to only be used interactively and will never be involved in a shell pipeline, then yes that's the standard practice. The moment you start talking about non-interactive or pipeline usage though, the standard becomes printing everything except actual program output on stderr (note that in this case, logged messages _are not_ actual program output), and once you're talking about a wrapper program like `firejail` (or more concretely looking at existing examples, like `parallel`, `socksify`, `datefudge`, `fakeroot`, and similar), _everything_ that isn't from the wrapped program has to go to stderr so that you don't interfere with the output of the wrapped program. @Hocceruser I'm pretty sure there's no such 'rule' about having no buffering on stderr (at least, if there is, it's not part of the ANSI C standard, and I'm pretty sure it's not part of C89 or C99 either). The only practical difference lies in handling of redirection in the shell (you can more easily redirect stdout than stderr, and stdout is what gets captured to be sent to the next stage in a pipeline). The whole original point was to segregate output being sent to another program with informational output, but back then informational output only meant errors, thus the usage of the name 'stderr'.

gitea-mirror commented

2026-05-05 07:31:04 -06:00

Author

Owner

@startx2017 commented on GitHub (Dec 15, 2017):

everything that isn't from the wrapped program has to go to stderr so that you don't interfere with the output of the wrapped program.

I've replaced all related printf calls with a fmessage() function call (implemented in util.c) and from there we can send all of them to stdout or stderr. I would go for stderr, @Ferroin makes a good point.

commit: c59a19848d

@startx2017 commented on GitHub (Dec 15, 2017): > everything that isn't from the wrapped program has to go to stderr so that you don't interfere with the output of the wrapped program. I've replaced all related printf calls with a fmessage() function call (implemented in util.c) and from there we can send all of them to stdout or stderr. I would go for stderr, @Ferroin makes a good point. commit: https://github.com/netblue30/firejail/commit/c59a19848dd37ac12bf024ba0cc295d3338116ae

gitea-mirror commented

2026-05-05 07:31:05 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 18, 2017):

Let's keep it as stderr, thanks @startx2017

@netblue30 commented on GitHub (Dec 18, 2017): Let's keep it as stderr, thanks @startx2017

gitea-mirror referenced this issue

2026-05-05 10:11:47 -06:00

[PR #1494] [MERGED] Allow private-bin parameters to be absolute paths #3992

Rows
Columns

[GH-ISSUE #1677] Make firejail print to stderr by default (instead of stdout) #1133