Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support running on demand via systemd #151

Merged
merged 1 commit into from
Aug 17, 2021
Merged

Support running on demand via systemd #151

merged 1 commit into from
Aug 17, 2021

Conversation

fd0
Copy link
Member

@fd0 fd0 commented Aug 9, 2021

What is the purpose of this change? What does it change?

This change allows rest-server to be run on demand by systemd (socket activation). The rationale for supporting both is as follows:

  1. On demand running with a listening socket opened externally is a good idea because then rest-server does not have to have the privileges to listen on a port.
  2. My first choice for that would be systemd (so the process can even be restricted further), but it is not available for non-Linux systems

Was the change discussed in an issue or in the forum before?

Closes #126
Supersedes #127

Checklist

  • I have enabled maintainer edits for this PR
  • There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
  • I have run gofmt on the code in all commits
  • All commit messages are formatted in the same style as the other commits in the repo
  • I'm done, this Pull Request is ready for review

panic(err)
}

switch len(listeners) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps make the systemd socket activation explicit with a --systemd switch?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you think that's needed? We can discover (from the environment) if we're run via systemd socket activation...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case you will end up ignoring the address configuration and using systemd instead, which could surprise the user. Adding a --systemd flag also makes clear that some magic is happening here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, rest-server does log that it is in systemd mode, so I guess this is fine,

// findListener creates a listener.
func findListener(inetd bool, addr string) (listener net.Listener, err error) {
if inetd {
log.Print("inetd mode activated")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this even work on windows?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Via cygwin maybe? Or WSL? It compiled, so I left it there...

Copy link
Contributor

@wojas wojas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@fd0 fd0 changed the title Support running on demand via inetd and systemd Support running on demand via systemd Aug 17, 2021
@fd0
Copy link
Member Author

fd0 commented Aug 17, 2021

inetd mode is off: #126 (comment)

@fd0 fd0 force-pushed the add-socket-activation branch 2 times, most recently from 6921484 to 0f90ebf Compare August 17, 2021 19:32
@fd0 fd0 merged commit d2813ea into master Aug 17, 2021
@fd0 fd0 deleted the add-socket-activation branch August 17, 2021 19:39
//
// systemd-socket-activate -l 8080 ./rest-server
log.Printf("systemd socket activation mode")
return listeners[0], nil
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure who should do the check, but if the environmental flags don't match the passed in file descriptors, listerners[0] can be nil here and result in a panic later. Not a very nice to debug.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking that listeners[0] is valid is probably a good idea before returning it. The expected behavior of findListener is that it either returns a listening socket or an error. Returning nil is thus wrong. Would you be willing to open a PR to check that listeners[0] != nil?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've opened coreos/go-systemd#405 for now, let's see if they are willing to fix the condition on their end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support starting rest-server from inetd and similar services
4 participants