Du willst in dem Unit- File das "default.target".
Das ist meist Runlevel5, also das Bunte mit Netzwerk und vielen möglichen Benutzern.
Du willst explizit NICHT das reboot.target. Die Ausführung deines Scriptes (wenn es denn richtig für systemd konfiguriert wäre), würde solange verzögert, bis du die Kiste neu starten würdest. Das ist nicht in deinem Sinne.
Und dann hast du einen gewaltigen Denkfehler in deinem Ansatz.
Du möchtest ein Userland Script als Systemdienst starten.
Keine leichte Aufgabe und erst recht keine gute Idee.
Da dein Script Fenster malen will, braucht es ein laufendes DesktopEnvirionment (also ein Gnome, KDE, xfce....)
Das läuft unter einem User.
Also kein Systemdienst.
Und deshalb liest du auch nur Fehler.
Dein Script wird gerufen und möchte irgendwohin schreiben, was es nicht kann, da systemd deinem Script weder ein Display noch ein Terminal zugeordnet hat. Ende Gelände.
Systemd kann aber auch im Userland spielen.
Tatsächlich kann jeder User seine eigenen Services starten.
Da wärest du jetzt richtig.
Aber es ist viel einfacher dein Script im jeweiligen DesktopEnvironment auf die herkömmliche (und bereits empfohlene) Weise als normales "Autosstart" - Script zu rufen.
Wenn du es dennoch mit deinem Servicefile via systemd starten möchtest, melde dich einfach normal am DE an, und gib dann als User die Kommandos:
ein.
Das "enable" weist systemd an, diese Unit auch künftig nach jedem Boot zu starten,
und "start" tut, was es sagt.
Wenn du als User mit systemd dein Script rufst, wird es logischerweise auch nur gerufen, wenn genau dieser User sich anmeldet.
Es ist nicht so ganz klar, ob du das wirklich willst.
Aber klar ist, dass ein Script, das Fenster malt, sicher KEIN Systemdienst sein kann.