Bug#1066983: monopd: Fails to start monopd.service

[Markus Koschany]

Hello Shriram,

Am Mittwoch, dem 27.03.2024 um 15:10 +0530 schrieb Shriram Ravindranathan:
> Dear Markus,
> 
> On 27/03/24 13:01, Markus Koschany wrote:
> > 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.
> I am sorry but I don't understand the point you are trying to make here. 
> I don't think it is in the right spirit that we should expect anybody 
> (even sysadmins) to bodge the package somehow and get it to work.
> 

The package is not broken and the bug severity is incorrect. Sylvain already
explained what you could have done with systemctl to solve this issue. 


signature.asc
Description: This is a digitally signed message part

Bug#1066983: monopd: Fails to start monopd.service

[Shriram Ravindranathan]

Dear Markus,

On 27/03/24 13:01, Markus Koschany wrote:

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.
I am sorry but I don't understand the point you are trying to make here. 
I don't think it is in the right spirit that we should expect anybody 
(even sysadmins) to bodge the package somehow and get it to work.

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.

I think that would be great. Thank you so much.

Best Regards,

--
Shriram Ravindranathan



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066983: monopd: Fails to start monopd.service

[Markus Koschany]

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

Bug#1066983: monopd: Fails to start monopd.service

[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).


> 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.


> 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?


Kind regards,
Sylvain


signature.asc
Description: Digital signature

Bug#1066983: monopd: Fails to start monopd.service

[Markus Koschany]

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.

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. 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.

[1] https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html


signature.asc
Description: This is a digitally signed message part

Bug#1066983: monopd: Fails to start monopd.service

[Sylvain Rochet]

Hi,

On Sat, Mar 23, 2024 at 09:35:38PM +0100, Sylvain Rochet wrote:
> 
> That might be related to the latest change "Add a service template for 
> compatibility reasons with monopd.socket.".

Actually, the main problem is /lib/systemd/system/monopd.socket which 
set Accept=yes while monopd needs Accept=no (which is the default value).

By the way, I just released monopd 0.10.3 that detect this 
misconfiguration and exit instead of spinning forever over accept() :)

Sylvain


signature.asc
Description: Digital signature

Bug#1066983: monopd: Fails to start monopd.service

[Shriram Ravindranathan]

Hi Sylvain,

Thanks! I am able to use the application now with socket masking. I also 
downloaded the previous version 
(0.10.2-5) 
and that also seems to be working out of the box, albeit with one warning.


```
Setting up monopd (0.10.2-5) ...
monopd.socket is a disabled or a static unit not running, not starting it.
```

On 24/03/24 02:05, Sylvain Rochet wrote:

Hi Shriram,

That might be related to the latest change "Add a service template for
compatibility reasons with monopd.socket.".

Masking socket activation and enabling the service worked for me:

# systemctl stop monopd@*.service
# systemctl stop system-monopd.slice
# systemctl stop monopd.socket
# systemctl mask monopd.socket
# systemctl enable monopd.service
# systemctl start monopd.service

Kind regards,
Sylvain


Regards,

--
Shriram Ravindranathan



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066983: monopd: Fails to start monopd.service

[Sylvain Rochet]

Hi Shriram,

