Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Syslog log handler #296

Open
aedwardstx opened this issue Jun 21, 2024 · 2 comments
Open

Remove Syslog log handler #296

aedwardstx opened this issue Jun 21, 2024 · 2 comments

Comments

@aedwardstx
Copy link

Greetings! The below snippet sets up a syslog log handler, either using a unix socket or via UDP to localhost. This happens implicitly by pyeapi being in the import chain which can easily happen if you use Napalm. IMHO, a library should not make decisions about how to handle logs, that should be left up to the application consuming the library. In my case, this became a problem in a CI pipeline when the below code opened a socket. As a safeguard, we have a mechanism in place that throws an exception if a socket is opened by the code under test.

https://github.com/arista-eosplus/pyeapi/blob/develop/pyeapi/utils.py#L47-L50

# Create a handler to log messages to syslog
if sys.platform == "darwin":
    _syslog_handler = logging.handlers.SysLogHandler(address='/var/run/syslog')
else:
    _syslog_handler = logging.handlers.SysLogHandler()
@dlyssenko
Copy link
Contributor

hi @aedwardstx, however pyeapi makes lots of logs, updating it and leaving it w/o a handler will break lots of pyeapi deployments. How do you propose to handle _LOGGER then?

@aedwardstx
Copy link
Author

Hey @dlyssenko,

I spot checked a few similar libraries, netmiko, ncclient, napalm, and py-junos-eznc. All of them face similar challenges but none of them implement a log handler. They leave log handling up to the developer to implement as they see appropriate.

python/cpython#91070 indicates logging.handlers.SysLogHandler(address='/var/run/syslog') doesn't work on modern versions of MacOS.

Perhaps consider implementing a warning that the log handler is going away in a future version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants