Logging stopt na een reboot.

[Briolet]

Ik heb er al zeker een jaar last van dat het syslog deel stopt na een reboot, maar ik kan de vinger niet achter de oorzaak krijgen.

Het begint ermee dat de share met de naam "Logs" na een reboot geheel verwijderd wordt, inclusief metadata. Daarna wordt hij weer opnieuw aangemaakt. Zie onderstaand screenshot uit mijn log.



Dit is de enige share waar dit bij gebeurd. Maar omdat de share gewist is, besluit Log Center dat hij niet meer kan loggen en zet alle log functies uit en vergeet het oude pad. Na een reboot moet ik dat op drie plekken weer activeren.

Eigenlijk dacht ik dat de share misschien corrupt was. Vanochtend heb ik de share hernoemd tot "Logs-oud" en een nieuwe share aangemaakt met de naam "Logs". Vervolgens alle data van de oude share naar de nieuwe share verplaatst.

Ik doe net een reboot als test, maar tot mijn verbazing gebeurd nu hetzelfde net de nieuwe share. Heeft iemand dit ooit meegemaakt of een idee waarom juist van deze share de metadata gewist wordt na een reboot.

[Hofstede]

Bij mij zie ik dat niet. Maar mijn share heet LogsAndReports. Het zou zo maar kunnen dat "Logs" een reserved name is en dat dat intern tot rare verschijnselen leidt.

Zie je het ook gebeuren als je de share een andere naam geeft?

[Briolet]

Deze share heet al 'Logs' sinds 2012 

Maar het kan iets recents (1 jaar geleden) geweest zijn dat dit veroorzaakt. De naam van de share aanpassen was inderdaad een van mijn volgende tests. (Maar dan moet ik alles wat logt even nalopen qua paden).

Alleen LogCenter onthoudt het nieuwe pad als ik de naam van de share aanpas. Dat viel me op toen ik de share-naam in "Logs-oud" veranderde.

Mijn andere idee is dat LogCenter dit triggert. Wil ik ook nog testen door te rebooten met logging uit. Maar dit is mijn werk-nas, dus wil ik dit soort testen met rebooten liever tot het weekend uitstellen.

[Briolet]

Ik heb de naam nu in "Logboeken" veranderd. Net als gisteren kreeg ik de volgende waarschuwing:



Log Center is de enige loggende app die ziet dat ik de naam verander. In de app is het pad daarna ook netjes aangepast.  Hierna rebooten geeft niet meer het probleem met de share. Het lijkt er inderdaad op dat de naam "Logs" een gereserveerde naam is geworden.

Log Center is de enige app die de naamsverandering volgt. De apps Surveillance Station, Security Analyser, Opslag Analyser, etc. geven nu een waarschuwing bij het openen, dat ze de opslaglocatie niet meer kunnen vinden.
En ik had een aantal scripts op deze share staan. Moest ik ook de paden van aanpassen.

Ik zal het nog even in de gaten houden, maar het lijkt idd aan de naam te liggen. (Al dan niet in combinatie met Log Center)

[Briolet]

Om het volledig te testen heb ik opnieuw een share "Logs" gemaakt. Maar nu met niet erop en ook niets meer dat naar deze share logt.

Na een reboot zie ik weer in het log:



Het moet echt de naam van de share zijn die dit veroorzaakt.

Als ik in het log zoek op "Metadata", dan zie ik dat het 12-12-2018 begonnen is.  Ik zie ook 5x dat de metadata van mijn externe USB disk gewist zijn. Maar dat dus niet bij elke reboot. (17x in die periode)

[Hofstede]

Volgens mij heeft de Metadata melding met de Media/ Universal Search indexer te maken. En die begint telkens opnieuw omdat de Logs share wordt verwijderd en toegevoegd. M.a.w. de Metadata melding is een gevolg.

De Metadata melding voor USB schijven is een bug die al heel lang geleden is gemeld maar nooit opgelost. Ik denk dat Synology dit bewust doet met USB schijven om de index te vernieuwen.

Mijn vermoeden is dat na een herstart een opschoonprocedure automatisch de Logs directory waar de share naar verwijst verwijderd. Dan gaat de NAS de shares tijdens boot initialiseren, ziet dat voor de share Logs de bijbehorende directory is verdwenen, en maakt hem opnieuw aan.

Dat zou je kunnen testen door niet een share maar via SSH zelf een directory Logs aan te maken en kijken of die blijft staan bij herstart.

Toevoeging:
Ik heb het zojuist op twee verschillende NASsen geprobeerd, geen van beide vertoond dit verschijnsel. Share Logs wordt door DSM ongemoeid gelaten.

Het enige wat ik kan bedenken dat één van de door jouw geinstalleerde packages die van de Logs share gebruik maakt het probleem veroorzaakt.