[Feature Request] Start daemon (murmurd) without starting (virtual) servers

[toby63]

Description:
On many Distributions (Linux) the daemon (murmurd) is auto-started on system-startup.
This is intended and useful in most cases and can likely be disabled.

But in some cases people might not want the (or all) virtual servers to also auto-start.
For example if they prefer to configure the virtual servers over protocols like ICE/gRPC etc.

A config option to prevent autostart of (specific) virtual servers in the configuration files would be useful.

---

Todo:

• (see src/murmur: Added config option autostart #4241) Implement an option to not autostart all or specific virtual servers.

---

Update: The initial intended usecase can be solved in a different way, so I changed the description for a different usecase.

[streaps]

I don't know much about the murmur internals, but I did a test with my murmur server. I stopped virtual servers via murmur-cli. Then I restarted the daemon. All virtual server were running again.

I'm not convinced that it is a good solution to have murmurd running in the background when no virtual server is active, just in case the user wants to start a server.

On the other hand I think an "autostart" option would be useful (autostart=true/false). That would allow the admin to disable virtual servers and to prevent startup of specific virtual servers when murmurd is (re-) started. I'm talking about an "autostart" option in murmur.ini and the virtual server config.

What about "Start daemon without starting virtual server" for the title of this issue?

[Krzmbrzl]

I agree that having murmur running in the background doing nothing is not the best idea. Also making this the default breaks any usage of a server binary directly as this relies on the server firing up a virtual server by default.

I think it'd be easy enough though to add a CLI option to stop automatic booting of virtual servers. Is that basically what you're asking for?

[streaps]

I'm not sure that a CLI option is that useful. Wouldn't it make the setup (in Debian) even more complicated?

[Krzmbrzl]

I have no idea how the setup works in Debian. But I always thought that every way of starting an application on Linux basically allows to specify CL arguments 🤔

[toby63]

tldr: A config option in the configuration files would be best 😃.

Because the best case imo would be an option to ask the user during installation about it.
The alternative would be for the users to be able to set it themselves afterwards.
In this case I think modifying a line in a configuration file is easier than needing to modify systemd scripts.

Update:
I see that with debconf it is possible to modify configuration during installation, for Example:

wasabi:/home/fr# debconf-show apache
* apache/server-name: hoshi.homeunix.net
* apache/document-root: /var/www
* apache/server-port: 80
* apache/enable-suexec: false
* apache/init: true
* apache/server-admin: webmaster@wasabi

Also:
[...] when installing (or upgrading) any single package [...], debconf asks the packages' configuration questions [...] and stores the user/admin preferences in a database. Later as the packages are installing, their scripts use the configuration preferences in the database to generate configuration files and otherwise do administrative tasks (e.g. set up servers to start or not start, install other software such as libdvdcss, etc.).
Source: https://wiki.debian.org/debconf

So I guess the best way would be a key in the configuration files.
The rest is up to the package maintainers, they can configure debconf.

[bendem]

Can you clarify what the use case is for this? Is there an actual user asking for this or is this "in case someone ever wants this"?
You seem to imply that software is automatically started and enabled on install, that is not true for debian so the issue would be inexistant.

[streaps]

Most daemons are indeed started and enabled on install in Debian. The mumble-server package is no exception. I just installed it on Debian Buster and murmurd is running.

[bendem]

Most daemons are indeed started and enabled on install in Debian. The mumble-server package is no exception. I just installed it on Debian Buster and murmurd is running.

Ah, I guess I was thinking of another distro then.

I still don't understand why users that need a one-off instance of murmur wouldn't just disable the service and start/stop it manually though like they do with other software. And I'm still not sure how making murmurd start without provisionning a default virtual server would help with that.

[streaps]

Btw, murmur-user-wrapper is independent from the system-wide murmurd that is started by systemd.

[streaps]

@bendem I don't see the need for the use case neither. murmur-user-wrapper seems to work fine for murmurd on-demand instances started by the user. If it's not good enough / easy enough it could be improved, but it doesn't need any change in murmurd itself. Giving the user the option to disable murmurd on install is Debian specific.

I think my idea of autostart=true/false is another use case and feature request.

[toby63]

I still don't understand why users that need a one-off instance of murmur wouldn't just disable the service and start/stop it manually though like they do with other software. And I'm still not sure how making murmurd start without provisionning a default virtual server would help with that.

Well exactly this scenario (on-off with systemd and configuration files in /etc) is inconvenient.
And please don't argue with the typical nerd attitude, this is too complicated for many normal users and they maybe want to start a quick server, without logging in as root, needing to start with a systemd command and configure this and that in console editor etc.
So my solution would be a good solution, given the case that the murmur-user-wrapper is not working when the daemon is disabled.
Also related to: #4164

Btw, murmur-user-wrapper is independent from the system-wide murmurd that is started by systemd.

That was one of my questions.
If thats the case, the method with deactivating the daemon should work.
To clarify:

• You disabled and stopped the daemon
• And then you started the user-wrapper?

Giving the user the option to disable murmurd on install is Debian specific.

That is the first idea.
If the wrapper is working independently, the first idea will be applied.

[toby63]

Still starting the daemon without running virtual servers can be a good idea.
If people instead want to configure virtual servers via ICE etc. and don't want the regular server based on the murmur.ini to start.
But I don't know the technical details, maybe its to complicated.
If the murmur-wrapper is working independently you can assume this low-priority.

[streaps]

That was one of my questions.
If thats the case, the method with deactivating the daemon should work.
To clarify:

* You disabled and stopped the daemon

yes

* And then you started the user-wrapper?

yes

output from netstat:

tcp     0    0 127.0.0.1:6502          0.0.0.0:*         LISTEN      297/murmurd         
tcp6    0    0 :::64738                :::*              LISTEN      297/murmurd         
udp6    0    0 :::64738                :::*                          297/murmurd  

and ps:

test 297 ... /usr/sbin/murmurd -ini /home/test/murmur/murmur.ini

[Krzmbrzl]

I still don't see this as something we need (especially considering that we have way too few devs to work on other feature requests already).

Even if someone wants to configure their server via ICE, there's no problem whatsoever if there already is a server running when connecting to the ICE interface, 'cause you can simply shut it down again if you don't want it. Or even simpler: You go ahead and configure the server that's already running instead of explicitly starting one yourself.

As such I'll close this issue (for now)

[toby63]

I think that it can be useful.
I admit that my first idea/usecase can be solved differently, but @streaps mentioned another usecase:
If you have multiple virtual servers, everytime you start the daemon, all virtual servers are started too.
This should not necessarily be the case.
Imo thats simply a design flaw and should be fixed.
But as no one complained yet, you can assume low-priority of course.

I understand that you want to close issues, but other projects use labels like later or maybe for such cases.
I would only close issues, if they are solved, invalid, intended-behaviour ("not a bug its a feature") or wontfix.

[Krzmbrzl]

Well starting all existing servers is in fact a feature - it has been explicitly programmed that way and I think this is reasonable.

Besides: With this amount of issues and this few developers, low priority is basically the same thing as wontfix 🤷

[toby63]

I think this might be a part of the whole gRPC-topic and also related to #4164 .
Implement an option to not autostart specific virtual servers.

[Krzmbrzl]

How is that related to gRPC?

Implement an option to not autostart specific virtual servers.

I have no problem with adding it as a CLI parameter. I'm just really against this being the default behavior.

[toby63]

How is that related to gRPC?

Well the whole thing gRPC and stuff is about is virtual server management.
So how is it not related?
If you only manage one server you can do that very easily without gRPC etc., so I assume that most people use it to manage several servers.

I'm just really against this being the default behavior.

Who said something about default behaviour?
This was always about an option.

[Krzmbrzl]

Who said something about default behaviour?

@streaps did:

I'm not sure that a CLI option is that useful. Wouldn't it make the setup (in Debian) even more complicated?

and you (I thought at least) did as well:

Still starting the daemon without running virtual servers can be a good idea.

So how is it not related?

Because gRPC doesn't care about whether or not a server is already running.

[toby63]

Who said something about default behaviour?

@streaps did:

I'm not sure that a CLI option is that useful. Wouldn't it make the setup (in Debian) even more complicated?

and you (I thought at least) did as well:

Still starting the daemon without running virtual servers can be a good idea.

😕 I don't see how that can be interpreted as arguments for default behaviour.
streaps argued for a config option instead of cli.
And I just clarified that I think that an option to run a daemon without running virtual servers is still useful, even though my first usecase was solved otherwise.

So how is it not related?

Because gRPC doesn't care about whether or not a server is already running.

And?
Just because a program or protocol can work bare-metal, that means that any functionality (that is not necessary for starting) is unrelated?

I think that this option would be useful for the proper use of grpc.
Thats what I mean with "related".

[Krzmbrzl]

I think that this option would be useful for the proper use of grpc.
Thats what I mean with "related".

And I disagree. To me this sounds a bit like "You can use a pen to write something on paper. Therefore the paper should be red". Like yeah pen and paper have something to do with each other but that doesn't affect them in such a way.

Anyways - this is not the important bit here ^^

---

I don't see how that can be interpreted as arguments for default behaviour.
streaps argued for a config option instead of cli.

🤷

So the consensus here was basically that a config option would be best?

[streaps]

This was my proposal:

On the other hand I think an "autostart" option would be useful (autostart=true/false). That would allow the admin to disable virtual servers and to prevent startup of specific virtual servers when murmurd is (re-) started. I'm talking about an "autostart" option in murmur.ini and the virtual server config.

so we would have

autostart=true|false

in murmur.ini as the default value and you could change that setting for every virtual server (as usual).

But honestly, it's not that important. +1 to "With this amount of issues and this few developers, low priority is basically the same thing as wontfix"

[Krzmbrzl]

Adding a new config option is not much work at all. My argumentation against this really was because I thought you'd wanted to change the default behavior which would have required a lot of workaround to keep other stuff working.

I added the respective option (plus a bonus one) in #4233

[Krzmbrzl]

Closing in favor of #5924