Re-launch process [qShieted]

    Liebe QNAP-Gemeinde,


    ich habe gestern meine QNAP (TS-659) wie so oft am Abend eingeschalten und bekam ca. alle 30 Sekunden von der Box folgende Mail:


    Server Name: xxxxxx
    IP Address: xxx.xxx.xxx.xxx
    Date/Time: 2011/12/19 22:32:19
    Level: Warning
    Re-launch process [qShieted].


    Ich finde im Internet keinerlei Infos dazu.
    Kennt irgendjemand diese Meldung/diesen Prozess bzw. weiß was sie/er bedeutet?
    Ich habe schon lange nichts mehr zusätzlich installiert bzw. konfiguriert, das letzte was ich geändert habe, war unmittelbar nach dem Erscheinen, das Einspielen der neuesten Firmware 3.5.2. Die läuft seit dem ohne Probleme. Ich habe gestern noch gar nicht auf die Box zugegriffen, sind schon die Mails eingetruddelt.


    Für Rückmeldung bin ich sehr dankbar.
    Liebe Grüße
    kbee

    Hallo dr_mike,


    Danke für Deine Antwort, ich habe auch den zweiten Thread gelesen.
    Das mit der Schadsoftware ist mir zwar auch schon in den Sinn gekommen, ich kann mir aber keinen Reim draus machen.
    Das müßte eine eigens für QNAP entwickelte Schadsoftware sein (der Beginn der Namen mit "q" läßt mich das vermuten) und ich wüßte nicht wie ich die eingeschleppt haben könnte, da sich mein NAS nach aussen eigentlich überhaupt nicht verbindet - mit Ausnahme der Firmware-Updates.


    Alles sehr sonderbar für mich ... :-/


    lg
    kbee


    P.S.: Virenscann kann ich natürlich machen, wird aber wieder "zwei-mal-Weihnachten"-lang dauern :roll:

    wirklich sehr merkwürdig... ich habe bei qnap schon beim qLonnel prozess zwei mal nachgefragt an unterschiedlichen stellen, aber niemand wusste etwas - also nicht mal die entwickler. schätze das wird in diesem fall nicht anders sein.


    eine schadsoftware wäre möglich aber halte ich auch für eher unwahrscheinlich. das einzige was ich mir sonst noch grundsätzlich vorstellen könnte, wäre dass irgend ein anderer prozess nen child prozess mit zufallsnamen macht aufgrund eines fehlers... wäre aber auch merkwürdig.


    ich schlage vor du lässt qnap mal per teamviewer drauf, damit sie es sich anschauen können. schreib dir gleich ne PN dazu.

    Zitat von "IamQ"

    eine schadsoftware wäre möglich aber halte ich auch für eher unwahrscheinlich. das einzige was ich mir sonst noch grundsätzlich vorstellen könnte, wäre dass irgend ein anderer prozess nen child prozess mit zufallsnamen macht aufgrund eines fehlers... wäre aber auch merkwürdig


    Prinzipiell gehe ich ja auch davon aus, dass es keine Schadsoftware ist, eben wegen dem vorangestellten'q'. Nur habe ich sämtliche Systemdateien auf meinem NAS inhaltlich nach der Zeichenfolge gescannt und absolut nichts gefunden. Interessant ist allerdings auch, dass der Aufbau des Prozessnamen sich ähnelt. Beide fangen mit kleinem 'q' an gefolgt von einem Grossbuchstaben und weiteren fünf Kleinbuchstaben.


    kbee
    Könntest du vielleicht mal auf der Shell den Befehl top ausführen und mal schauen, welche PPID der Prozess ausgibt??
    Beended wird top mit Ctrl+C.

    ja habe bei mir auch überhaupt nix gefunden auf dem nas. schon äusserst suspekt das ganze.


    naja ne qnap-spezifische schadsoftware würde immerhin für die popularität der qnap produkte sprechen :D ;)


    habe beiden usern ne PN geschickt mit der kontaktinfo einer person bei qnap, die bereits informiert ist diesbezüglich. ich bin sehr gespannt was dabei rauskommt.


    die ausgabe von top wäre natürlich auf jeden fall interessant.

    Zitat von "IamQ"

    naja ne qnap-spezifische schadsoftware würde immerhin für die popularität der qnap produkte sprechen :D ;)


    Da haste allerdings Recht. :D


    Das Ergebnis würde mich auch brennend interessieren.

    Hallo Jungs und Mädels,


    herzlichen Dank für euer Interesse und Anteilnahme :) .
    Wenn ich am Abend nach Hause komme werde ich dem Teil mal auf den Zahn fühlen, mal sehen was er preisgibt.
    Mit Linux bin ich halbwegs vertraut also top ist gerade noch in meinem Repertoire drinnen :D.


    Ich lasse Euch wissen, wenn ich neue Erkenntnisse gewonnen habe, ansonsten bin ich über jeden Tip froh der mich weiterbringt.


    lg
    kbee

    Nochwas, sollte der Fehler noch vorhanden sein, dann bitte auch den Inhalt von /etc/daemon_mgr.conf posten.


    Schaut nämlich beinahe so aus, als hätte Irgendetwas den Eintrag

    Code
    DAEMON34 = qShield, start, /sbin/qShield


    zerbröselt.


    Edit:
    Mein Verdacht erhärtet sich.
    Aus

    Code
    DAEMON34 = qShield, start, /sbin/qShield


    und

    Code
    DAEMON21 = ntpdated, start, /usr/sbin/ntpdated


    könnte ein qSieted entstanden sein.


    Genauso, wie in dem anderen Thema aus

    Code
    DAEMON39 = qLogEngined, start, /sbin/qLogEngined


    und

    Code
    DAEMON22 = stunnel, start, /usr/sbin/stunnel /etc/stunnel/stunnel.conf 2>/dev/null 1>/dev/null


    das qLonnel geworden sein kann. Es sieht so aus, als ob unter bestimten Bedingungen ein Script die Conf nicht korrekt parsen kann.

    Da hat der Bub nicht ganz unrecht :D
    Sieht sehr plausibel aus.
    Einzig, was mich noch stört, warum tritt es erst jetzt auf, wo das letzte fw-update schon ein monat aus ist?
    Ausserdem müßte der daemon_mgr in Deinem Beispiel "rückwärts" parsen um zu dieser Kombination zu kommen - es ist alles so kompliziert _hurted:


    Der daemon_mgr taucht ja relativ häufig in den Startskripts auf (/etc/init.d) ... ich kann mir noch keinen Reim draus machen, mal sehen ob die Box am Abend wieder spinnt.


    lg
    kbee

    Die Reihenfolge ist von mir willkürlich gewählt. Die Conf wird ja im laufenden Betrieb aktualisiert, sodass ich nicht weiss, ob die Prozesse immer in der gleichen Reihenfolge darin erscheinen. Andererseits ist es gar nicht mal so unmöglich, wenn zuerst der Prozess ntpdated drin steht und anschliessend von qShield nur teilweise überschrieben wird.


    IamQ
    Dankööö. Hab halt mal noch bissi gestöbert und bin über die Conf gestolpert.


    Edit sagt: Herauszufinden, wann und warum das auftreten kann wäre dann die Aufgabe von den QNAP Entwicklern. ;)

    Zitat

    Herauszufinden, wann und warum das auftreten kann wäre dann die Aufgabe von den QNAP Entwicklern.


    yep hab's qnap bereits gemailt :)

    Zitat von "IamQ"

    yep hab's qnap bereits gemailt :)

    :thumb: :thumb:


    Offtopic: Dann könnten die gleich mal mit schauen, warum die USB-Led nicht leuchtet, wenn ne Platte hinten an USB angeschlossen und korrekt erkannt wird. :D :mrgreen:

    Hallo erst mal.


    Es kam wie es kommen musste, trotz mehrmaligem Neustart keine Probleme :x

    Ich hab mir mal die besprochenen Dinge angesehen:


    *) top:

    Code
    Mem: 636200K used, 377324K free, 0K shrd, 21468K buff, 319944K cachedLoad average: 0.01, 0.02, 0.07    (State: S=sleeping R=running, W=waiting)  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND 9857 admin    R        876  6451  2.9  0.0 top 5460 admin    S       3884  5459  0.0  0.3 twonkymediaserv 3379 guest    S       3520     1  0.0  0.3 proftpd 3845 admin    S       2896     1  0.0  0.2 smbd 5256 admin    S <     2232     1  0.0  0.2 iscsid 3286 admin    S       2036     1  0.0  0.2 cupsd 6448 admin    S       1996  5909  0.0  0.1 sshd 6451 admin    S       1692  6448  0.0  0.1 sh 5024 admin    S       1636     1  0.0  0.1 hd_util 5858 admin    S       1580     1  0.0  0.1 upnpcd


    ... langweilig


    *) /etc/daemon_mgr.conf:

    Code
    DAEMON0 = bcclient, start, /sbin/bcclientDAEMON1 = hotswap, start, /sbin/hotswap &DAEMON2 = qwatchdogd, start, /sbin/qwatchdogd -t 5 &DAEMON3 = qsmartd, start, /sbin/qsmartd -dDAEMON4 = nmbd, start, /usr/local/samba/sbin/nmbd -l /var/log -D -s /etc/config/smb.confDAEMON5 = winbindd, stop, /usr/local/samba/sbin/winbinddDAEMON6 = upnpd, stop, /sbin/upnpd eth0 eth0DAEMON7 = radvd, stop, /usr/sbin/radvdDAEMON8 = nfsd, stop, /usr/sbin/rpc.nfsdDAEMON9 = rpc.mountd, stop, /usr/sbin/rpc.mountdDAEMON10 = rpc.rquotad, stop, /usr/sbin/rpc.rquotadDAEMON11 = _thttpd_, start, /usr/local/sbin/_thttpd_ -p 8080 -nor -nos -u admin -d /home/httpd -c '**.*'DAEMON12 = Qthttpd, start, /usr/local/sbin/Qthttpd -p 80 -nor -nos -u admin -d /home/Qhttpd -c '**.*'DAEMON13 = smbd, start, /usr/local/samba/sbin/smbd -l /var/log -D -s /etc/config/smb.confDAEMON14 = proftpd, start, TZ=/etc/localtime /usr/local/sbin/proftpd -n > /dev/null 2>&1 &DAEMON15 = crond, start, /usr/sbin/crond -l 9 -c /tmp/cron/crontabsDAEMON16 = ntpdated, start, /usr/sbin/ntpdatedDAEMON17 = stunnel, start, /usr/sbin/stunnel /etc/stunnel/stunnel.conf 2>/dev/null 1>/dev/nullDAEMON18 = upsd, start, /usr/sbin/upsd -u adminDAEMON19 = sshd, start, /usr/sbin/sshd -f /etc/ssh/sshd_config -p 22DAEMON20 = picd, start, /sbin/picd  1>/dev/null 2>/dev/null &DAEMON21 = hwmond, start, /sbin/hwmond &DAEMON22 = upsutil, start, /usr/sbin/upsutil &DAEMON23 = acpid, start, /sbin/acpidDAEMON24 = gpiod, start, /sbin/gpiod &DAEMON25 = hd_util, start, /sbin/hd_util &DAEMON26 = gen_bandwidth, start, /sbin/gen_bandwidth -r -i 5 &DAEMON27 = klogd.sh, start, /etc/init.d/klogd.sh start &DAEMON28 = qShield, start, /sbin/qShieldDAEMON29 = lcdmond, start, /sbin/lcdmondDAEMON30 = vdd_control, start, /sbin/vdd_control -d >/dev/null 2>&1 &DAEMON31 = qLogEngined, start, /sbin/qLogEnginedDAEMON32 = qsyslogd, start, /sbin/qsyslogdDAEMON33 = min_snmptrapd, stop, /sbin/min_snmptrapdDAEMON34 = upnpcd, start, /sbin/upnpcd -i 300 &


    ... auch nicht so der Renner


    *) ps |grep q:


    ..unauffällig


    Nun einige - wenn auch meist verwirr{end|t}e - Gedanken von mir:
    Die Theorie von Onkel mike hat natürlich was, aber ganz gerafft hab ich das Ganze noch nicht.
    Die /etc/daemin_mgr.conf wird - so vermute ich - beim Starten erzeugt. Darin sind alle daemons mit deren aktuellem Status aufgelistet.
    Ein /etc/init.d/crond stop führt auch prompt zur entsprechenden Änderung im .conf file, neben dem Dienst ändert sich der Status auf stop.
    Die Liste bleibt also im laufenden Betrieb, bis auf Statusänderungen, statisch.
    Das Problem kann also nur zum Zeitpunkt der Erzeugung generiert werden und diesen Zustand habe ich ja sicherheitshalber durch das Ausschalten vernichtet :oops:
    D.h. aber: An alle bei denen so ein Problem in Zukunft auftreten sollte, unbedingt /etc/daemon_mgr.conf anschauen, ob da was "krankes" drinnen steht.


    btw mike: echt cool die Theorie.


    lg
    kbee

    ich sichere mir regelmäßig über einen Crontabeintrag meine Config weg,....


    Code
    0 9 * * * tar cvvjf /share/HDC_DATA/systemdaten-disk-0/Serverdaten-0/Disk-0-`date +%Y%m%d-%H%M%S`-etc.tar.bz2 /etc


    dann könnte man hinterher die Stände vergleichen