[GH-ISSUE #301] Please stop using broadcast / journald to return error messages

kerem commented

2026-03-04 01:42:43 +03:00

Owner

Originally created by @et304383 on GitHub (Nov 25, 2015).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/301

This is incredibly annoying and provides zero value when one simply types a command incorrectly.

Originally created by @et304383 on GitHub (Nov 25, 2015). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/301 This is incredibly annoying and provides zero value when one simply types a command incorrectly.

kerem closed this issue

2026-03-04 01:42:44 +03:00

kerem commented

2026-03-04 01:42:44 +03:00

Author

Owner

@ggtakec commented on GitHub (Nov 25, 2015):

Hi @eric-tucker
I want to know in detail the meaning of your this issue.
Does it not mean that the error message that s3fs outputs?
If it is correct, you can not specify a dbglevel(and -d and curldbg) option.
The other, please tell me in detail the contents of a problem.
Thanks in advance for your help.

@ggtakec commented on GitHub (Nov 25, 2015): Hi @eric-tucker I want to know in detail the meaning of your this issue. Does it not mean that the error message that s3fs outputs? If it is correct, you can not specify a dbglevel(and -d and curldbg) option. The other, please tell me in detail the contents of a problem. Thanks in advance for your help.

kerem commented

2026-03-04 01:42:44 +03:00

Author

Owner

@et304383 commented on GitHub (Nov 25, 2015):

Here is what happens. You're broadcasting the error messages from s3fs to journald which then gets blasted to all open terminal windows in addition to the ridiculous popup you see in the screenshot below.

Why don't you just return the error to standard out?

Operation system: Fedora 21 KDE

@et304383 commented on GitHub (Nov 25, 2015): Here is what happens. You're broadcasting the error messages from s3fs to journald which then gets blasted to all open terminal windows in addition to the ridiculous popup you see in the screenshot below. ![s3fs_error](https://cloud.githubusercontent.com/assets/2693414/11401282/300e3c16-9368-11e5-87ab-07309b35e13f.jpg) Why don't you just return the error to standard out? Operation system: Fedora 21 KDE

kerem commented

2026-03-04 01:42:44 +03:00

Author

Owner

@ggtakec commented on GitHub (Nov 25, 2015):

At first, this s3fs error message means "not found mount point dir, so could not mount on".
Probably s3fs failed to mount at running and exited.
Then s3fs put message to syslog() with critical error level.
After that, journals caught it and broadcasted it(and repeated?).
I think probably you can stop it by modifying journals configuration.

And if you need to get error messages from s3fs on stdout(but daemon process does not have stdout), you can run s3fs foreground by specifying "-f" option.
It means you run s3fs manually(not run it as daemon at system starting).

I think you need to run s3fs without error(no mount point) at first, so s3fs does not put any error messages.

Regards,

@ggtakec commented on GitHub (Nov 25, 2015): At first, this s3fs error message means "not found mount point dir, so could not mount on". Probably s3fs failed to mount at running and exited. Then s3fs put message to syslog() with critical error level. After that, journals caught it and broadcasted it(and repeated?). I think probably you can stop it by modifying journals configuration. And if you need to get error messages from s3fs on stdout(but daemon process does not have stdout), you can run s3fs foreground by specifying "-f" option. It means you run s3fs manually(not run it as daemon at system starting). I think you need to run s3fs without error(no mount point) at first, so s3fs does not put any error messages. Regards,

kerem commented

2026-03-04 01:42:45 +03:00

Author

Owner

@et304383 commented on GitHub (Nov 25, 2015):

So your solution to my problem is don't run s3fs incorrectly?

Is there a language barrier here? Your English is broken so I'm not sure my issue is getting across to you correctly.

No program should need to broadcast to the entire system when a syntax error occurs on the command line call. I've NEVER seen this done, ever, in all my years using hundreds of Linux programs.

Your -f argument to run in the foreground works, but this should be the default behaviour. I can't imagine any circumstance where I'm running the command line tool and want to broadcast syntax errors to every single terminal I have open (which is dozens during a typical work day).

@et304383 commented on GitHub (Nov 25, 2015): So your solution to my problem is don't run s3fs incorrectly? Is there a language barrier here? Your English is broken so I'm not sure my issue is getting across to you correctly. No program should need to broadcast to the entire system when a syntax error occurs on the command line call. I've NEVER seen this done, ever, in all my years using hundreds of Linux programs. Your -f argument to run in the foreground works, but this should be the default behaviour. I can't imagine any circumstance where I'm running the command line tool and want to broadcast syntax errors to every single terminal I have open (which is dozens during a typical work day).

kerem commented

2026-03-04 01:42:45 +03:00

Author

Owner

@timuralp commented on GitHub (Nov 25, 2015):

@eric-tucker have you looked at how s3fs reports error messages? You may want to look into src/common.h (this is the line that logs messages):

syslog(S3FS_LOG_LEVEL_TO_SYSLOG(level), "%s" fmt "%s", S3FS_LOG_NEST(nest), __VA_ARGS__);

s3fs has no notion of journald, broadcast, or anything else you're complaining about. About syslog(3): "syslog() generates a log message, which will be distributed by syslogd(8)". You can read further about this in the man pages (man syslog).

What may actually be the problem, as @ggtakec has mentioned, is the configuration of journald on your system. Is ForwardToWall= enabled in journald.conf (http://man7.org/linux/man-pages/man5/journald.conf.5.html)? Note from the man page: "By default, only forwarding to wall is enabled."

Lastly, please check the tone of your posts. There is no need to be rude just because you're ignorant of how s3fs logs messages and how they are propagated. I suggest learning more about how syslog messages are handled on your particular platform.

P.S. The solution to your problem @ggtakec already mentioned: "I think probably you can stop it by modifying journals configuration." (he's referring to journald and journald.conf, but surely the small error did not trip you up).

@timuralp commented on GitHub (Nov 25, 2015): @eric-tucker have you looked at how s3fs reports error messages? You may want to look into `src/common.h` (this is the line that logs messages): ``` syslog(S3FS_LOG_LEVEL_TO_SYSLOG(level), "%s" fmt "%s", S3FS_LOG_NEST(nest), __VA_ARGS__); ``` s3fs has no notion of journald, broadcast, or anything else you're complaining about. About `syslog(3)`: "syslog() generates a log message, which will be distributed by syslogd(8)". You can read further about this in the man pages (`man syslog`). What may actually be the problem, as @ggtakec has mentioned, is the configuration of journald on _your_ system. Is `ForwardToWall=` enabled in `journald.conf` (http://man7.org/linux/man-pages/man5/journald.conf.5.html)? Note from the man page: "By default, only forwarding to wall is enabled." Lastly, please check the tone of your posts. There is no need to be rude just because you're ignorant of how s3fs logs messages and how they are propagated. I suggest learning more about how syslog messages are handled on your particular platform. P.S. The solution to your problem @ggtakec already mentioned: "I think probably you can stop it by modifying journals configuration." (he's referring to journald and journald.conf, but surely the small error did not trip you up).

kerem commented

2026-03-04 01:42:45 +03:00

Author

Owner

@et304383 commented on GitHub (Nov 25, 2015):

Why should I have to know exactly how s3fs logs messages? Hundreds, thousands, and even millions of developers make command line tools that have no problem returning error messages to the console. I've never seen this behaviour. The outlier here is this application. Your response of "ignorant of how s3fs logs messages" is a typical Linux elitist response and is not helpful to anyone.

I'm an end user. It's not my job to understand how the source code works for an application I'm using. I do, however, expect that an application I use follows obvious Linux standards and makes uses of stderr and stdout, rather than some other.

I'm sorry if I come across as rude, but it frustrates me that either ggtakec didn't understand my issue or was giving me a useless response of "don't run the tool in such a way that it makes an error." It's like this person did not understand that I wasn't asking for help with a particular error. I was asking why the error reporting is done in such a non-conventional and obtrusive way.

Finally, I set ForwardToWall to no and while one of the popups goes away (the large one) the smaller one is still present and I still get a broadcast to all terminals. The issue here isn't with how syslog messages are handled on my system. It's with s3fs using syslog messages to begin with rather than just using stderr. I shouldn't have to make system level configuration changes so that one outlier program doesn't return errors in a completely incorrect manner.

System wide broadcast level messages have a place - displaying an error message from a command line tool caused by a syntax error is not one of them.

@et304383 commented on GitHub (Nov 25, 2015): Why should I have to know exactly how s3fs logs messages? Hundreds, thousands, and even millions of developers make command line tools that have no problem returning error messages to the console. I've never seen this behaviour. The outlier here is this application. Your response of "ignorant of how s3fs logs messages" is a typical Linux elitist response and is not helpful to anyone. I'm an end user. It's not my job to understand how the source code works for an application I'm using. I do, however, expect that an application I use follows obvious Linux standards and makes uses of stderr and stdout, rather than some other. I'm sorry if I come across as rude, but it frustrates me that either ggtakec didn't understand my issue or was giving me a useless response of "don't run the tool in such a way that it makes an error." It's like this person did not understand that I wasn't asking for help with a particular error. I was asking why the error reporting is done in such a non-conventional and obtrusive way. Finally, I set ForwardToWall to no and while one of the popups goes away (the large one) the smaller one is still present and I still get a broadcast to all terminals. The issue here isn't with how syslog messages are handled on my system. It's with s3fs using syslog messages to begin with rather than just using stderr. I shouldn't have to make system level configuration changes so that one outlier program doesn't return errors in a completely incorrect manner. System wide broadcast level messages have a place - displaying an error message from a command line tool caused by a syntax error is not one of them.

kerem commented

2026-03-04 01:42:45 +03:00

Author

Owner

@RobbKistler commented on GitHub (Nov 25, 2015):

First, its important to understand that some of the error checking that s3fs-fuse does happens late, after libfuse has already "daemonized" the process. This particular error happens to be one of those.

Second, I think there's a bug that causes some messages to be sent to syslog with LOG_EMERG instead of LOG_CRIT. Some systems have the syslog facility configured to broadcast emergencies.

@ggtakec at 5af6d4bd82 maybe in common.h:

#define S3FS_LOW_LOGPRN_EXIT(fmt, ...) \
       if(foreground){ \
         fprintf(stderr, "s3fs: " fmt "%s\n", __VA_ARGS__); \
       }else{ \
         syslog(S3FS_LOG_CRIT, "s3fs: " fmt "%s", __VA_ARGS__); \
       }

should be

#define S3FS_LOW_LOGPRN_EXIT(fmt, ...) \
       if(foreground){ \
         fprintf(stderr, "s3fs: " fmt "%s\n", __VA_ARGS__); \
       }else{ \
         syslog(S3FS_LOG_LEVEL_TO_SYSLOG(S3FS_LOG_CRIT), "s3fs: " fmt "%s", __VA_ARGS__); \
       }

Without the conversion from S3FS log levels to syslog levels, this ends up going to syslog() with LOG_EMERG.

Unfortunately, this change would make "exits" totally silent if the user does not specify -f.

@ggtakec, would it be OK to always print to stderr and syslog for S3FS_PRN_EXIT()?

@RobbKistler commented on GitHub (Nov 25, 2015): First, its important to understand that some of the error checking that s3fs-fuse does happens late, after libfuse has already "daemonized" the process. This particular error happens to be one of those. Second, I think there's a bug that causes some messages to be sent to syslog with LOG_EMERG instead of LOG_CRIT. Some systems have the syslog facility configured to broadcast emergencies. @ggtakec at 5af6d4bd825a1e771a30d4e456a77d7d5b3fbfdd maybe in common.h: ``` #define S3FS_LOW_LOGPRN_EXIT(fmt, ...) \ if(foreground){ \ fprintf(stderr, "s3fs: " fmt "%s\n", __VA_ARGS__); \ }else{ \ syslog(S3FS_LOG_CRIT, "s3fs: " fmt "%s", __VA_ARGS__); \ } ``` should be ``` #define S3FS_LOW_LOGPRN_EXIT(fmt, ...) \ if(foreground){ \ fprintf(stderr, "s3fs: " fmt "%s\n", __VA_ARGS__); \ }else{ \ syslog(S3FS_LOG_LEVEL_TO_SYSLOG(S3FS_LOG_CRIT), "s3fs: " fmt "%s", __VA_ARGS__); \ } ``` Without the conversion from S3FS log levels to syslog levels, this ends up going to syslog() with LOG_EMERG. Unfortunately, this change would make "exits" totally silent if the user does not specify -f. @ggtakec, would it be OK to always print to stderr _and_ syslog for S3FS_PRN_EXIT()?

kerem commented

2026-03-04 01:42:45 +03:00

Author

Owner

@RobbKistler commented on GitHub (Nov 25, 2015):

I opened PR #302 with a proposal to address this issue.

@RobbKistler commented on GitHub (Nov 25, 2015): I opened PR #302 with a proposal to address this issue.

kerem commented

2026-03-04 01:42:45 +03:00

Author

Owner

@ggtakec commented on GitHub (Nov 26, 2015):

@eric-tucker Sorry for a bug about syslog message level which is output when s3fs exited.
It had been fixed by #302.
Please check latest master branch codes.

@RobbKistler and @timuralp Thanks for support to me.

I close this issue.
But if you have more problem about this, please reopen this issue or post new issue.

Regards,

@ggtakec commented on GitHub (Nov 26, 2015): @eric-tucker Sorry for a bug about syslog message level which is output when s3fs exited. It had been fixed by #302. Please check latest master branch codes. @RobbKistler and @timuralp Thanks for support to me. I close this issue. But if you have more problem about this, please reopen this issue or post new issue. Regards,

kerem commented

2026-03-04 01:42:45 +03:00

Author

Owner

@et304383 commented on GitHub (Nov 26, 2015):

This fixes it. Thank you very much.

@et304383 commented on GitHub (Nov 26, 2015): This fixes it. Thank you very much.

kerem referenced this issue

2026-03-04 01:53:39 +03:00

[PR #170] [MERGED] Reviewed and fixed response codes print in curl.cpp - #157 #1376

Rows
Columns

[GH-ISSUE #301] Please stop using broadcast / journald to return error messages #157