/etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 3: import: not found

I’m getting a bunch of errors every few minutes on /var/log/messages. It looks like a python script is getting run by the shell instead of the interpreter:

Oct 12 20:49:14 turris dnsmasq-script[6279]: /sbin/hotplug-call: /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 3: import: not found
Oct 12 20:49:14 turris dnsmasq-script[6279]: /sbin/hotplug-call: /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 4: import: not found
Oct 12 20:49:14 turris dnsmasq-script[6279]: /sbin/hotplug-call: /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 5: import: not found
Oct 12 20:49:14 turris dnsmasq-script[6279]: /sbin/hotplug-call: /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 6: from: not found
Oct 12 20:49:14 turris dnsmasq-script[6279]: /sbin/hotplug-call: /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 7: import: not found
Oct 12 20:49:14 turris dnsmasq-script[6279]: /sbin/hotplug-call: /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 8: import: not found
Oct 12 20:49:14 turris dnsmasq-script[6279]: /sbin/hotplug-call: /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 9: import: not found
Oct 12 20:49:14 turris dnsmasq-script[6279]: /sbin/hotplug-call: /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 10: from: not found
Oct 12 20:49:14 turris dnsmasq-script[6279]: /sbin/hotplug-call: /etc/hotplug.d/dhcp/99-dhcp_host_domain_ng.py: line 13: syntax error: unexpected "("
Oct 12 20:49:14 turris dnsmasq[6279]: script process exited with status 2

Any ideas what’s happening here?

https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/332 but I have no idea why it could still happen.

Thanks! It still happens because the fix introduces a new bug.

The relevant line of code is:

[ -x $script ] && $script || . $script

where $script is the Python script.

Turns out that it is executable, so it does get run directly but it exits non-0 (1 to be precise), so the next part also runs (. $script), causing it to be sourced and as such interpreted by the shell.

I’m going to investigate it a bit further to understand why it’s exiting 1 and will try to submit fixes to both problems if I can.

It would be helpful if there was a link between the issue and the merge requests or commits that fixed it. :frowning:

1 Like

In fact, could you point me to where the fix should go?

I looked in that repo but the /sbin/hotplug-call script is not present. It is present in the turris-os project hosted on Github but the version on master is clearly different from what I have running on my router.

Where should I look? Is there any documentation where I can see how the release process is setup?

It might be best to simply use something like

if [ -x "$script" ];
  then "$script"
  else . "$script"
fi

I think the repo is correct, but better wait for Turris team colleagues.

Can you please let us know, which version of Turris OS do you have? I see that there is a label Turris OS 4.x, but I would just rather avoid misunderstanding. In this case, even the kernel version should be sufficient.

In the turris-os-packages repository, you should focus just on the master branch. Nothing else for Turris OS 4.0+. I see that script /sbin/hotplug-call comes from package base-files. This package is directly pulled from OpenWrt repository as many other packages.

But we are patching this file as it was mention in linked thread by @vcunat. See the patch, which was sent to upstream (but not merged, yet).

Sure. Take a look at our development workflow at turris-build repository.

That patch seems insufficient to me due to wrong precedence of the two operators, as pointed out in post above, but there certainly remain some other unclear bits.

Let’s mention author of the patch @paja, so he will look at it.

1 Like

Thanks for all the info. I am indeed on TOS 4.0, uname:

Linux turris 4.14.146 #0 SMP Wed Sep 25 23:24:28 2019 armv7l GNU/Linux

Having read the upstream pull request thread, it seems like this patch is not going to get merged any time now or in the future.

Their proposed approach is to wrap the python script (which I just learned is an exception as everything else is shell) in a shell script that calls it, and they seem to have good reason to suggest that, both technical (subshells) and from a project perspective (breaks current contract, requires new and more complex documentation, etc).

Right now this is broken. @vcunat’s suggestion would work but means TurrisOS is eternally patching that, which can cause maintenance troubles. Personally it looks like OpenWRT’s suggestion is better in the long term for this project but obviously I will defer that decision to the competent people working directly on TurrisOS.

I can submit patches with your preferred solution.

I am also still investigating why the script exits 1. I have worked out that it’s because some entries in /tmp/dhcp.leases have * in them, such as:

1571092641 xx:xx:xx:xx:xx:xx 172.20.0.111 * *

I’m not sure why they are there though, or what’s the correct way of dealing with them.