Hi Sylvain, Am Montag, dem 25.03.2024 um 18:48 +0100 schrieb Sylvain Rochet: > Hi Markus, > > On Mon, Mar 25, 2024 at 02:36:59AM +0100, Markus Koschany wrote: > > Sylvain Rochet wrote: > > > Actually, the main problem is /lib/systemd/system/monopd.socket which > > > set Accept=yes while monopd needs Accept=no (which is the default value). > > > > I wonder if monopd needs a systemd socket file at all and if we should > > disable the service after the installation. We have been using this > > setting since the introduction of systemd. If monopd runs with > > Accept=no then we also don't need a service template file. At some > > point I also noticed the same warning as Shriram > > > > "monopd.socket is a disabled or a static unit not running, not > > starting it." and then followed [1] and added the required template > > file. > > Yeah, socket activation is not really useful for public servers > services, it is mostly used for local services that can be spawned on > the fly later. Furthermore, socket activation breaks monopd metaserver > registration because the daemon must be running to register, so better > only ship the service file. I let you decide whether the service should > be disabled or enabled by default (but unless something recently > changed, daemon usually runs by default on Debian. I admit having lost > track :D).
Our Policy is still to enable autostarting a service but I also don't see a must directive in 9.3.3.1 [1], so if there is a good reason it should be OK to disable the service and let the local administrator re-enable it, if desired. > > I have been running monopd for the past decade and I also suspect the > > daemon is affected by some bugs which might be remotely exploitable. > > What makes you think that? > > My daemon is running attached to gdb so I can easily catch and trace any > issue that would kill the process. So far it's been over 10 years > without a single issue, some process lived for several years between > systems reboot. > > I am not saying it is bug free because nothing is bug free, but if it is > remotely exploitable and actively exploited, I would be aware of it on > my running instance. I have seen multiple lines like that in my log files before: monopd.service: main process exited, code=killed, status=11/SEGV It happens from time to time but at some time it was more frequent which made me believe that some players found a way to reproducibly crash the server. I can send you my log file but you probably can't easily debug the problem because there was no gdb attached to the process. > > Since users usually don't need the monopd server anyway, if they want > > to play a game, they should make a conscious decision to start it if > > they want to use it locally. For a simple internet game, the daemon is > > not required. > > Installing the server package isn't already a conscious decision? As this bug report proves, normal people tend to have problems with system services. A system administrator would have simply disabled or masked the service. There is nothing here what could not have been resolved with some systemctl commands. However I believe I just remove the systemd socket file now and be done with it. There are pros and cons for autostarting the service or disabling it but we don't need to overthink this. Regards, Markus
signature.asc
Description: This is a digitally signed message part
