I discussed with slangasek, who said: - The workaround is to either to configure systemd to restart rsyslog when the socket is available, or to have openvpn restart rsyslog when the VPN comes up. - The definitive fix would require rsyslogd to grow netlink support (or be managed by something else that does).
For now, I'm working around this by using openvpn config. ** Summary changed: - rsyslog fails to bind to tcp socket on restart + rsyslog attached to OpenVPN-managed tun0 fails to bind to tcp socket on restart -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1799702 Title: rsyslog attached to OpenVPN-managed tun0 fails to bind to tcp socket on restart Status in rsyslog package in Ubuntu: New Bug description: My rsyslog configuration listens on TCP port 514 and is bound to an address on tun0 (created by an openvpn server daemon): module(load="imtcp") input(type="imtcp" port="514" address="10.8.9.1") This machine rebooted (due to unattended upgrades) overnight and when it came back up, rsyslog was not listening on the port. The logs show: Oct 24 03:00:16 foo rsyslogd-2077: Could not create tcp listener, ignoring port 514 bind-address 10.8.9.1. [v8.16.0 try http://www.rsyslog.com/e/2077 ] A restart of rsyslogd was required to address the issue. I'm curious what the right solution to this problem would be, as the bind interface is configuration-dependent. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1799702/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
