Programmupdate im Dienst - So möglich?

[Bernhard Geyer]

Gegeben:
Anwendung läuft in Dienst unter lokalen Konto.

Anforderung:
Dienstanwendung soll sich aktualisieren können.

Normalerweis würde man zweite Exe (Update.exe) starten, sich selbst beenden und die Update sorgt dafür das die eigene Exe aktualisiert wird.
Da diese in einem Dienst läuft, müsste der Dienst beendet werden.
Was passiert dann? Beendet sich dann auch diese "Diensteumgebung/"Desktop" nicht gleich mit?

[MyRealName]

Was ich mal gemacht habe ist einfach eine Mini-Einfach-Exe, welche eine DLL oder BPL lädt und zum updaten entlädt. Exe selbst wird nie geupdated, brauch ja auch nicht, ist nur ein Loader

[Bernhard Geyer]

Zitat:

Zitat von MyRealName (Beitrag 1512290)

Was ich mal gemacht habe ist einfach eine Mini-Einfach-Exe, welche eine DLL oder BPL lädt und zum updaten entlädt. Exe selbst wird nie geupdated, brauch ja auch nicht, ist nur ein Loader

Wäre eine Idee bei neuen Anwendung.
Hier haben wir schon eine bestehende Anwendung die aufgrund der Historie nicht so einfach so umgebaut werden könnte.

[peterbelow]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1512288)

Gegeben:
Anwendung läuft in Dienst unter lokalen Konto.

Anforderung:
Dienstanwendung soll sich aktualisieren können.

Normalerweis würde man zweite Exe (Update.exe) starten, sich selbst beenden und die Update sorgt dafür das die eigene Exe aktualisiert wird.
Da diese in einem Dienst läuft, müsste der Dienst beendet werden.
Was passiert dann? Beendet sich dann auch diese "Diensteumgebung/"Desktop" nicht gleich mit?

Implementiere die zweite Anwendung auch als Dienst. Wenn die erste ein Update detektiert kann sie diesen zweiten Dienst starten und sich selbst beenden.

[Delphi.Narium]

Unter Windows kann man doch mit

Code:

net stop "NameDeinesDienstes"

einen Dienst beenden.

Dann die Update.exe starten und dann mit

Code:

net start "NameDeinesDienstes"

den Dienst wieder starten.

Das als Batchdatei mit dem Aufruf der Update.exe zwischen dem Stoppen und Starten des Dienstes, aufgerufen per ShellExecute?

Was bei "NameDeinesDienstes" anzugeben ist, kann Du mit

Code:

net start

herausfinden, in der Liste einfach nach dem Namen suchen.

Oder mit Delphimitteln, wie in dem schon etwas älteren Post beschrieben: Run "Net Start..." in Delphi

Kombiniert mit peterbelows Vorschlag sollte das mit reinen Delphimitteln gehen, ohne Nebenwirkungen auf andere Dienste und / oder Programme, sofern sie nicht von Deinem Dienst in irgendeiner Form abhängig sind.

[Bernhard Geyer]

Da die Update.exe ja im Dienst gestartet würde ja sich mit dem Dienst beenden sich doch selbst "killen".

Zitat:

Implementiere die zweite Anwendung auch als Dienst. Wenn die erste ein Update detektiert kann sie diesen zweiten Dienst starten und sich selbst beenden.

