Hi Lorenzo. Sorry for late answer.
Lorenzo - 14.04.24, 11:36:32 CEST: > On Sat, 13 Apr 2024 15:05:41 +0200 > > Martin Steigerwald <mar...@lichtvoll.de> wrote: > > Martin Steigerwald - 13.04.24, 14:32:16 CEST: > > > Any idea how to find the cause of what is happening here? > > > > I found the cause: > > > > The container starts out with an almost empty environment. In > > [...] > > > > root@zdevuan:~# cat rcS.log > > > > >> environment > > > > container=lxc > > PWD=/ > > > > >> end of environment > > > > No PATH defined. > > > > The script defines it. See line 8 in my changed script. However it > > > > does not export it. Thus adding line 9 fixes the bug I reported: > > 8 PATH=/sbin:/usr/sbin:/bin:/usr/bin > > 9 export PATH > > > > The network is configured just fine after adding that line. > > > > Same goes for stage 2. In /etc/runit/2 I added: > >[...] > > > > Exporting the PATH there as well like > > > > 1 #!/bin/sh > > 2 > > 3 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin > > 4 export PATH > > 5 SVDIR=/etc/service > > > > fixes > > > > root@zdevuan:~# cat /etc/boot.d/network > > #!/usr/bin/env sh > > > > /etc/init.d/networking restart > > > > The network is configured even without the "export PATH" fix in > > /etc/runit/1. > > OK, so if I undertand correctly we either export PATH in the > /etc/init.d/networking script or we export PATH both in stage 1 and 2 > (so the script does not fail during boot and can be called during > runtime): is that correct? In case it is called during both stage 1 and stage 2, yes. And yes, it appears there is a link to the networking script in /etc/rcS.d which would be called in stage 1. > If yes I think it's better to fix the networking script (ifupdown pkg) > so that the fix works for sysvinit users too. Yeah, I would think so to, but: % grep PATH /etc/init.d/networking PATH="/sbin:/bin:/usr/sbin:/usr/bin" Yet, it has no export statement, it just defines the variable. What may be happening here is that something called from the script requires a valid path, but without export the variable would not be exported to that something. So it might be that the networking script needs an "export PATH" added to it. However: > Different story if multiple scripts fails during boot because of empty > PATH; many scripts in /etc/rc.S/ set their PATH but others don't.. > Could you confirm that no other scripts fails in your container setup > when PATH is not exported in stage 1 ? There are some script which do not set a command search path: % grep -L "PATH" * README brightness checkroot-bootclean.sh hwclock.sh mariadb mountall-bootclean.sh mountnfs-bootclean.sh mountnfs.sh procps rcS sudo I am not sure whether those work correctly or not. Some are not even supposed to work inside a container at all. What I wonder: What is the supposed default or standard here? Are init scripts supposed to be started with PATH variable set up and exported or not? How is it done with SysVInit? I bet it would be best to match as close as possible what SysVInit is doing to be as compatible as possible. Otherwise it might be challenging to chase and find all the corner cases with existing setups. And as there is no issue initializing the network in the container with SysVInit instead of Runit used as PID 1, I'd consider a change in Runit. At least it could be challenging to find whether networking inside a container is the only thing that breaks. Of course in case PATH variable needs to be setup, one might argue that Incus/LXC needs to do it, cause networking is setup just fine even with Runit in physical machines or VMs. So far the container appears to be working, but I did not check whether every single init script works correctly. Partly due to bootlogd not working inside the container. > > I just wonder why stage 2 contains /usr/local bin directories. I think > > that should not be the case. Shall I report this as a different issue? > > PATH is passed to env call for runsvdir, so I guess one can exec a bin > from local as runscript (not sure) without setting the PATH. I can't > think of other use cases.. > I'm fine with removing, just a bit wary, I'm afraid to break some custom > setup Hmm, I get that. I am just a bit concerned as it may be a security issue. > > I added empty "debug" and "verbose" files in /etc/runit but did not > > find any debug output. Maybe those files needed to have some content. > > Maybe it requires bootlogd. > > those files only work for runit stuff (runscripts and the sv trigger), > boot scripts are for sysvinit and do not obey to runit settings :( > perhaps it's time to roll some native runit bootscripts.. I see. Well that would be great. But also would require a lot of work and testing I bet. Best, -- Martin
