Na ja, das ist alles eigentlich eine Grundeigenschaft aller Linuces.
Ein Prozess kann in prinzipiell zwei verschiedenen Modi laufen: Interaktiv oder eben nicht interaktiv.
Reine Serverprogramme laufen immer im nicht-interaktiven Modus.
Die sollen ja auch im Hintergrund schweigend möglichst schnell und gut ihren Dienst versehen.
Sie werden einfach gestartet, ohne dass ihnen ein Terminal zugeordnet wird.
Die können nicht einfach etwas ausgeben.
Sie schreiben ihre Ausgaben meist in das Systemjournal, oder halt in irgendwelche Dateien, die ihnen per Konfigdatei (oder hardcoded im Binary selbst) zugeordnet werden.
Interaktive Programme brauchen Tastatur und Bildschirm. Anders macht das ja auch kaum Sinn.
Werden die gestartet, wird zu allererst einmal ein Terminal gestartet, das seinerseits dann eine Shell oder das jeweilige Programm aufruft.
Das zugeordnete Terminal verbindet nun die ersten drei Dateidescriptoren (letztlich Integerzahlen von 0 bis zur konfigurierbaren Obergrenze von su -c 'sysctl fs.file-max' ). Dabei ist Nummer 0 das Keyboard, Nummer 1 der Bildschirm und Nummer 2 der Fehlerkanal, der standardmäßig ebenfalls auf den Bildschirm zeigt. Und damit kann das Programm auf dem Bildschirm ausgeben und von der Tastatur lesen. Die Fehler landen ebenfalls -ohne jede Rücksicht auf die möglicherweise gleichzeitig stattfindende "normale" Ausgabe auf dem Bildschirm, was i.d.R. eine völlig chaotische Bildschirmdarstellung zeitigt.
Shells, wie die bash, können in beiden Modi laufen. Interaktiv sogar als Login-Shell.
Oder eben, wenn Scripte abgearbeitet werden nicht-interaktive(, oder sogar auch da interaktiv).
Shells sind nun mal ihrer Natur nach Zwitterwesen.
Noch etwas anders laufen die Dinge in einer graphischen Konsole.
Dort wird die erste graphische Konsole distributionsabhängig (und ebenfalls konfigurierbar) meist auf dem Pseudoterminal Nummer 7 gestartet. Es ist somit durch <strg><alt><F7> erreichbar. Dort übernimmt aber der darunterliegende X-Server (oder neuerdings Wayland) alle Input und Outputgeräte. Dazwischengeschaltet kümmert er sich, dass die entsprechenden Fenster die jeweiligen Mausbewegungen und Tastendrücke korrekt erhalten.
Dein kdialog ist genau zwischen all den herrlichen Kleinigkeiten.
Ich glaube (bin mir aber nicht sicher), dass sogar kdialog mittlerweile die IPC (InterProcessCommunication) von Linux, also letztlich dbus nutzt.
Dabei wird das DE angewiesen vom X-Server (oder Wayland) ein neues Fenster zu erzeugen.
Das geht am Terminal komplett vorbei.
(Es geht auch komplett am Terminal vorbei, wenn es noch nach der alten Methode direkt mit dem X-Server babbelt)
Da dein Script solche Ausgaben verwendet, ist es eigentlich kein wirklicher Service, sondern tatsächlich ein interaktives Script.
Aber egal.
Das regeln der Reihenfolge in systemd wird damit auch nicht leichter. Das bleibt erst mal undurchsichtig, wie es halt ist.
Bei systemd liegt das Hauptaugenmerk auf möglichst optimaler Parallelisierung.
Die Reihenfolge der Abarbeitung aller Scripte wird nicht, wie SysV- Init durch die nummerische Reihenfolge der Scriptnamen ( 10-irgendwas kommt vor 11-irgendwasanderes usw.) geregelt, sondern durch die Definition von sogenannten Targets, worauf sich die Konfiganweisungen BEFORE, AFTER, WANTS und dergleichen beziehen.
Das kannst du in man systemd.service nachlesen. Die komplette Doku findet sich bei Freedesktop (ganz runterscrollen bis zu Manuals and Documentation for Users and Administrators )