FAQ
Because the server will typically receive connections from only clients of
the same user, not from other people's.
For example, tools like task
spooler<http://vicerveza.homeunix.net/~viric/soft/ts/>,
moosic <http://www.nanoo.org/software/moosic/>, ssh
agent<http://en.wikipedia.org/wiki/Ssh-agent>,
and probably many more.

Actually task spooler and moosic are able to start the server if it is not
running.

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

I don't mean to questionm your implementation but just out of the
curiosity, why do a client/server architecture if each user will be running
their own server?

- RK


On Mon, Mar 17, 2014 at 11:38 AM, Daniel Fanjul <
daniel.fanjul.alcuten@gmail.com> wrote:
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

--
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

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 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