Open he32 opened 1 year ago
I have apparently managed to not reproduce the "does nothing" failure mode I observed earlier -- I have exabgp4 up and running on a separate test machine, including "exabgp-cli". And I think I have a handle on the "missing syslog" issue, will open a separate issue about that.
Thank you for this return @he32 - I will do what I can to help. Would this patch be what you would like to see changed and work for you?
diff --git a/src/exabgp/logger/handler.py b/src/exabgp/logger/handler.py
index 1013874e..e45dd38c 100644
--- a/src/exabgp/logger/handler.py
+++ b/src/exabgp/logger/handler.py
@@ -1,5 +1,6 @@
# A wrapper class around logging to make it easier to use
+import os
import sys
import logging
import logging.handlers as handlers
@@ -43,9 +44,14 @@ def getLogger(name=None, **kwargs):
def _syslog(**kwargs):
+ # python for loop variable scope leaks
+ for syslog_file in ['/var/run/log', 'dev/log']:
+ if os.path.exists(syslog_file):
+ break
+
formating = kwargs.get('format', SHORT)
handler = handlers.SysLogHandler(
- address=kwargs.get('address', '/dev/log'),
+ address=kwargs.get('address', syslog_file),
facility=kwargs.get('facility', 'syslog'),
)
handler.setFormatter(logging.Formatter(formating))
I suspect that would be a problem for Darwin, at least my MacOS (up-to-date arm64) only has /var/run/syslog
and none of the other two. NetBSD appears to cope fine with /dev/log
, I don't have a FreeBSD system to check. However, I think I would change 'syslog'
in the next line to 'daemon'
.
Or, better yet, provide a way for the administrator to override the default facility
used for syslog. But as stated above, I would also like to argue that the default should be daemon
and neither user
nor syslog
, ref. this excerpt from my <syslog.h>
:
#define LOG_USER (1<<3) /* random user-level messages */
#define LOG_DAEMON (3<<3) /* system daemons */
#define LOG_SYSLOG (5<<3) /* messages generated internally by syslogd */
The way the exabgp env variables are set up, it would be a large configuration change to do this but it may be worth it. I will look into it as it would allow moving syslog out of file logging section and have both which may be desirable in some cases.
before I get to that point, is this uncontrovesial?
diff --git a/src/exabgp/logger/handler.py b/src/exabgp/logger/handler.py
index 1013874e..0d9a2147 100644
--- a/src/exabgp/logger/handler.py
+++ b/src/exabgp/logger/handler.py
@@ -43,10 +43,16 @@ def getLogger(name=None, **kwargs):
def _syslog(**kwargs):
+ syslog_file = '/dev/log'
+ if sys.platform == 'netbsd':
+ syslog_file = '/var/run/log'
+ if sys.platform == 'darwin':
+ syslog_file = '/var/run/syslog'
+
formating = kwargs.get('format', SHORT)
handler = handlers.SysLogHandler(
- address=kwargs.get('address', '/dev/log'),
- facility=kwargs.get('facility', 'syslog'),
+ address=kwargs.get('address', syslog_file),
+ facility=kwargs.get('facility', 'daemon'),
)
handler.setFormatter(logging.Formatter(formating))
return handler
That looks OK to my eyes, at least.
Although if you want to reduce the noise, you could drop the test for netbsd, since it's fine with using /dev/log
.
The way the exabgp env variables are set up, it would be a large configuration change to do this but it may be worth it.
As long as the default is made "sane" and is documented, I would perhaps not put too much effort into the ability to override the facility, at least if this was the only thing which should be fixed in this area.
I'm working on an update to the exabgp.1 man page, at least bringing it up to 4.2.21 level, as that's what I'm testing with at the moment. A few new "env" variables has been introduced since that man page was last updated, and exabgp.api.highres seems to be gone, at least according to "exabgp --fi".
I'll take a stab at exabgp.conf.5 a little later, and will submit these as one or two pull requests when I'm sort-of satisfied.
I will look into it as it would allow moving syslog out of file logging section and have both which may be desirable in some cases.
OK.
exabgp.1 man page update waiting in https://github.com/Exa-Networks/exabgp/pull/1123
exabgp.conf.5 man page update waiting in https://github.com/Exa-Networks/exabgp/pull/1124
Thank you, I have merged a change to help syslog. I will review when I have some time.
I'm running the old version of exabgp (3.*) on NetBSD/amd64 for a distributed DNS resolver service. This has been stable and has been working flawlessly.
Trying to upgrade to exabgp 4 has so far turned out to be a frustrating experience -- and more so than it ought to be IMHO. I will do my best to come up with constructive input on each of the issues, so this is just a summary of the observed issues so far:
exabgp.daemon.daemonize=true
andexabgp.log.destination=syslog
, no output will ever be seen from exabgp, including syslog. A lack of stdout/stderr outputs makes sense, of course, but nothing in syslog either is more surprising. This causes debugging of config file conversion to require use of system call tracing, and poring over megabytes of output to find the error message. I thought I had this figured out ("use/var/run/log
instead of/dev/log
"), but apparently that's not the case --/dev/log
exists as a compat symlink on NetBSD. However, it is customary to run syslogd in "secure" mode (do not listen on inet/udp port 514).-d
option andexabgp.daemon.daemonize=false
to get any output at all. In my final attempt which I think has a proper config which "ought to work", including use of the healthcheck module, exabgp starts, reports 4 BGP neighbors as "new neighbor:" (two IPv4, two IPv6) but despite this, exabgp fails to establish any BGP sessions; it apparently "just sits there".kill -KILL
to get rid of the apparently stuck exabgp process. That seems excessive, and I thought at least TERM used to be a signal to "please exit"?I know the above descriptions are mostly not "actionable", I will try to dig into each of them separately with an own more detailed description and a separate issue for each of them. This is therefore just to summarize the observations so far, as a start.