inetd.service spamt in syslog

[vanaalten]

Het was mij een tijd geleden al opgevallen, maar er lijkt niets 'kapot' te zijn - enkel wordt m'n /var/log/syslog ondergespamt:

code:

...
Sep 25 11:57:39 vanaalten systemd[1]: inetd.service: Got notification message from PID 520 (WATCHDOG=1)
Sep 25 11:57:41 vanaalten systemd[1]: inetd.service: Got notification message from PID 520 (WATCHDOG=1)
Sep 25 11:57:44 vanaalten systemd[1]: inetd.service: Got notification message from PID 520 (WATCHDOG=1)
Sep 25 11:57:46 vanaalten systemd[1]: inetd.service: Got notification message from PID 520 (WATCHDOG=1)
...

Vandaag, sinds 06:25, al ruim 8000 entries. Geen idee hoe lang dit probleem al optreedt (de oudste syslog, van 18 september, laat het ook al zien).

Nou lijkt alles verder goed te werken, maar zo langzamerhand begint dit te irriteren en wil ik die spam uit m'n logfile. Echter: ik heb geen idee hoe dit komt en hoe ik dit moet aanpakken.

PID 520:

code:

 # ps -p 520
  PID TTY          TIME CMD
  520 ?        00:00:19 inetd

Ofwel, wordt je weinig wijzer van.

Google geeft mij in elk geval dit resultaat:
https://bbs.archlinux.org/viewtopic.php?id=184326
...acht jaar oud, maar genoeg overeenkomsten. Echter, geen concrete oplossing of tips hoe ik dit verder kan uitzoeken. De laatste opmerking is "It's systemd's own internal watchdog it injects into its event loop. Usually, the messages seen here are only at the debug level." - en dat geeft ook weinig concrete hulp: geen idee hoe ik inetd log level kan beinvloeden (en al helemaal geen idee hoe ik die blijkbaar(?) op 'debug' heb gezet.

Iemand enig idee hoe ik kan achterhalen wat er aan de hand is?

[DJMaze]

vanaalten schreef op dinsdag 25 september 2018 @ 12:06:
Iemand enig idee hoe ik kan achterhalen wat er aan de hand is?

Heb je inetd al in debug modus gedraait om te kijken of daar wat in staat?

[Hero of Time]

Welke distro gebruik je? Want ik heb geen proces genaamd 'inetd' op m'n Debian systeem. Je linkt naar het forum van Arch, maar dat zegt nog niet of je ook zelf Arch draait. Is er iets van systemd configuratie dat met inetd babbelt?

[vanaalten]

Ah, excuses, als startpost verdient bovenstaande geen voldoende...

Machine: Intel DH67CF moederbord, i3-2100 processor, 4GB geheugen en Crucial MX500 1TB SSD

OS: Debian stable / stretch

Ik gok dat ik nog 'inetd' heb draaien omdat dat vroeger de standaard daemon was - de huidige install is geen schone installatie vanaf scratch, maar een resultaat na 16 jaar lang regelmatig 'sudo apt-get dist-upgrade'.

En: geen idee hoe systemd aan inetd hangt. Om heel eerlijk te zijn, bij het invoeren van systemd werd het hele bouwwerk voor mij wat ondoorgrondelijk. Da's denk ik deel van m'n probleem: ik zie even niet wat er aan relaties met inetd is en hoe te achterhalen wat deze melding van inetd triggered.

DJMaze schreef op dinsdag 25 september 2018 @ 12:17:
[...]

Heb je inetd al in debug modus gedraait om te kijken of daar wat in staat?

Goed punt. Met wat google lijkt er inderdaad een mogelijkheid voor te zijn (de '-d' switch), nu even uitzoeken hoe ik dat in de config voor elkaar krijg. Ga ik mee aan de slag, dank.


Edit:
...en rust!

Geen idee of het mij gelukt is om inetd in debug-mode te laten lopen. Als ik /etc/init.d/openbsd-inetd mag geloven (die ik executeer om inetd te (her)starten), dan is een file /etc/default/openbsd-inetd met inhoud "OPTIONS='-d '" genoeg om het voor elkaar te krijgen, maar ik merkte to-taal geen verschil. Ook nergens een bevestiging dat die optie gezien was. Gewoon wat rommel in die string gooien maakte ook niets uit.

Daarna er achter gekomen dat er ook een inetd.service file bestaat in /etc/systemd/system/multi-user.target.wants - met o.a. een "WatchdogSec=5" regel er in.
Aangepast naar 15 seconden, inetd restart: geen verschil.

En uiteindelijk blijkt het gewoon heel simpel te zijn:
/etc/systemd/user.conf had een regeltje "LogLevel=debug". Die er uit geeft 'info' als default, vervolgens systemd herstarten - en de logfile is heeeeerlijk rustig.

Kan je je enkel nog afvragen wie die regel erbij gezet heeft. Lijkt mij dat alleen ikzelf dat geweest kan zijn, het is niet iets dat gebruikelijk is als standaard setting bij release. Maar kan mij totaal niet herinneren ooit in die file bezig geweest te zijn...

Dank voor het luisteren en de suggesties!

[ Voor 35% gewijzigd door vanaalten op 25-09-2018 14:34 . Reden: Aanvulling, probleem opgelost. :) ]

[valkenier]

vanaalten schreef op dinsdag 25 september 2018 @ 13:42:

Ik gok dat ik nog 'inetd' heb draaien omdat dat vroeger de standaard daemon was - de huidige install is geen schone installatie vanaf scratch, maar een resultaat na 16 jaar lang regelmatig 'sudo apt-get dist-upgrade'.

Holy, 16 jaar?? En dat gaat goed?
Ik doe zo nu en dan toch wel eens een frisse install van een nieuwe release, waarbij ik /home partitie intact laat.

[JohanKupers]

valkenier schreef op vrijdag 5 oktober 2018 @ 17:27:
[...]


Holy, 16 jaar?? En dat gaat goed?
Ik doe zo nu en dan toch wel eens een frisse install van een nieuwe release, waarbij ik /home partitie intact laat.

In principe gaat dat goed werken, mits je redelijk snel van release upgrade, Je hebt alleen wel eens dat je voor bepaalde packages in de loop der jaren wat configs moet aanpassen als ze in de distributie van versie veranderen.

Wat je niet moet doen is een installatie jarenlang laten draaien en dan ineens over wilt gaan naar een recentere release waarbij de repositories van de tussenliggende releases al offline zijn.

Been there, done that, made a new install en build it again

Was een gevalletje management wat niet wilde upgraden, want hij doet het toch nog. Totdat ze op die ouwe zooi iets wilde uitbreiden wat dus nieuwere versies nodig had van packages.

[vanaalten]

valkenier schreef op vrijdag 5 oktober 2018 @ 17:27:
[...]


Holy, 16 jaar?? En dat gaat goed?
Ik doe zo nu en dan toch wel eens een frisse install van een nieuwe release, waarbij ik /home partitie intact laat.

Oh, gaat prima. Om de paar jaar naar de nieuwe ‘stable’ release upgraden, half dagje werk om config files bij te werken, dingen te fixen die niet werken, maar verder geen grote problemen.

Enkel overstappen naar een ‘freeze’ voordat een stable release is is wat avontuurlijk. Of een setup met wat dingen uit een ‘testing’ repository, een mixed setup dus, is vragen om problemen. Maar verder doet Debian z’n best om upgrades vrij pijnloos te maken.