FAQ
Thanks, Rodrigo, it is definitely a solution for linux environments where
the owner of the service is only one, when there is only one running copy
of the server.

But this tool is for personal usage, several users on the same machine
should be able to start their respective servers. That's why the domain
socket would be in their $HOME's.

On Mon, Mar 17, 2014 at 7:06 PM, Rodrigo Kochenburger wrote:

If you're on a systemd-based linux you could rely on systemd's socket
activation:
http://www.freedesktop.org/software/systemd/man/systemd.socket.html

- RK


On Mon, Mar 17, 2014 at 8:54 AM, Daniel Fanjul <
daniel.fanjul.alcuten@gmail.com> wrote:
Hi gophers,

I am considering a client server tool for personal usage. The client and
the server would communicate with a domain socket in $HOME, the server
would not need any options to boot, the client would be a command line tool
that would connect, interchange some data and die; and the server would run
indefinitely. The problem: I would like the client to boot the server if it
is not running.

In C, I would do something like this when the connection fails:

- the client opens the server socket.
- the client connects to itself, opens the client socket.
- the client forks.
- the child becomes the server, closes the client socket descriptor,
detaches from tty, manages signals like SIGHUP.
- the parent becomes the client, closes the server socket descriptor.
- the parent eventually dies and the child continues in background.

I don't know how to fork and manage the (file) descriptors in that way in
go. Or if there are higher level solutions without race conditions. I would
prefer to avoid using os/exec.Command() because I would need to know the
path to the executable. I would prefer to avoid the low level syscall
package.

The problem seems hard enough to not implement this feature at all, but I
would like to know the best alternatives in go anyway.

Thanks,
Daniel.



--
Daniel Fanjul Alcutén
Tools Engineer @Spotify AB
https://github.com/daniel-fanjul-alcuten

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Daniel Fanjul Alcutén
Tools Engineer @Spotify AB
https://github.com/daniel-fanjul-alcuten

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 5 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 17, '14 at 3:54p
activeMar 17, '14 at 7:40p
posts5
users2
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase