Re: [systemd-devel] Best practise for creating sockets without a corresponding service
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
[systemd-devel] Best practise for creating sockets without a corresponding service
Hello systemd fans.
I'm creating a pipeline of services and would like systemd to manage
all aspects possible.
The first service in the chain creates an arbitrary number of FIFO
outputs (as a demultiplexer), which I use as inputs to the rest of the
chain. These outputs are internal to the service itself and cannot be
managed by systemd.
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.
Step P (where P is 2..whatever)
- serviceP@.service and serviceP@.socket => Processed data flows via
STDIN and STDOUT (using StandardInput=fd:socket_name and
StandardOutput=fd:socket_name and also
FileDescriptorName=serviceP.%i.socket for example) all managed by
systemd. Here there are indeed additional services which are launched
and further process the data and it flows through each link. All works
well here. Lovely...
So, as there are a variable number of inputs to the first link in the
chain, I use templates for services and sockets for the subsequent
links in the chain. In this case, the variability is based on the
number of CPU cores so I use a oneshot service to start them all with
the following fragment in the ExecStart script:
cpu_cores=$(nproc --all)
eval systemctl start step1@{1..${cpu_cores}}.service
It's all working really nicely, with STDIN and STDOUT flowing from
start to finish and dependencies and socket creation all good for the
rest of the chain. The only outstanding issue is the second service
instance templates for socket and services.
As far as I understand:
- Socket template instances need a corresponding service instance template.
- Services need an ExecStart= or ExecStop= to be valid.
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).
Now to the question:
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
But this does not feel like the right approach.
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).
Thank you very much in advance for any insight. Is there a
systemd-users list I should use instead?
