[systemd-devel] [systemd.service] TCP listen port conflict resolution / explicit erring?

[Alec Taylor]

Hmm, maybe I'll chuck:
X-Listen-Port
X-Listen-Name

On all the generated SystemD units.

Okay, will rewrite to use .socket files. Is there a trick to overcoming the
PATH issue which avoids launching bash?

On Tue, May 2, 2017 at 10:11 PM, Lennart Poettering <lennart at poettering.net>
wrote:

> On Mon, 01.05.17 13:57, Alec Taylor (alec.taylor6 at gmail.com) wrote:
>
> > Wrote some scripts to generate systemd .service files and start-up those
> > services.
> >
> > Currently just for some REST APIs, but soon will include distributed
> > systems also.
> >
> > I set the TCP listen port variable that is used by my .service like so:
> > `Environment=PORT=4200`
> >
> > To get PATH to work nicely, my `ExecStart` begins with:
> > /bin/bash -c 'PATH=bash -c PATH=$PREPEND_PATH:$PATH
> >
> > (would appreciate an alternative to launching a new shell there also!)
> >
> >
> >
> > *Is there a systemd trick of explicitly erring on TCP listen-port
> > conflicts?*
> > And/or should I just write a parser that loops through all .service's and
> > checks the `PORT=` and raises on conflict?
>
> No, systemd can't do that for you. And even if it did, this would be
> awfully racy as in the time between such a check and the service
> trying to ultimately bind() to it something else might already have
> taken it.
>
> I'd generally recommend using socket activation for this, i.e. the
> ".socket" unit type systemd provides. This howver requires explicit
> support in the relevant daemons. Many daemons do support that scheme
> out-of-the-box now, but the majority probably does not.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170504/b2df9aed/attachment-0001.html>