janus: add systemd unit file

[saghul]

No description provided.

[ploxiln]

Perhaps there should be a "contrib" or "init" folder with stuff like this. (I'd also not add too much systemd basics to the janus-gateway README, maybe just a link to a good reference)

[saghul]

Do you have any concrete suggestion? I personally don't foresee many more contributed init files, for better or worse systemd is the standard and it's here to stay. I'd address that if we need to.

Debian and Ubuntu only have systemd support on their latest release, so putting the most basic instructions on the README (just the necessary to get started) didn't sound like a bad idea to me.

[lminiero]

Please not in the README... we can add a new page in mainpage.dox for that.
PS: will you let me enjoy my vacation or are you going to create pull requests the whole month?? 😄

[saghul]

Please not in the README... we can add a new page in mainpage.dox for that.

I don't mind removing the README part, though I still think it could help people, mainpage.dox is not that accessible, the README is the first thing a user sees.

PS: will you let me enjoy my vacation or are you going to create pull requests the whole month?? 😄

Just a couple more 😎

[saghul]

Dropped the README changes.

[ploxiln]

The current LTS release of ubuntu, which is pretty popular, uses "upstart". Some people run janus under docker instead of their init system. If you wanted examples of alternatives :)

[willbarrett]

We use Upstart for a parent management process. That management process handles keeping Janus online and translating messages for the rest of our systems. There are a number of different solutions here.

[saghul]

Feel free to send a Pull Request with a different init file, right now
there is just one open (this one), so I'd rather take care of a problem
when it actually manifests ;-)
On Aug 10, 2015 8:06 PM, "Will Barrett" notifications@github.com wrote:

We use Upstart for a parent management process. That management process
handles keeping Janus online and translating messages for the rest of our
systems. There are a number of different solutions here.

—
Reply to this email directly or view it on GitHub
#306 (comment)
.

[lminiero]

Considering the feedback, I'm even more convinced I'd rather have this as part of the documentation instead of having a separate folder/file. I'm thinking of an ad-hoc page like the one we have for the different ways of deploying Janus behind web servers:

http://janus.conf.meetecho.com/docs/deploy.html

a new page that might contain info on the different approaches you listed. Especially if the init file is so small (~12 lines, IIRC from Twitter) I see no harm in having it listed in a documentation file as an example users can refer to, which is what most OS projects do anyway. I don't consider the fact people are more willing to read the README a pro, actually: I'd instead very much encourage people to check the documentation (RTFM 😄 ), as otherwise I end up writing the same responses over and over on the group/issues, which is what happens more than I'd like. What can be added to the README is some stronger statement about the fact most of the info is in the docs, something that's probably lacking as of now.

I can take care of preparing this documentation when I get back from my vacation, starting from the effort @saghul contributed. @ploxiln @willbarrett if you guys have anything you're willing to share about the way you did things, I'll add the info to the same page.

[saghul]

@lminiero Thanks for taking the time to reply. FWIW, I don't need this to be in the Janus repo, as I have it as part of a Debian package. I thought that it would be useful for others, that's why I shared it.

Ping me when you have the skeleton for the deployment section and I can add something to it, at least the systemd part.

I still find it much more useful to have these file(s) in file form rather than embedded in the docs, but that's your call to make.

[willbarrett]

Ping me as well - when you're ready. I'm happy to provide a sample Upstart file.

[lminiero]

Hi guys, I just prepared a first version of the page I mentioned. You can see a live image here:

http://janus.conf.meetecho.com/docs/service.html

Any feedback is more than welcome! The systemd section is admittedly a bit lacking, so if you have any additional text for it, that would be great @saghul 😃

@ploxiln @willbarrett same as to the upstart info guys, if you have any sample/text to share I'll be happy to add it there (with the proper acknowledgments, of course).

[ploxiln]

I can offer an upstart file (typically copied to /etc/init/janus.conf):

description "janus"

start on filesystem or runlevel [2345]
stop on runlevel [!2345]
limit nofile 50000 50000
limit core unlimited unlimited

respawn
respawn limit 10 5

exec /opt/janus/bin/janus

Admittedly, I don't use this anymore, as I use docker for running janus now.

(EDIT: also, just for the record, no need for acknowledgement for this snippet)

[willbarrett]

@ploxiln's solution looks good to me. Pretty much matches what we do.

[lminiero]

Thanks guys, I'll add this to the documentation later today.

[keller00]

Just tried adding it to systemd today on Ubuntu 16.04, I had to add these to the unit file, otherwise DNS lookup failed to the stun server:

After=network-online.target

Want=network-online.target

[jj7112]

I confirm the "network.target" is non existent in /etc/systemd/system/, probably name change since the original commit.
In linux distros like Ubuntu 20.x, Debian 10.x, 9.x
the following is needed/working:

After=network-online.target
Wants=network-online.target

[vincentfretin]

I just did some search and found https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ that explains the difference between network.target and network-online.target:

• network.target is a passive unit, that's probably why there is no file, "It only indicates that the network management stack is up after it has been reached. Whether any network interfaces are already configured when it is reached is undefined."
• network-online.target: "is a target that actively waits until the nework is "up", where the definition of "up" is defined by the network management software. Usually it indicates a configured, routable IP address of some kind"