[GH-ISSUE #34] systemd socket activation #12

New issue

Closed

opened 2026-03-13 15:21:08 +03:00 by kerem · 1 comment

kerem commented

2026-03-13 15:21:08 +03:00

Owner

Originally created by @logic on GitHub (Jan 22, 2018).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/34

systemd provides socket activation as an option for listening services, and is particularly handy for services that listen on privileged ports. It would be useful to be able to operate a very infrequently-accessed service like this via on-demand activation.

It looks like miekg/dns already supports socket activation via ActivateAndServe (analogous to ListenAndServe), and coreos/go-systemd provides a handy activation abstraction.

(And because you can configure multiple listeners, it would be easy to also grab the listener for HTTP from systemd as well.)

Originally created by @logic on GitHub (Jan 22, 2018). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/34 systemd provides socket activation as an option for listening services, and is particularly handy for services that listen on privileged ports. It would be useful to be able to operate a very infrequently-accessed service like this via on-demand activation. It looks like [miekg/dns](https://github.com/miekg/dns) already supports socket activation via `ActivateAndServe` (analogous to `ListenAndServe`), and [coreos/go-systemd](https://github.com/coreos/go-systemd) provides a handy activation abstraction. (And because you can configure multiple listeners, it would be easy to also grab the listener for HTTP from systemd as well.)

kerem

2026-03-13 15:21:08 +03:00

closed this issue
added the
feature request
label

kerem commented

2026-03-13 15:21:24 +03:00

Author

Owner

@joohoi commented on GitHub (Jan 25, 2018):

This looks interesting, however I'd be a bit careful to implement (at least as a default) things that are very dependent on the users systemd configuration. It's different, of course, when and if this would be packaged for certain distributions, allowing automatic setup of such systemd features.

This is the first time I read of such feature. Could you elaborate the impact and usefulness? I think I'm missing something, but if the service(s) would be activated upon incoming connection, all I can see is a slight overhead in the initial connection. Acme-dns doesn't reserve too much of resources currently, so I don't see an immediate need for this. But as said, I'm new to the feature so please correct me as I obviously have something wrong here.

@joohoi commented on GitHub (Jan 25, 2018): This looks interesting, however I'd be a bit careful to implement (at least as a default) things that are very dependent on the users systemd configuration. It's different, of course, when and if this would be packaged for certain distributions, allowing automatic setup of such systemd features. This is the first time I read of such feature. Could you elaborate the impact and usefulness? I think I'm missing something, but if the service(s) would be activated upon incoming connection, all I can see is a slight overhead in the initial connection. Acme-dns doesn't reserve too much of resources currently, so I don't see an immediate need for this. But as said, I'm new to the feature so please correct me as I obviously have something wrong here.

kerem referenced this issue

2026-03-13 16:13:19 +03:00

[PR #12] [MERGED] Update README json examples. #246