Welcome file locations limited when used in systemctl

[mcfnord]

I use -w or --welcomemessage with a filename at CLI like this:

jamulus-headless --nogui --server --directoryserver anygenre1.jamulus.io:22124 --serverinfo "Hear;California;US" -u 6 -w /root/welc.html

That shows the welc.html file contents when I connect.

But then I run jamulus-headless using systemctl, starting with this:

sudo systemctl edit --full jamulus-headless

I made this line:

ExecStart=/bin/sh -c 'exec /usr/bin/jamulus-headless --nogui --server --directoryserver anygenre1.jamulus.io:22124 --serverinfo "Hear;California;US" -u 6 -w /root/welc.html'

When I connect to that server, I see this:

Server Welcome Message: /root/welc.html

Oh no, that's the path, not the file contents. Is it possible to specify a full path here, and see the file contents? The syntax from CLI to systemctl sure looks the same to me.

(I want to call systemctl reload jamulus-headless to re-cache the welcome message from the file, to deliver hot new dynamic features crowds love, but instead, the file path is treated as a literal.)

[ann0see]

I'd remove the /bin/sh -c exec part.
I'm quite sure it's an error in bash/sh not Jamulus

[mcfnord]

This also does same:

ExecStart=/usr/bin/jamulus-headless --nogui --server --directoryserver anygenre1.jamulus.io:22124 --serverinfo "Hear;California;US" -u 6 -w /root/welc.html

I imagine the same Jamulus code that gets a path when called from the user bash prompt also gets a path when systemctl runs ExecStart. I couldn't quite find evidence that ExecStart changes anything, but it must.

What if I kill the jamulus-headless process, and re-spawn it? That would re-cache the welcome message in the file. Would this be seamless to connections? Maybe a second of dropout?

[ann0see]

I don't know the code and especially not much about systemd. Does the systemd manual give any hints on how the ExecStart line is run?

[mcfnord]

This didn't clarify, and ChatGPT insisted nothing happens to the params ("It's important to note that systemd does not add or modify quotes automatically. It treats the ExecStart directive as a single string and passes it as-is to the shell for execution. If you need to use quotes for your command or arguments, you need to include them explicitly in the ExecStart directive.").

[ann0see]

Each command line is split on whitespace, with the first item being the command to execute, and the subsequent items being the arguments. Double quotes ("...") and single quotes ('...') may be used, in which case everything until the next matching quote becomes part of the same argument. Quotes themselves are removed after parsing. In addition, a trailing backslash ("") may be used to merge lines. This syntax is intended to be very similar to shell syntax, but only the meta-characters and expansions described in the following paragraphs are understood. Specifically, redirection using "<", "<<", ">", and ">>", pipes using "|", and running programs in the background using "&" and other elements of shell syntax are not supported.

I don't think that ChatGPT is correct - that's from the link you provided

What happens if you move the --serverinfo to the end?

[mcfnord]

Yeah, that's how quotes are handled, so a param can contain spaces. Moving --serverinfo changed nothing. I wonder what Jamulus has to receive differently in order to behave differently. It's parsing the param and saying, "Nope, that's not a path."

[mcfnord]

Because my --servinfo contains no spaces, I removed the quotes, but nothing changed.

ExecStart=/usr/bin/jamulus-headless --nogui --server --directoryserver anygenre1.jamulus.io:22124 -u 6 -w /root/welc.html --serverinfo Hear;California;US

[ann0see]

The code is here:

jamulus/src/server.cpp

Lines 204 to 215 in 068bfbc

	SetWelcomeMessage ( strNewWelcomeMessage ); // first use given text, may be overwritten
	if ( QFileInfo ( strNewWelcomeMessage ).exists() )
	{
	QFile file ( strNewWelcomeMessage );
	if ( file.open ( QIODevice::ReadOnly | QIODevice::Text ) )
	{
	// use entire file content for the welcome message
	SetWelcomeMessage ( file.readAll() );
	}
	}

Maybe systemd doesn't have permissions to read/write to that location or you have some kind of sandbox/blocking/...

[mcfnord]

I relocated the file from /root/welc.html to /welc.html, and that fixes it!

Not sure why. --edit sets user jamulus to own the process, but i changed that to root, and still failed. I think ProtectSystem=no might help here. I don't mind writing to / ! But I'll still have to systemctl restart jamulus-headless to load the new file. This interrupts service for half a second, but also shows the new welcome message to everyone. So if I do that hourly, it's not a big deal, and everyone will see it.

[ann0see]

Half a second is quite a thing still. Would JSON-RPC somehow help in your setting?

[mcfnord]

jamulusclient/sendChatText is pretty close, with no service dropout. I do like having a welcome message that changes, because welcome message reaches everyone who arrives later, but it's kind of a minor feature. I'd rather use a global model where I reach people on nearly any server, so I'm proceeding with that idea.

I do think the -w reference should address the apparent limitations of where the welcome message can appear. I almost understood: systemctl runs the process as user jamulus, which cannot see /root, and also probably doesn't have its own /home/jamulus path, because it's not an interactive user account. There may be differences on different Linux platforms, but maybe we should recommend locating the full path in /welc.html. (I haven't built next-release branch into HTML reliably so I don't create PRs for it.) I did not see any other params that follow this pattern of fullpath-if-openable.

[ann0see]

I think putting the file in / is messy. So I'd rather create a folder owned by the jamulus user in e.g a folder like /etc/jamulus