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

Allow daemon to log to stdout as journald can still log the output #2591

Merged
merged 1 commit into from
Apr 2, 2021

Conversation

mtorromeo
Copy link
Contributor

@mtorromeo mtorromeo commented Mar 19, 2021

When trying to use janus within a systemd service unit, the best option is to use the forking type which means starting janus with -b to "daemonize" the process.

Even if I do this I don't want to log the process output to a file as journald is already capable of storing and timestamping the log from the process' stdout, as demonstrated by this journal logs (captured with a patched janus):

Mar 19 16:41:51 myserver systemd[1]: Starting Janus WebRTC Server...
Mar 19 16:41:51 myserver janus[1306664]: Janus commit: not-a-git-repo
Mar 19 16:41:51 myserver janus[1306664]: Compiled on:  Fri Mar 19 15:41:32 UTC 2021
Mar 19 16:41:51 myserver janus[1306664]: Running Janus as a daemon
Mar 19 16:41:51 myserver janus[1306664]: Logger plugins folder: /usr/lib64/janus/loggers
Mar 19 16:41:51 myserver janus[1306664]: [WARN]      Couldn't access logger plugins folder...
Mar 19 16:41:51 myserver janus[1306664]: ---------------------------------------------------
Mar 19 16:41:51 myserver janus[1306664]:   Starting Meetecho Janus (WebRTC Server) v0.10.10
Mar 19 16:41:51 myserver janus[1306664]: ---------------------------------------------------
Mar 19 16:41:51 myserver janus[1306664]: Checking command line arguments...
Mar 19 16:41:51 myserver janus[1306664]: Debug/log level is 4
Mar 19 16:41:51 myserver janus[1306664]: Debug/log timestamps are disabled
Mar 19 16:41:51 myserver janus[1306664]: Debug/log colors are disabled
Mar 19 16:41:51 myserver janus[1306664]: Adding 'vmnet' to the ICE ignore list...
Mar 19 16:41:51 myserver janus[1306664]: Using X.X.X.X as local IP...
Mar 19 16:41:51 myserver janus[1306664]: Token based authentication disabled
Mar 19 16:41:51 myserver janus[1306664]: Initializing recorder code
Mar 19 16:41:51 myserver janus[1306664]: Initializing ICE stuff (Full mode, ICE-TCP candidates disabled, half-trickle, IPv6 support disabled)
Mar 19 16:41:51 myserver janus[1306664]: TURN REST API backend: (disabled)
Mar 19 16:41:51 myserver janus[1306664]: Crypto: OpenSSL >= 1.1.0
...

Janus instead aborts the process lamenting the following:

Running Janus as a daemon but no log file provided, giving up...

BTW I think that I should be allowed to not log to anything if I really wanted to but this is beside the point.

@januscla
Copy link

Thanks for your contribution, @mtorromeo! Please make sure you sign our CLA, as it's a required step before we can merge this.

@mtorromeo mtorromeo force-pushed the allow-daemon-stdout branch 2 times, most recently from a9e0c30 to 4003b67 Compare March 19, 2021 15:46
@lminiero
Copy link
Member

I think this will break generic "putting into background", that is, in contexts different than yours: IIRC we had to close stdout/stderr in that case, because otherwise we would keep on printing even when put into background.

@lminiero
Copy link
Member

BTW I think that I should be allowed to not log to anything if I really wanted to but this is beside the point.

You are allowed not to log anything:

	#log_to_stdout = false					# Whether the Janus output should be written
											# to stdout or not (default=true)
	#log_to_file = "/path/to/janus.log"		# Whether to use a log file or not

If you set log_to_stdout to FALSE in janus.jcfg and don't provide any file, we won't log anything.

@mtorromeo
Copy link
Contributor Author

If you set log_to_stdout to FALSE in janus.jcfg and don't provide any file, we won't log anything.

not while demonizing, unless I'm misinterpreting something.

There's this check that blocks the process in such a situation:

	if(daemonize && logfile == NULL) {
		g_print("Running Janus as a daemon but no log file provided, giving up...\n");
		exit(1);
	}

But, that's not what I want anyway. I want to log but to the journal (via stdout or otherwise).

This is only my opinion but manually sending a process to background doesn't seem like the ideal use case, and you can always explicitly configure "log_to_stdout = false" if you need to (like in a rc.d style init script), but the current implementation doesn' allow me to explicitly use "log_to_stdout = true".

What about a flag to force outputting to stdout then?

@lminiero
Copy link
Member

What about a flag to force outputting to stdout then?

That sounds like a more acceptable solution, as it wouldn't impact existing deployments, and should give you the flexibility you need.

