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

Search Discussions

  • Rodrigo Kochenburger at Mar 17, 2014 at 6:06 pm
    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 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.
    --
    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 at Mar 17, 2014 at 6:38 pm
    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.
  • Rodrigo Kochenburger at Mar 17, 2014 at 6:42 pm
    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 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
    --
    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 at Mar 17, 2014 at 7:40 pm
    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.

Related Discussions

Discussion Navigation
viewthread | post
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