Re: [systemd-devel] systemctl, unclear error msg/warning, "Refusing to accept PID outside of service control group..."

2022-11-03 Thread Michal Koutný
Hi.

On Thu, Oct 27, 2022 at 10:46:38PM +0200, rop  wrote:
>"New main PID x does not belong to service, and PID file is not
> owned by root. Refusing."
> And when trying to examine the pid-file, it wasn't even created.

That'd suggest that the service has misconfigured PIDFile= path (not
pointint to where the daemon actually writes its pid).

> Where can I find an explanation of these messages?
> 
> What exactly is deemed "unsafe"?

Perhaps,
https://github.com/systemd/systemd/issues/8085#issuecomment-363008993

> And what to do about it?

Update the application/its unit file :-p

Michal



signature.asc
Description: Digital signature


Re: [systemd-devel] Best practise for creating sockets without a corresponding service

2022-11-03 Thread Michal Koutný
Hello.

On Fri, Oct 28, 2022 at 12:39:01PM +0200, Simon Mullis  
wrote:
> Step 0
> - service_data_gen => creates N outputs
> 
> Step 1
> - service1@.service => N instances are created but don't actually need
> to do anything.
> - service1@.socket => N sockets are created which are the target FIFOs
> for the output of - service_data_gen above.

What processes the data flowing into step1@.socket (==service1@.socket)?

> I don't need any service to actually run in step1, I would like
> systemd to manage the sockets and the dependencies (as it is for the
> rest of the chain).

So why don't you just shift the rest of the pipeline/numbering?
step1@.socket would trigger step1@.service and it'd do job that your
current step2@.service does.

And you'd initiate your pipeline with

eval systemctl start step1@{1..${cpu_cores}}.socket

and trigger by writes into the sockets from the single
service_data_gen.

> What is the best practise for an ExecStart= entry to act as a dummy,
> where no service is actually required?  At the moment I am using:
> 
> ExecStart=/usr/bin/sh -c "sleep infininty" in the service template for
> service1@.service

ExecStart=/bin/true
RemainAfterExit=true

is slightly better in terms of system resource use.

> I think the crux of this is entirely related to the use of instance
> templates and linking one unconnected single parent service to many
> child services (and sockets).

FTR, not related to templates in particular, as systemd.socket(5) says:
"For each socket unit, a matching service unit must exist".

HTH,
Michal


signature.asc
Description: Digital signature