> > > I had to add this patch to make 'runltp -f net.rpc' pass just after
> > > container is started - that happens in container autotests here.
> > Yep, I suspected this. Because on normal linux distro it's working right after
> > boot (tested on rpc01.sh). Can't this be a setup issue?
> This depends on what is installed and how it is configured.
> But definitely the state with rpcbind process not running and systemd is
> listening on rpcbind sockets - is valid.
> In the setup where the issue was caught, the test harness creates a
> container with minimal centos8 setup inside, boots it, and starts ltp
> inside.
> Just reproduced manually:
> [root@vz8 ~]# vzctl start 1000
> Starting Container ...
> ...
> [root@vz8 ~]# vzctl enter 1000
> entered into CT 1000
> CT-1000 /# pidof rpcbind
> CT-1000 /# rpcinfo > /dev/null 2>&1
> CT-1000 /# pidof rpcbind
> 678
> CT-1000 /#
Thanks for info. I'm asking because if it's a setup bug it should not be hidden
by workaround but reported. I suppose normal Centos8 VM works.
Kind regards,
Petr
>> Just reproduced manually:
>
>> [root@vz8 ~]# vzctl start 1000
>> Starting Container ...
>> ...
>> [root@vz8 ~]# vzctl enter 1000
>> entered into CT 1000
>> CT-1000 /# pidof rpcbind
>> CT-1000 /# rpcinfo > /dev/null 2>&1
>> CT-1000 /# pidof rpcbind
>> 678
>> CT-1000 /#
>
> Thanks for info. I'm asking because if it's a setup bug it should not be hidden
> by workaround but reported. I suppose normal Centos8 VM works.
I's say this is starting service on demand and this is exactly what socket activation is designed for.