On a overworked server you might see that /sbin/init maybe-ubiquity is taking up a lot of CPU cycles.
This will be evident if you use top.
We experienced this on a Focal Fossa Ubuntu 20.04 server.
The problem is frustrated by the fact the process is owned by user 1, root, as below:
1 root 20 0 171280 11724 8240 R 73.7 0.1 2:04.17 /sbin/init maybe-ubiquity
At first fixing the problem seems obvious – google shows that maybe-ubiquity has something to do with graphical installation so one could just remove it. Removing it is possible, although a reboot is required:
Apparent instructions:
edit /etc/default/grub
Comment out the line:
#GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity"
Now run update-grub.
HOWEVER, once you do this, you now have a new problem. This time, maybe-ubiquity is gone but /sbin/init is giving high CPU. So actually /sbin/init, still owned by root user 1, is an issue.
In our instance the problem was related to PHP service maximum sub-processes. A closer glance at the busy server would have revealed that the number of open processes is out of control. For reference this server normally has just under 1000 processes, but it had over 2500 processes.
The solution was to reduce the number of maximum sub-processes for the server using the Virtualmin Pro bulk update facility. Many of them were set to 9999 but should have rather been on default, which is 16.
Actually having them at 9999 wasn’t a problem for the majority of websites, but one specific probably buggy site or CRON, was shooting up the processes into over a thousand.
The ideal situation is to figure out what /sbin/init is running to cause so much CPU, but in this case an ulterior problem had to be addressed and then the CPU came down a lot.