Is there an issue with Ubuntu 19 image

I am seeing a process /tmp/kdevtmpfsi in a fresh image installation after sometime. Any idea why is it taking 100%cpu and also it tries to update the metrics for which I have not installed any agent.

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

On a review on running a redis docker container which resulted in this situation, it appears that UFW does not interoperate with Docker well on the Docker on Ubuntu image built from the upstream packages for UFW and Docker.

Docker inserts the rules for forwarding exposed ports in the DOCKER chain, which is included in the FORWARD chain before any UFW rules are processed, so containers that have exposed ports that rely on firewall isolation are not in fact isolated.

The upstream package that Docker is installed from includes a service file that does not pull in options from the /etc/default/docker file, so making changes such as --iptables=false there have no effect. You can mask or update the service unit file to include this option and restart docker to avoid having Docker populate iptables, and manage exposing the ports, though this may have other implications with respect to the iptables rules Docker sets for inter-container communication.

Reviewing the docker logs for the container, it shows that remote connections are made to the redis instance, and without securing through other means ( e.g. requiring authentication ) the connections eventually load a module and configure redis to sync as a slave which is involved in the mechanism for getting the unwanted program from executing on the redis instance.

The id of the process running within the container overlaps with the id of the do-agent user on the host, so from the host, it looks like the process is running as the do-agent user, but in fact is running within the container which isn’t aware of the do-agent user but shares the same id.

We’re looking into this to see what options we have to better assist in surfacing the importance of using secured deployments in containers as well as exploring options to address the UFW/Docker situation. For the moment, I would recommend always using authentication based configurations, and if you rely on the firewall isolation, you will want to modify the Docker service unit to disable modifying iptables, and manage iptables manually for the containers you deploy.

I’m also getting 100% CPU utilization via a do-agent owned task /tmp/kdevtmpfsi. I am using the DO Docker image which is Ubuntu 18.04. Is this related to the use of the metrics agent?

If it helps, I installed Ubuntu 20.04 almost a week ago (New droplet from scratch). The only 4 things I installed were caddyserver using their PPA, php7,d composer and the do-agent from digital ocean.

Again this was less than a week ago.