Re: this check,

	if(daemonize && logfile == NULL) {
		g_print("Running Janus as a daemon but no log file provided, giving up...\n");
		exit(1);
 	}

I guess it can be removed, since as you pointed out people may not want any logging at all.

@mtorromeo
Copy link
Contributor Author

Would this new implementation work for you?

Copy link
Member

@lminiero lminiero left a comment

Choose a reason for hiding this comment

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

Much more compact, thanks! I added a few notes inline.

janus.ggo Outdated
@@ -2,6 +2,7 @@
option "daemon" b "Launch Janus in background as a daemon" flag off
option "pid-file" p "Open the specified PID file when starting Janus (default=none)" string typestr="path" optional
option "disable-stdout" N "Disable stdout based logging" flag off
option "log-stdout" - "Log to stdout" flag off
Copy link
Member

Choose a reason for hiding this comment

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

Not sure that - is the right one-char shortcut here: wouldn't it be confused with what - usually stands for in scripts and applications? Of course, I do realize almost all letters of the alphabet are gone, we used too many 😄

A couple of side notes:

  • For each command-line property there should be a janus.jcfg equivalent
  • New command line properties should be documented in janus.1 (the man file) and added to the summary in the README as well

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure that - is the right one-char shortcut here

- means "no short option". Quoting the info page of gengetopt:

'short'

     The short option, a single upper or lower case char, or a digit.
     If a '-' is specified, then no short option is considered for the
     long option (thus long options with no associated short options are
     allowed).  Since version 2.22 you can also specify '?' as the short
     option.

For each command-line property there should be a janus.jcfg equivalent

There is already a log_to_stdout options in janus.jcfg but it defaults to true while the command line flag defaults to false. This issue exists only because I had to preserve the current behaviour where daemonize would disable stdout even if log_to_stdout was set to true.

Should I just rename the command line flag to --log-to-stdout instead of --log-stdout and leave everything else as-is?

Copy link
Member

@lminiero lminiero Apr 1, 2021

Choose a reason for hiding this comment

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

- means "no short option". Quoting the info page of gengetopt:

Ah thanks for the heads up, I didn't know about that!

There is already a log_to_stdout options in janus.jcfg but it defaults to true while the command line flag defaults to false. This issue exists only because I had to preserve the current behaviour where daemonize would disable stdout even if log_to_stdout was set to true.

In that case I think it may be worth making it clearer in the description of the property should that this is a way to make sure stdout remains alive even, or especially, when demonizing (since that's basically the only thing it's used for). The "Log to stdout" text doesn't make that clear enough IMO.

Should I just rename the command line flag to --log-to-stdout instead of --log-stdout and leave everything else as-is?

Makes sense!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did change the --log-stdout flag to --log-to-stdout in the end. That's because the analogous configuration log_to_file has the matching flag --log-file and I think it makes sense to keep it consistent.

Copy link
Member

@lminiero lminiero Apr 2, 2021

Choose a reason for hiding this comment

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

Are you sure the right changes were pushed? I still see the old name. Besides I see the updated description in the man-file, but not in the .ggo one?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's what I was explaining.

I thought that changing --log-stdout to --log-to-stdout was not consistent with --log-file that is NOT named --log-to-file despite its configuration option being log_to_file.

So I did NOT change anything here. Do you still want to rename it even in light of this argument?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, maybe you were referring to the description and not the name. I just pushed the update for that as well.

Copy link
Member

Choose a reason for hiding this comment

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

Do you still want to rename it even in light of this argument?

No, I'm fine with that. I asked because you wrote:

I did change the --log-stdout flag to --log-to-stdout in the end.

but the name was still the old one. Did you mean "I didn't change... in the end"?
Description looks good, thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Did you mean "I didn't change... in the end"?

Oh, yeah, didn't notice the typo. Sorry about that.

Comment on lines +29 to +31
.BR \-L ", " \-\-log-stdout
Log to stdout, even when the process is daemonized (default=off)
.TP
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@lminiero Is this description good enough?

@lminiero
Copy link
Member

lminiero commented Apr 2, 2021

Changes look fine to me! If you can confirm it now addresses your requirement, it's good to merge for me 👍

@mtorromeo
Copy link
Contributor Author

Yes, the patch has been tested and works as intended

@mtorromeo
Copy link
Contributor Author

For context, this is the systemd service file I am using:

[Unit]
Description=Janus WebRTC Server
Documentation=https://janus.conf.meetecho.com/
After=network.target

[Service]
Type=forking
User=janus
ExecStart=/usr/bin/janus -ob --log-stdout
Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

@lminiero
Copy link
Member

lminiero commented Apr 2, 2021

Merging then, thanks!

@lminiero lminiero merged commit 4dd379a into meetecho:master Apr 2, 2021
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.

None yet

3 participants