Also.... Ich habe das wie folgt gelöst:
Codeapache2 -Vläßt sich nicht derzeit nicht ausführen.
Ich werde jetzt erst einmal die Sache mit den Repos in Ordnung bringen.
Das ist seltsam - dieser Befehl sollte eigentlich auch dann gehen, wenn Apache nicht läuft.... Hmmmmmmmmmmmmm
Ok...
Auf Opensuse ist leider vieles anders, deshalb mache ich Apache Sachen immer auf Ubuntu....
Aber laut den Docs (extra mal nachgesehen) liegt Apache hier: /etc/apache2/
Also machst Du mal Folgendes:
cd /etc/apache2/
## um logfiles zu identifizieren und den loglevel auch
grep -R -i "log" * > ~/logconfig.txt
## um die hosts zu finden
grep -R -i "servername" * > ~/hosts.txtDann ins Homeverzeichnis gehen und die beiden entstandenen dateien (logconfig.txt + hosts.txt) hier rein posten. Bitte auch gleich mal in hosts.txt gucken und versuchen uns zu sagen, welcher von den hosts der ist, auf dem das betroffene drupal läuft (es war doch drupal, oder ? jedenfalls wars i-eine CMS).
Gutes Gelingen 
PS: Wenn DU den Apachedienst wieder am Laufen hast, erstellst mit den Bordmitteln der CMS ein Backup und setzt danach das System / die Repos sauber auf. Also so würde ich es machen. Es sei denn Du hast bereits ein aktuelles Backup - in dem Fall vergiss was ich geschrieben habe
Welche logs enthalten weitergehende Infos?
Wie ich bereits sagte - das hängt von der Apache Config ab.
1. Wie ist das Log Level ?
2. Wo logt Apache ?
3. Wo loggen eventuell weitere VHosts ?
4. und was weiss ich sonst noch
Mach doch einfach mal das was ich geschrieben habe und dann sehen wir weiter
PS: Wenn Apache wieder startet, würde ich aber auch dazu raten Dein Projekt zu sichern und vlt eine etwas integere Softwarestruktur aufzusetzen (Stichwort Repos) um da alles wieder einzuspielen. Du machst Dir wahrscheinlich das Leben damit bissel leichter 
Aber eins nach dem anderen.
Alles anzeigenAlso ich wüsste ja gerne was inden Logs steht.
Und die Ausgabe systemctl status apache2 - das sind keine logs (!) - das ist lediglich ein Teil den man wohl ebenfalls in den logs finden wird.
Je nach Konfiguration und Anzahl virtueller Hosts kann es durchaus mehrere Logfiles geben.
Jetzt versuch mal Folgendes
1. Finde die involvierten Conf Dateien heraus mit einem
Codeapache2 -V2. Suche in denen nach Protollanweisungen
Codecat file.conf | igrep log3. In einer dieser Log- Dateien wirst Du ganz klare Informationen finden und falls nicht das Loglevel nicht ausreichend
In dem Fall stellst Du das Loglevel auf Debug, reproduzierst den Fehler und suchst erneut in den Logs. Spätestens dann wirst Du sehr klare Informationen finden und das Problem ganz gezielt einkreisen können
Das habe ich aber schon einmal geschrieben.
Sollte es an Problemen liegen die durch dezent chaotisch gemischte Softwarequellen verursacht wurden, wird man auch das in den Logs finden können - denke ich zumindest. Spätestens dann, wenn man sich nach den Apache Protokollen dann die des Systems ansieht.
Das erste Ziel sollte es doch sein daß der Apache Dienst wieder läuft. Wenn man jetzt ganz viele Repos raus feuert und womögliche teilweise nicht ersetzt, könnte man dem Apache (oder dem darauf sitzenden php/drupal/DB whatever gemisch) schlimmstenfalls soweit den Rest geben, daß man wirklich nur noch alles neu installieren kann.
Hoffentlich gibst von dem Drupal (oder was immer er da laufen hat) ein aktuelles Backup
Ja, Du wirst wohl Recht haben - ich habe mir heute morgen einen anderen Screenherunter geladen der auch spontan funktioniert hat. Wahrscheinlich war der andere kaputt (den hatte ich ebenfalls neu herunter geladen).
Ähnlich überflüssig wird es dann wohl gewesen sein die Tastatur des Roots mit anzupassen Naja...
Aber Danke für die Info 
Grins, also bis das neue System alles hat was das ehemalige hatte/konnte ... werd ich sicher nochn bissel Spaß haben 
Und ne "Kleinigkeit an meinen beiden Testservern steht auch noch an
Naja, wenn alles immer out of the Box funktionieren würde wäre das ja langweilig (der Standard Spruch von meinem Ex- Abteilungsleiter)
Dir ein schönes WE 
Alles anzeigenDas sollst du auch nicht. Es geht lediglich darum, ob es überhaupt bei anderen Usern geht. Ist das der Fall, kann man dann bestimmte Files vergleichen / austauschen.
Was du aber noch testen kannst...
~/.config/kglobalshortcutsrc
~/.config/khotkeysrc
~/.config/kxkbrc
Abmelden, in einen echten Terminal wechseln, diese drei Files umbenennen (sichern) und wieder normal anmelden. Dabei werden diese, wie bei einem neuen User, neu estellt. Sollte es nichts bringen, stellst du sie einfach wieder her.
Also die Variante mit den Config Dateien hat nicht geklappt, aber kA... "echtes Terminal" ?
Hast du Yast - Hardware - System Tastatur Layout auch schon kontrolliert?
Ja, sollte richtig sein.
Naja, ich habe jetzt einfach als root in dessen systemeinstellungen auf kde die tastatur so eingestellt, wie sie nun auch für den user eingestellt war (nämlich entsprechend der ausgabe von localctl). diese theater von wegen "tote tasten" auch da raus genommen - neu gestartet - als user angemeldet und voila - die Null geht wieder
Ich habe mir durch diese blöde Null wegen fehleingaben schon einen Zugang versperrt weil mich mein eigenes fail2ban nicht mehr auf den server lässt 
schon komisch daß ich die systemeinstellungen für den user und root synchron halten muss, damit sie beim user greifen. das hatte ich auch bei dem wechsel des SDDM Anmeldebildschirms, wo ich ein anderes Wallpaper rein gemacht habe. Wahrscheinlich liegt das an der permission.secure regel
Ich glaube auch daß ich das problem mit der NULL seit dem tastaturwechsel bereits hatte, es mir aber vorher nicht aufgefallen ist.
Es läuft jedenfalls wieder.
Ein ganz liebes Danke fürs helfen
PS:
"ibus" installiert?
Dieses Paket kann u.U. solche Probleme verursachen.
Nein, Ibus ist nicht installiert. Aber laut Paketbeschreibung könnte es das Problem theoretisch lösen...
Probleme nur unter diesem Account?
Mal testweise einen neuen User anlegen und vergleichen...
Interessante Idee - der Root hat diese Probleme nicht. Ich habe also die Tastatur unter Systemeinstellungen zwischen den beiden Accounts abgeglichen undneu gestartet - hat nix gebracht. Was "dead Keys" sein sollen ist mir unklar, ich habe bei dem betroffenen Account ein "ohne Akzenttasten" daraus gemacht. Naja, wie gesagt - nix gebracht. Die angepasste Tastatureinstellung (101 Tasten, Generic) passt aber nicht zu der folgenden Ausgabe (auch wenns beim Root klappt mit der Null):
localectl status
System Locale: LANG=de_DE.UTF-8
VC Keymap: de-latin1
X11 Layout: de
X11 Model: pc105
X11 Options: terminate:ctrl_alt_bkspEs kann jedenfalls nicht sein, daß ich wegen einer Tastatureinstellung einen Benutzer löschen und neu anlegen soll - ich habe in diesem Desktop schon ohne ENde Arbeit rein gesteckt - das muss auch anders und "ohne Gewalt" zu lösen sein
Typ Application/Shellscript mit Anwendung bin/bash verknüpft - alles wieder gut
hab ich geändert - neu gestartet - brachte nichts. Die Akzente haben übrigens auch vorher schon funktioniert. Und was mich sehr wundert - die interne Tastatur des Laptops verhält sich genau so krank wie die externe. Ich glaube nach wie vor nicht daß es die Hardware ist - 4 Tastaturen - alle kapuut ? Neee....
Hallo Zusammen,
ich habe unter ~/bin einige ausführbare Scripts, die über Autostart gestartet werden und auch funktionieren - ohne die Ausführung im Terminal.
Seit heute starten die aber nicht mehr wenn ich sie anclicke, was sie vorher getan haben. Da kam immer ein PopUp was gefragt hat ob ich es ausführen soll - hab dann "Ja" geclickt und das Script lief.
Das klappt jetzt aber nicht mehr. Gestern abend habe ich im Desktop auch irgendwie an den Eigenschaften des Dateityps .desktop herum gespielt aber leider kA was ich da gemacht habe oder wie das vorher war 
So sehen die Einstellungen aus:
Die Autostart- Funktion scheint keine Probleme zu haben - die Scripts werden definitiv nach der Anmeldung ausgeführt - ohne Terminalfenster so wie es sein soll. Aber das sollen die eben auch wenn ich drauf clicke