-
Notifications
You must be signed in to change notification settings - Fork 837
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
120 seconds timeout on OpenNebula running subp.py #4078
Comments
Launchpad user Ron(rblom) wrote on 2023-02-13T13:09:39.495644+00:00 |
Launchpad user Ron(rblom) wrote on 2023-02-13T13:28:58.813028+00:00 |
Launchpad user Ron(rblom) wrote on 2023-02-13T13:57:14.859601+00:00 Launchpad attachments: cloud-init.tar.gz |
Launchpad user Scott Moser(smoser) wrote on 2023-02-13T14:58:54.984894+00:00 OpenNebula passes network information ("Context" [1]) in shell syntax. It drops the permissions using 'sudo'. I suspect that sudo is timing out on a dns lookup as networking is not configured at this point in boot. I've never felt it terribly useful for sudo to rely on dns, but it can depending on configuration [3]. The easy solutions for you are:
The right solution is probably to implement a parser in cloud-init that does not involve executing 'sh' at all. (Sorry, it was me that wrote that the first time). -- |
Launchpad user Chad Smith(chad.smith) wrote on 2023-02-15T04:33:25.707380+00:00 Looking over journalctl logs as well as your network config in the attached cloud-init.log it looks like one of the following could lead to that sudo timeout on DNS resolution Scott mentioned.
Two other things I note in your attached logs.
This is due to misconfiguration I believe in user-data provided in context.sh. ntp: The service_name and services keys should live under a "config:" key like this: ntp:
sudo cloud-init schema --system --annotate # on this system should help highlight some of those schema problems in the future. Though I don't think it handles non-ASCII character sets currently. |
Launchpad user Chad Smith(chad.smith) wrote on 2023-02-15T04:45:36.632560+00:00 Agreed that there could be a better parsing of context.sh instead of shelling out. That said, this has been in place since 2013, I'd rather avoid the risk if this is a network config problem. |
Launchpad user Ron(rblom) wrote on 2023-02-17T13:31:50.130591+00:00 Hi, I hacked the cloud-init not to use sudo and then there's no timeout. So your first suggestion seems the right one. Will try to figure out why sudo is waiting for 120 seconds. Tnx |
Launchpad user Alberto Contreras(aciba) wrote on 2023-02-23T07:45:49.612487+00:00 Per the discussion, it looks like it is a cloud misconfiguration and I am going to mark it as invalid for the time being. |
This bug was originally filed in Launchpad as LP: #2007149
Launchpad details
Launchpad user Ron(rblom) wrote on 2023-02-13T13:09:39.495644+00:00
Hi,
I'm using the latest AlmaLinux 9 GenericCloud image. This has cloud-init 22.1-5.el9.alma and works with OpenNebula. Booting is very slow on OpenNebula because of a 120 seconds timeout.
systemd-analyze blame give me:
2min 3.083s cloud-init-local.service
In de cloud-init.log I see:
2023-02-09 11:30:10,244 - util.py[DEBUG]: Reading from /run/cloud-init/tmp/tmpac937qy0/context.sh (quiet=False) 2023-02-09 11:30:10,245 - util.py[DEBUG]: Read 3674 bytes from /run/cloud-init/tmp/tmpac937qy0/context.sh 2023-02-09 11:30:10,245 - subp.py[DEBUG]: Running command ['sudo', '-u', 'nobody', 'bash', '-e'] with allowed return codes [0] (shell=False, capture=True) 2023-02-09 11:32:10,667 - util.py[DEBUG]: Reading from /sys/class/net/eth0/addr_assign_type (quiet=False) 2023-02-09 11:32:10,668 - util.py[DEBUG]: Read 2 bytes from /sys/class/net/eth0/addr_assign_type 2023-02-09 11:32:10,669 - util.py[DEBUG]: Reading from /sys/class/net/eth0/uevent (quiet=False)See the two minute timeout after subp.py command.
When running the cloud-init-local.service manually when the machine is started I get the same logging but without the 120 seconds timeout.
The text was updated successfully, but these errors were encountered: