Bug#1066983: monopd: Fails to start monopd.service
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
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
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#531546: cacti and rrdtool 1.3
Package: cacti Followup-For: Bug #531546 Actually the release of cacti included in Lenny (0.8.7b) does not support rrdtool 1.3. This is because cacti was not supporting it when Lenny was released. Release Notes - 0.8.7c - ... - RRDtool 1.3 Support - ... Installing the unstable cacti package (0.8.7d by now) fixed all issues I had, empty graphs, ... Maybe we should push cacti = 0.8.7c into the next Lenny release ? Sylvain -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages cacti depends on: ii apache2-mpm-prefor 2.2.9-10+lenny2 Apache HTTP Server - traditional n ii dbconfig-common1.8.39common framework for packaging dat ii debconf [debconf-2 1.5.24Debian configuration management sy ii libapache2-mod-php 5.2.6.dfsg.1-1+lenny3 server-side, HTML-embedded scripti ii libphp-adodb 5.05-1The ADOdb database abstraction lay ii logrotate 3.7.1-5 Log rotation utility ii mysql-client-5.0 [ 5.0.51a-24+lenny1 MySQL database client binaries ii php5-cli 5.2.6.dfsg.1-1+lenny3 command-line interpreter for the p ii php5-mysql 5.2.6.dfsg.1-1+lenny3 MySQL module for php5 ii php5-snmp 5.2.6.dfsg.1-1+lenny3 SNMP module for php5 ii rrdtool1.3.1-4 Time-series data storage and displ ii snmp 5.4.1~dfsg-12 SNMP (Simple Network Management Pr ii ucf3.0016Update Configuration File: preserv Versions of packages cacti recommends: ii iputils-ping 3:20071127-1 Tools to test the reachability of ii mysql-server 5.0.51a-24+lenny1 MySQL database server (metapackage ii mysql-server-5.0 [mysq 5.0.51a-24+lenny1 MySQL database server binaries Versions of packages cacti suggests: pn php5-ldap none (no description available) -- debconf information: cacti/purge: false cacti/db/app-user: cacti cacti/passwords-do-not-match: cacti/dbconfig-remove: cacti/mysql/admin-user: root * cacti/dbconfig-install: true cacti/upgrade-backup: true cacti/missing-db-package-error: abort cacti/install-error: abort * cacti/webserver: Apache2 cacti/internal/reconfiguring: false cacti/mysql/method: unix socket cacti/database-type: mysql cacti/remote/host: cacti/remove-error: abort cacti/db/dbname: cacti cacti/remote/port: cacti/dbconfig-reinstall: false cacti/upgrade-error: abort cacti/dbconfig-upgrade: true cacti/internal/skip-preseed: false cacti/remote/newhost: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#424723: closed by Pierre Habouzit [EMAIL PROTECTED] (Re: Bug#424723: Acknowledgement (nscd is crashing after few seconds))
Hi, On Fri, May 18, 2007 at 07:24:05AM +, Debian Bug Tracking System wrote: this is a known problem, that there is some inconsistencies between etch and sarge version for whatever reason, and we noticed it too late. So you have to purge the cache manually, and it /should/ work after that. You misread, this is not between etch and sarge because this is a fresh etch install. On etch nscd crash just after corrupting its database from time to time. Then when your restart it with the corrupted db it crashes after few seconds, the only way to start it again is to clear the cache and it will work for few days. The only workaround available is a cron job like : */10 * * * * root if ! pidof nscd /dev/null ; then rm /var/db/nscd/* ; /etc/init.d/nscd start ; fi Sylvain signature.asc Description: Digital signature
Bug#424723: Acknowledgement (nscd is crashing after few seconds)
Hi, It seems that clearing /var/db/nscd fixes the problem but this is a fresh install (ie. not upgraded from Sarge) then there is still a problem somewhere (cache db corrupted for some reasons ?). Sylvain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424723: nscd is crashing after few seconds
Package: nscd Version: 2.3.6.ds1-13 Severity: grave Justification: renders package unusable Well, I believe this is somehow important, on all of my servers it crashes in about 15 seconds. Please note that I am using a lot of groups (more than 2000) and that my servers are heavily loaded. I am using a vanilla kernel (without grsec, pax, and such). It worked without problem on Debian Sarge. Here is a gdb output (without symbols however) : # gdb /usr/sbin/nscd GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (gdb) run -d Starting program: /usr/sbin/nscd -d (no debugging symbols found) 4110: handle_request: request received (Version = 2) from PID 4119 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4119 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4120 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4121 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4121 4110: GETPWBYUID (11101) 4110: Haven't found 11101 in password cache! [New LWP 4117] 4110: handle_request: request received (Version = 2) from PID 4120 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4120 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4122 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4122 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4121 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4122 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4121 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4119 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4123 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4123 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4123 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4124 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4124 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4124 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4125 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4125 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4126 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4126 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4126 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4125 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4127 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4127 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4127 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4128 4110: GETFDPW 4110: provide access to FD 7, for passwd 4110: handle_request: request received (Version = 2) from PID 4128 4110: GETFDGR 4110: provide access to FD 9, for group 4110: handle_request: request received (Version = 2) from PID 4128 4110: GETFDHST 4110: provide access to FD 11, for hosts 4110: handle_request: request received (Version = 2) from PID 4129 4110: GETFDPW 4110:
Bug#369443: no /usr/X11R6 directory makes pornview segfault on startup
Package: pornview Version: 0.2pre1-5 Severity: grave Justification: renders package unusable I am using a fresh debian install, so I use Xorg7, then I have a quite empty /usr/X11R6/ directory, here are the latest strace output before SIGSEGV. open(/usr/share/pixmaps/gnome/cursors/32e49c8b393e725c8f6b5fc0203e4fff, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/share/pixmaps/gnome/index.theme, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/X11R6/lib/X11/icons/gnome/cursors/32e49c8b393e725c8f6b5fc0203e4fff, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/X11R6/lib/X11/icons/gnome/index.theme, O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Process 3532 detached -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.16 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages pornview depends on: ii libatk1.0-0 1.11.4-2 The ATK accessibility toolkit ii libc6 2.3.6-9GNU C Library: Shared libraries ii libglib2.0-0 2.10.3-1 The GLib library of C routines ii libgtk2.0-0 2.8.17-2 The GTK+ graphical user interface ii libpango1.0-0 1.12.1-3 Layout and rendering of internatio ii libpng12-01.2.8rel-5.1 PNG library - runtime ii libx11-6 2:1.0.0-6 X11 client-side library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxine1 1.1.1-1.1 the xine video/media player librar ii xlibs 6.9.0.dfsg.1-6 X Window System client libraries m ii zlib1g1:1.2.3-11 compression library - runtime pornview recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
