systemd unit file?

[fattywompus]

 

Is there a reason murmur uses init.d rather than a systemd unit file?  And if I were to try to convert from init.d to run from a systemd unit file would that cause any unforeseen issues?  It runs fine as is using systemctl so not really any high priority reason other than everything else I'm playing with on my server so far is using unit files, and it would seem convenient to have all my service files the same type and in one place.  Also I'm still a bit new to running a server and messing with service files so it would be a learning exercise. 

If it is feasible, I'm running ubuntu server 20.04 LTS but some investigation has led me to guides on installing murmur on CentOS, which include setting up a unit file:
https://robido.com/server-admin/install-and-setup-a-mumble-server-on-centos-7/
Would it be reasonable to follow such a guide just adapting the file locations and whatnot?

Any thoughts on the subject welcome and thanks in advance.

 

[davidebeatrici]

We actually provide a systemd file, but it's affected by a problem that is being fixed in https://github.com/mumble-voip/mumble/pull/4619.

The official package for Ubuntu uses the init.d script wrapped by systemd-sysv-generator.

Edited December 9, 2020 by davidebeatrici

[fattywompus]

Thanks for the quick and to the point answer.  So it looks like that was being worked on as we spoke and a new unit file has been accepted.  Guessing it may take a bit to make it's way to the PPA, so is there any hope of using it in the mean time?  I dabbled a bit creating a murmur.service file and pasted in the contents of the newly finished one.  Noticed it was referencing /etc/murmur.ini rather than the /etc/mumble-server.ini the wrapper was using so just for the sake of curiosity I made a copy of mumble-server.ini, named it murmur.ini, and tried running "systemctl start murmur" which failed with (code=exited, status=203/EXEC) which led me to look for /usr/bin/murmurd which didn't exist.  Instead we have /usr/bin/murmur-user-wrapper...  I'm a bit out of my depth but any possibility if I had the actual murmurd it would run?  Or does this change require a lot more than I realize?

Edited December 10, 2020 by fattywompus
forgot to say thanks

[davidebeatrici]

No problem, I just merged the pull request.

Changing the paths should be enough for the systemd file to work.

/usr/bin/murmur-user-wrapper is used to run the server as user. The binary can be found at /usr/sbin/murmurd, because it's supposed to be launched as root.

[fattywompus]

Excellent!  Made the change to the path in the unit file and systemctl status reports active (running) so we appear to be in business.  I connected with the SuperUser account from my laptop (on the same LAN) which is where I left off with setting things up (about to create an admin account to manage things from, not intending to use the SuperUser account regularly) before getting side tracked with this systemd business.  And that connection showed in the systemctl status.   

If I could trouble you with one last thing, I'm curious although it seems to be good with what limited testing I can do at the moment, what is the "disabled" referencing in this line in systemctl status?

Loaded: loaded (/lib/systemd/system/murmur.service; disabled; vendor preset: enabled)

And thanks once again for help!

[davidebeatrici]

You're welcome!

disabled indicates that the service doesn't start automatically. You can enable it with sudo systemctl enable murmur.