-
Notifications
You must be signed in to change notification settings - Fork 717
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
tracing-journald: Do not connect socket #1745
Comments
/cc @Ralith |
SGTM! |
Actually, one drawback to this: if we don't |
Lets journald subscribers survive a journald restart. Closes #1745 ## Motivation Currently the journald subscriber immediately connects to the journald socket. As such I understand it'd not survive a full restart of journald. ## Solution Do not connect the client socket immediately; instead pass the socket pathname every time we send a message. This is also what upstream does.
Lets journald subscribers survive a journald restart. Closes #1745 ## Motivation Currently the journald subscriber immediately connects to the journald socket. As such I understand it'd not survive a full restart of journald. ## Solution Do not connect the client socket immediately; instead pass the socket pathname every time we send a message. This is also what upstream does.
Lets journald subscribers survive a journald restart. Closes #1745 ## Motivation Currently the journald subscriber immediately connects to the journald socket. As such I understand it'd not survive a full restart of journald. ## Solution Do not connect the client socket immediately; instead pass the socket pathname every time we send a message. This is also what upstream does.
Lets journald subscribers survive a journald restart. Closes #1745 ## Motivation Currently the journald subscriber immediately connects to the journald socket. As such I understand it'd not survive a full restart of journald. ## Solution Do not connect the client socket immediately; instead pass the socket pathname every time we send a message. This is also what upstream does.
Bug Report
Currently tracing-journald subscribers immediately connect to the systemd journal socket.
I believe this implies that the subscriber will permanently fail if the connection to the socket ever drops, e.g. if journald crashes. I think the subscriber should use an unconnected socket and then use
send_to
to specify the target socket explicitly for every message. That'd make a subscriber "survive" a journald crash, and it's also what upstream doesI can make a pull request (based on #1744) to change this.
Crates
tracing-journald
The text was updated successfully, but these errors were encountered: