100% cpu usage with unresolved name server

Bug #1511118 reported by Lefteris Nikoltsios
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
socat (Debian)
Fix Released
Unknown
socat (Ubuntu)
Fix Released
Critical
Unassigned

Bug Description

Description: Ubuntu 15.10
Release: 15.10

Package Info:
==========
socat:
  Installed: 1.7.3.0-1
  Candidate: 1.7.3.0-1
  Version table:
 *** 1.7.3.0-1 0
        500 http://gr.archive.ubuntu.com/ubuntu/ wily/universe i386 Packages
        100 /var/lib/dpkg/status

[Impact]
At Ubuntu Wily OS, when we use the socat with a nameserver which is not defined at /etc/hosts and is unknown, the system hits 100% cpu usage. Additional, to terminate the process you must give -9 parameter in kill command. Ctrl+C does not terminate the process.

With older versions of socat (< 1.7.3.0 upstream) the system does not drive up to 100% cpu usage, but prints appropriate error message.

[Test case]
* A simple test to validate the issue, is to execute the below command:
socat tcp:server-local:789 -
* Using older version of socat the above command will print:
socat[2756] E getaddrinfo("server-local", "(null)", {1,0,1,6}, {}): Name or service not known

[Regression Potential]
This bug affects the releases that use socat 1.7.3.0 upstream version (Wily, Xenial). The Vivid, Trusty and Precise are not affected.

Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

Lefteris, could you add the upstream patch here and follow all the SRU steps? Thank you!

Changed in socat (Ubuntu):
importance: Undecided → Critical
status: New → Confirmed
Changed in socat (Debian):
status: Unknown → New
Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Alkis, Why Critical? 100% CPU and requiring kill -9 in a very specific invocation envirionment is not world-ending for something that is primarily a sysadmin tool. I will be happy to sync into Xenial from Debian after a Debian upload fixing the issue. I'd like to see some record of this being committed upstream before I'd be happy to upload an SRU to Wily, but if another uploader wants to drive it and review closer then that's fine.

Changed in socat (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Alkis Georgopoulos (alkisg) wrote :

Hi Robie,

from https://wiki.ubuntu.com/Bugs/Importance => Critical:
> Renders the system temporarily or permanently unusable
Yup, especially if you are on a single core system and you've never heard of what a terminal or a `kill -9 `is.

> Severely affects applications beyond the package responsible for the root cause
Yup, e.g. it causes our "epoptes" application that relies on socat to hang there waiting for socat to finish, but it never does until the `kill -9`.

Upstream socat unfortunately doesn't use a bug tracker, and we don't feel comfortable posting here the headers of the e-mails that we exchanged with the developer.
But it should be possible to get the bug triaged and the patch committed to Ubuntu without proof from upstream, as is the case with many many other bugs.

The socat maintainer in Debian didn't reply either; if he does before Xenial featurefreeze etc it'll be fine, but if not, it would be nice to have this fixed at least in Ubuntu. The Debian maintainer might fix it e.g. after Xenial is out, but before the Stretch freeze; that would leave Ubuntu broken while Debian would be fine.

/me also needs to check why he isn't getting mail notifications from launchpad recently... :)

Thanks,
Alkis

Changed in socat (Debian):
status: New → Fix Released
Revision history for this message
Robie Basak (racb) wrote :

1.7.3.0-2 is synced from Debian now so this is fixed in Xenial.

If someone can prepare a backport, please follow the steps at https://wiki.ubuntu.com/StableReleaseUpdates#Procedure to have Wily updated.

Changed in socat (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.