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 <[email protected]> wrote: > On Mon, 01.05.17 13:57, Alec Taylor ([email protected]) 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 >
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
