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

Michal Koutný mkoutny at suse.com
Thu Nov 3 18:31:30 UTC 2022


Hello.

On Fri, Oct 28, 2022 at 12:39:01PM +0200, Simon Mullis <simon at mullis.co.uk> wrote:
> Step 0
> - service_data_gen => creates N outputs
> 
> Step 1
> - service1 at .service => N instances are created but don't actually need
> to do anything.
> - service1 at .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 at .socket (==service1 at .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 at .socket would trigger step1 at .service and it'd do job that your
current step2 at .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 at .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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: Digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20221103/16bb5267/attachment.sig>


More information about the systemd-devel mailing list