Das wäre eine Idee.
Auch wenn dieser zweite Dienst nur temporär vorhanden wäre, könnte man damit das Problem lösen.
(Sollte ja aufgrund der lokalen Adminrechte kein Problem sein.

1. Dienst registrieren
2. Starten
3. Beim Restart des ersten Dienstes diese Dienst stoppen und deregistieren.

Danke für den Hinweis.

[Delphi.Narium]

Wenn ich per ShellExercute ein Programm starte, kann ich mich sofort beenden, ohne dass das per ShellExecute gestartete Programm davon betroffen ist.

Ist das Verhalten aus 'nem Dienst heraus anders?

[Bernhard Geyer]

Zitat:

Zitat von Delphi.Narium (Beitrag 1512297)

Wenn ich per ShellExercute ein Programm starte, kann ich mich sofort beenden, ohne dass das per ShellExecute gestartete Programm davon betroffen ist.

Ist das Verhalten aus 'nem Dienst heraus anders?

Das ist ja mehr oder minder die Frage:
Ich beende ja den Dienst, der mit der zu aktualisierenden Anwendung verbunden ist.
Damit müsste m.E. Windows den ganzen "Dienste-Desktop" unter dem der Updater gestartet wurde doch auch beenden, oder?

[Delphi.Narium]

Ehrlich gesagt verstehe ich nicht, warum das passieren sollte.

Ein Dienst ist doch auch nur ein Programm.

Zum Test würd' ich mir 'nen Dienst schreiben, der per ShellExecute eine Batchdatei startet. In der Batchdatei zuerst den Dienst beenden und 'nen Moment warten. Dann die Exe des Dienstes umbenennen und ein bisserl warten. Dann die Exe zurück umbenennen und wieder 'nen Moment warten und dann den Dienst starten.

Per Echo kannst Du in der Batchdatei jeweils eine Ausgabe in 'ne Textdatei umleiten, um darin ggfls. nachvollziehen zu können, bis wohin die Batchdatei gekommen ist oder ob sie auf Anhieb sofort vollständig durchläuft.

Wenn Deine Vermutung stimmt, müsste die Batchdatei nach dem "net stop DeinDienst" beendet werden.

[himitsu]

Windows weiß, was ein Programm/Dienst gestartet hat. zu jedem Programm wird dessen Parent gespeichert.

Also technisch wäre es schon möglich, dass Windows beim Beenden eines Diensts ALLES von ihm beendet.
Ist wie wenn ich im Taskmanager (Details) zu einem Programm sage "Prozessstruktur beenden" (diesen Prozess/Task samt seiner ChildProzesse und deren Childs usw.), gegenüber "Task beenden" (nur diesen Prozess).



Aber es kann auch einfach nur sein, dass der Dienst in einer eigenen Session läuft.
Gestartet Programme, auch die CMDs, würden dann standardmäßig in dieser Session laufen
und beendet Windows beim Ende des Dienstes auch diese Session, dann fliegt das mit weg.
Also ich fände es schon nett, wenn Windows da mal bissl aufräumt. :angle2:



PS: Du kannst doch zwei EXEn machen, also noch einen "manuell" gestarteten UpdateService, welcher dann deinen Dienst beendet, aktualisiert und wieder startet. (durch deinen ersten Service gestartet)

[QuickAndDirty]

Update.exe kann eine Laufende .exe umbennen! Das geht auch von hand im explorer... ich war auch erschrocken als ich das getestet hab, aber es geht.

1. Update.Exe benennt meindienst.exe im laufenden Betrieb um in Meindienst_kannweg_2022_09_23_12_00.exe
2. Update.Exe führt einen download der neuen Meindienst.exe durch und speichert sie anstelle der alten meindienst.exe
3. Update.Exe initiert entweder einen Neustart des Dienstes oder es trägt einen Neustart des dienstes in den Taskscheduler von Windows ein oder man wartet bis der Dienst aus anderen Gründen neustartet.
4. meindienst.exe löscht beim start Meindienst_kannweg_2022_09_23_12_00.exe

[MyRealName]

Windows hängt das Handle der offenen Datei einfach beim Umbennen um

[QuickAndDirty]

Zitat:

Zitat von MyRealName (Beitrag 1512329)

Windows hängt das Handle der offenen Datei einfach beim Umbennen um

ist auf jedefall, cool , denn es erlaubt Software Updates mit super wenig downtime.

[himitsu]

Es gibt garkeine offenen FileHandle auf die EXE.
Der Programmcode wird via MMF in den Speicher gemappt. (ein FileHandle gibt es nur kurz beim Programmstart)

Das Mapping auf den Dateiihnalt (Festplatte) arbeitet anders und daher wird das Umbenennen nicht behindert.
Nur das Löschen/Ändern geht so halt nicht, aber der Adressaufkleber (der Dateiname) kann geändert werden. (MMF hängt halt nicht am Pfad/Namen, sondern am Inhalt)

[Bernhard Geyer]

Zitat:

Zitat von QuickAndDirty (Beitrag 1512334)

Zitat:

Zitat von MyRealName (Beitrag 1512329)

Windows hängt das Handle der offenen Datei einfach beim Umbennen um

ist auf jedefall, cool , denn es erlaubt Software Updates mit super wenig downtime.

Das funktioniert aber immer nur Semi-Stabil.

Den Trick versuchte ich immer wieder in den letzten "Jahrzehnten" zu nutzen, um Updates am Server trotz offener Anwendung auszutauschen.
Im einem Jahr ging es, im nächsten nicht mehr.
Ok. An einem Netzwerkshare ist es komplizierter da noch weitere Faktoren rein spielen könnten

[QuickAndDirty]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1512346)