On Sat, Mar 16, 2024 at 08:03:02PM +0530, Shriram Ravindranathan wrote:
> Package: monopd
> Version: 0.10.2-6+b2
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: s...@ters.dev
> 
> Dear Maintainer,
> 
> monopd.service fails to start (could not bind port 1234), rendering the 
> package unusable.
> 
> Mar 16 19:25:02 think182 sudo[4410]:  shriram : TTY=pts/0 ; PWD=/home/shriram 
> ; USER=root ; COMMAND=/usr/bin/apt install monopd
> Mar 16 19:25:02 think182 sudo[4410]: pam_unix(sudo:session): session opened 
> for user root(uid=0) by (uid=1000)
> Mar 16 19:25:03 think182 systemd[1]: Reloading.
> Mar 16 19:25:04 think182 systemd[1]: Reloading.
> Mar 16 19:25:04 think182 systemd[1]: Starting monopd.service - game server 
> for board games like GtkAtlantic...
> Mar 16 19:25:04 think182 systemd[1]: Listening on monopd.socket - monopd 
> listening socket.
> Mar 16 19:25:04 think182 monopd[4512]: monopd 0.10.2 started
> Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: 
> game=[Atlantic]
> Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: 
> game=[Monopoly]
> Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed to parse ERRNO= 
> field value '-2' in notification message: Numerical result out of range
> Mar 16 19:25:04 think182 monopd[4512]: could not bind port 1234, exiting
> Mar 16 19:25:04 think182 systemd[1]: monopd.service: Main process exited, 
> code=exited, status=254/n/a
> Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed with result 
> 'exit-code'.
> Mar 16 19:25:04 think182 systemd[1]: Failed to start monopd.service - game 
> server for board games like GtkAtlantic.
> Mar 16 19:25:05 think182 sudo[4410]: pam_unix(sudo:session): session closed 
> for user root

That might be related to the latest change "Add a service template for 
compatibility reasons with monopd.socket.".

Masking socket activation and enabling the service worked for me:

# systemctl stop monopd@*.service
# systemctl stop system-monopd.slice
# systemctl stop monopd.socket
# systemctl mask monopd.socket
# systemctl enable monopd.service
# systemctl start monopd.service

Kind regards,
Sylvain


signature.asc
Description: Digital signature

Bug#1066983: monopd: Fails to start monopd.service

[Shriram Ravindranathan]

Package: monopd
Version: 0.10.2-6+b2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: s...@ters.dev

Dear Maintainer,

monopd.service fails to start (could not bind port 1234), rendering the package 
unusable.

Here is the lsof output after the package is installed:
systemd  1root   47u  IPv6 198704  0t0  TCP *:1234 (LISTEN)
exim4 1116 Debian-exim4u  IPv4  20710  0t0  TCP 127.0.0.1:25 
(LISTEN)
exim4 1116 Debian-exim5u  IPv6  20711  0t0  TCP [::1]:25 (LISTEN)

This was on a fresh install of bookworm. Here are the journalctl logs:

Mar 16 19:25:02 think182 sudo[4410]:  shriram : TTY=pts/0 ; PWD=/home/shriram ; 
USER=root ; COMMAND=/usr/bin/apt install monopd
Mar 16 19:25:02 think182 sudo[4410]: pam_unix(sudo:session): session opened for 
user root(uid=0) by (uid=1000)
Mar 16 19:25:03 think182 systemd[1]: Reloading.
Mar 16 19:25:04 think182 systemd[1]: Reloading.
Mar 16 19:25:04 think182 systemd[1]: Starting monopd.service - game server for 
board games like GtkAtlantic...
Mar 16 19:25:04 think182 systemd[1]: Listening on monopd.socket - monopd 
listening socket.
Mar 16 19:25:04 think182 monopd[4512]: monopd 0.10.2 started
Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: 
game=[Atlantic]
Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: 
game=[Monopoly]
Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed to parse ERRNO= 
field value '-2' in notification message: Numerical result out of range
Mar 16 19:25:04 think182 monopd[4512]: could not bind port 1234, exiting
Mar 16 19:25:04 think182 systemd[1]: monopd.service: Main process exited, 
code=exited, status=254/n/a
Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed with result 
'exit-code'.
Mar 16 19:25:04 think182 systemd[1]: Failed to start monopd.service - game 
server for board games like GtkAtlantic.
Mar 16 19:25:05 think182 sudo[4410]: pam_unix(sudo:session): session closed for 
user root


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages monopd depends on:
ii  libc6  2.36-9+deb12u4
ii  libgcc-s1  12.2.0-14
ii  libmuparser2v5 2.3.3-0.1
ii  libstdc++6 12.2.0-14
ii  libsystemd0252.22-1~deb12u1
ii  sysvinit-utils [lsb-base]  3.06-4

monopd recommends no packages.

Versions of packages monopd suggests:
ii  gtkatlantic  0.6.3-2

-- no debconf information