Fail to restart nginx service // delete triggered task

[Vargraen]

Moin,

ich bin dumm. Ich wollte mit meinem nginx-proxy-manager in Docker herumspielen und wollte dafür die Ports 80 und 443 vom internen nginx Server befreien. Also erstellte ich einen "Ausgelösten Task" zum BootUp

sed -i -e 's/80/82/‚ -e 's/443/445/‚ /usr/syno/share/nginx/server.mustache /usr/syno/share/nginx/DSM.mustache /usr/syno/share/nginx/WWWService.mustache

synosystemctl restart nginx

Leider war einer der Ports schon in Benutzung und der nginx service konnte nicht neu gestartet werden. Was ich nicht wusste war, dass auch die gesamte Weboberfläche zur Verwaltung der Syno an dem internen nginx Server hängt. Und ohne den komme ich natürlich auch nicht in die Aufgabenverwaltung dort hinein. Was ich noch habe ist der SSH Zugang.
Ich habe darüber versucht die drei im Script genannten Files wieder zurück zu ändern und den Service neu zu starten, aber selbst nachdem ich die alten Ports dort mit vim erfolgreich eingetragen habe, weigert sich der nginx service neu zu starten und ich weiß nicht warum.
Bei einem kompletten Neustart der Syno funktioniert der Server für eine kurze Zeit wie er soll, bis das BootUp Script eben ausgeführt wird. Ich brauche also entweder einen Weg den nginx service über SSH erfolgreich zu starten oder dieses triggered script on bootup zu löschen. Leider ist es kein "scheduled task", dort hab ich schon gefunden wie ich den löschen könnte. Wo aber die triggered tasks liegen weiß ich nicht.
Hat von euch jemand eine Idee wie ich das System retten kann?

 

[Ulfhednir]

VORSICHT: DSM verwendet für das Anwendungsportal etc. ebenfalls einen Nginx. Wenn du diesen versuchst abzuschießen, schießt du dir dein System mutmaßlich selbst ab. Dein Problem lässt sich anderweitig lösen: Du machst das Portforwarding 80/443 einfach auf die gebundenen Ports des Proxy-Managers. So handhabe ich das mit SWAG ohne Probleme.

 

[Vargraen]

Ja, das habe ich auch festgestellt. Das System hab ich mir damit nun abgeschossen...

 

[Ulfhednir]

Weil meine Alarmsirenen hochgingen, habe ich das Folgefroblem glatt überlesen.
unter /etc/crontab sollten die Cronjobs / Tasks gespeichert sein. Die kannst du theoretisch dem VI-Editor ändern oder löschen.
Ich würde mal behaupten: Vermutlich die letzte ID in der File.

sudo -i cd /etc vi crontab

 

[Vargraen]

Komischerweise taucht der Job da nicht auf, lediglich die zeitgesteuerten Backup Jobs habe ich dort drin. Ich habe den Job auch nicht über synoschedtask --get id=xx gefunden - ich nahm daher an dass die "triggered tasks" woanders abgelegt werden als die scheduled tasks.

 

[Ulfhednir]

Scheinst Recht zu haben. Ich habe gerade einen Trigger erstellt und abgeglichen.
Wirst du vielleicht unter:

/usr/syno/etc/synoschedule.d/root fündig?

 

[Vargraen]

Leider nein, da liegt der Task auch nicht. Sehr seltsam.
Ich hab es jetzt wieder rückgängig machen können. Ich habe die DS einmal rebooted, den nginx mit synosystemctl stop nginx angehalten, die Files nochmal mit vi zurückgeändert und wieder über synosystemctl start nginx gestartet. Ich vermute mal dass der Service noch irgendwie lief als ich das das erste Mal probierte. Ich bin jedenfalls heilfroh dass das wieder funktioniert und werd das so lassen und mir mal anschauen wie ich den npm anders nutzen kann.

 

[luddi]

Ist leider nur in einer Datenbank abgelegt.

Details könnt ihr hier entnehmen: https://www.synology-forum.de/threa...oesartig-mach-nett-aber-wie.80071/post-662994