Zitat:

Zitat von QuickAndDirty (Beitrag 1512334)

Zitat:

Zitat von MyRealName (Beitrag 1512329)

Windows hängt das Handle der offenen Datei einfach beim Umbennen um

ist auf jedefall, cool , denn es erlaubt Software Updates mit super wenig downtime.

Das funktioniert aber immer nur Semi-Stabil.

Den Trick versuchte ich immer wieder in den letzten "Jahrzehnten" zu nutzen, um Updates am Server trotz offener Anwendung auszutauschen.
Im einem Jahr ging es, im nächsten nicht mehr.
Ok. An einem Netzwerkshare ist es komplizierter da noch weitere Faktoren rein spielen könnten

Naja Updates sind bei mir immer lokal und das Update wird von einem Dienst durchgeführt. Der Dienst ist immer aus. Wird nur für das Update gestartet und existiert wirklich nur um die Elevevated Rights aus der installation zu konservieren, so dass Updates immer mit Elevated Right durchegführt werden können.
Zudem setzte ich den SecurityDiscriptor(ACL) des Dienstes , bei der installation(ServiceAfterInstall) herunter, damit er von Anwendungen mit Userrechten gestartet werden kann.
Ich weiß nicht viel darüber, aber ich habe es mir (ein bisschen) von Chrome und (sehr viel)von Firefox abgeschaut.

Nutze im Moment diese ACLs für den Update Service...oder Elevation Service...

Delphi-Quellcode:

{//Alte ACL (SDDL )
  Permission := 'D:' +
  '(A;;CCLCSWRPWPDTLOCRRC;;;SY)' +         // default permissions for local system
  '(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)' + // default permissions for administrators
  '(A;;CCLCSWLOCRRC;;;AU)' +               // default permissions for authenticated users
  '(A;;CCLCSWRPWPDTLOCRRC;;;PU)' +         // default permissions for power users
  '(A;;CCDCLCSWRPWPDTLOCRSDRC;;;BU)'+      // Built IN Users
  '(A;;RP;;;IU)';                          // added permission: start service for interactive users
}
  Permission := 'D:' +
  '(A;;CCLCSWRPWPDTLOCRRC;;;SY)' +         // default permissions for local system
  '(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)' + // default permissions for built-in administrators
  '(A;;CCLCSWRPLOCRRC;;;IU)'+              // permissions for interactively logged-on user   von MozillaMaintainance und ChromeElevation
  '(A;;CCLCSWRPLOCRRC;;;SU)'+              // permissions for service logon user  von MozillaMaintainance und ChromeElevation
  '(A;;CCDCLCSWRPWPDTLOCRSDRC;;;BU)'+      // permissions for built-in users
  '(A;;CCLCSWRPLOCRRC;;;AU)' +             // default permissions for authenticated users
  '(A;;CCLCSWRPWPDTLOCRRCRP;;;PU)';        // default permissions for power users

Wenn die mal nicht mehr ausreichen passe ich die halt an.