Dark_Wolf
Anmeldungsdatum: 12. August 2006
Beiträge: 2594
Wohnort: Linuxland
|
Hallo Leute, nach einer internen Umstellung des LDAPserver (nach 12 Jahren darf ja wohl mal) bekommen wir hier auf 2 Servern komische Meldungen. Sprich die genannten Services von Systemd starten nicht. Die beiden unten genannten Server hatten vorher eine LDAPanbindung. Jetzt nicht mehr, da nur ein Rootzugriff auf der CMD erforderlich ist. Alle LDAPpakete wurde inkl. Config deinstalliert. Sudo-ldap wurde wieder durch sudo ersetzt. Beide Server up2date. Server1 Ubuntu 18.04 für Postgresql
Unit user@122.service has begun starting up.
Aug 22 23:20:35 odoo systemd[9563]: pam_unix(systemd-user:session): session opened for user postgres by (uid=0)
Aug 22 23:20:35 odoo systemd[9563]: Failed to fully start up daemon: Permission denied
Aug 22 23:20:35 odoo systemd[9564]: pam_unix(systemd-user:session): session closed for user postgres
Aug 22 23:20:35 odoo systemd[1]: user@122.service: Failed with result 'protocol'.
Aug 22 23:20:35 odoo systemd[1]: Failed to start User Manager for UID 122.
Ich darüber jetzt nicht viel gefunden, zumindest nichts das ich jetzt irgendwie verstehen würde. Der Server funktioniert auch ganz normal. PGSQL tut seinen Dienst. Und wieso "Permission Denied"? Wo will da denn was drauf zugreifen? Das Systemdservice dazu sieht so aus:
[Unit]
Description=User Manager for UID %i
After=systemd-user-sessions.service
[Service]
User=%i
PAMName=systemd-user
Type=notify
ExecStart=-/lib/systemd/systemd --user
Slice=user-%i.slice
KillMode=mixed
Delegate=pids cpu
TasksMax=infinity
TimeoutStopSec=120s Das gleiche Problem gibt es auch noch bei einem Ubuntu 16.04 Server seit der Umstellung. Dort betrifft die gleiche Fehlermeldung auch noch einen Webuser. Funktion des Servers aber auch dort normal. Vielen Dank und glg
Dark Wolf
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Greppe doch mal die Konfigurationen (also die Units) nach dem ominösen User, bzw. suche die 122.service. Ggf. ist auch eine ·User-Unit unter ~/.local/share/… aktiv?
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2594
Wohnort: Linuxland
|
Das hab ich schon gemacht. Nichts gefunden. Weder mit locate noch mit find. Sehr eltsam. Ich kann das Service auch nicht deaktivieren, da es "statisch" ist.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
ExecStart=-/lib/systemd/systemd --user sagt ja, dass er eine UserUnit anlegt für den %i-User. Gibt es den noch im /home oder in der /etc/passwd? Ich weiß auch gerade nicht, wo systemd seine Namen herbekommt. Morgen gucke ich gerne mit dir weiter ☺
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Dark_Wolf schrieb: […]
Das Systemdservice dazu sieht so aus:
Welche Datei in welchem Verzeichnis ist das? Was zeigt: getent passwd 122 ; echo $?
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2594
Wohnort: Linuxland
|
kB schrieb: Dark_Wolf schrieb: […]
Das Systemdservice dazu sieht so aus:
Welche Datei in welchem Verzeichnis ist das? Was zeigt: getent passwd 122 ; echo $?
Ja es ist Postgre, wie schon oben beschrieben.
postgres:x:122:128:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash 0
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2594
Wohnort: Linuxland
|
ChickenLipsRfun2eat schrieb: ExecStart=-/lib/systemd/systemd --user sagt ja, dass er eine UserUnit anlegt für den %i-User. Gibt es den noch im /home oder in der /etc/passwd? Ich weiß auch gerade nicht, wo systemd seine Namen herbekommt. Morgen gucke ich gerne mit dir weiter ☺
Danke ☺
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Also. Mal in Kürze: systemd hat definitiv zu viele Wrapper und bearbeitet viel zu viele Konfigurationen - da blicke ich nicht durch 😀 Was mich wundert ist, dass dein psql einwandfrei funktioniert. Kannst du im laufenden System mal mittels systemd-cgls prüfen, ob es eine user-Unit für 122 gibt? Mögliche Ursachen gibt es offenbar viele. psql-Konfiguration, später eingebundene externe Verzeichnisse, besagte userconfigs , usw. Blöd ist, dass psql selbst einen "Wrapper" benutzt und die eigentliche Service-Unit nur ein /bin/true aufruft, die eigentliche Arbeit ist in einer .target-Unit, welche pro Instanz gestartet wird. Preisfrage: Was habt ihr beim Wechsel auf systemd alles manuell geändert? ☺
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2594
Wohnort: Linuxland
|
Hallo, und vielen Dank für dein Bemühen. Und ja, Systemd ist zwar cool, aber auch komplex. a Eine user-Unit für 122 gibt es nicht. Die einzige Änderung die es gab war das die LDAPschiene ausgetauscht wurde. Davon waren natürlich alle Server und Clients betroffen. Der Server fährt hier Odoo, eine manuelle Änderung gab es in PGSQL nicht. Auch nicht in der besagten Systemdkonfigurationsdatei. Ich hab dann zum Test auch mal den Postgresql runter geworfen und nochmal drauf gespielt, Fehler bleibt da bestehen. Das ganze läuft jetzt unter KVM. Viel verfrachte ich das ganze einfach auf nen LXC. Dann ist es frisch und der Fehler wird auch weg sein. Geht aber leider nicht bei dem 16.04 Server. Der beherbergt ein fettes Virtualmin mit allen Features und steht auch öffentlich. Daher möchte ich den Fehler natürlich gerne beheben. Oder dahinter kommen warum das nun so tickt. Ne ganz andere Frage: Hat jemand von euch schon mal mit dem Prosupport von Canonical zu tun gehabt. Würde sich bei solchen Konzelationen die Subscription auszahlen? Vermutlich supporten die nur die Pakete wo eine Ubunturose drauf ist. Sprich dann müsste man sich zuerst auch mal danach richten.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Dark_Wolf schrieb: Eine user-Unit für 122 gibt es nicht.
Ja, doch. Die gibt es automatisch für jeden loginfähigen User (siehe deine Unit oben: user@.service). Die Frage ist ja, wieso die failed, bzw. in dem Fall, unter welchem User Postgre läuft, wenn nicht als postgre-User. Was sagt denn ein systemctl list-dependencies postgresql ?
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2594
Wohnort: Linuxland
|
Ok, sehr stange. postgresql.service
● ├─postgresql@10-main.service
● ├─system.slice
● └─sysinit.target
● ├─apparmor.service
● ├─blk-availability.service
● ├─dev-hugepages.mount
● ├─dev-mqueue.mount
● ├─keyboard-setup.service
● ├─kmod-static-nodes.service
● ├─lvm2-lvmetad.socket
● ├─lvm2-lvmpolld.socket
● ├─lvm2-monitor.service
● ├─open-iscsi.service
● ├─plymouth-read-write.service
● ├─plymouth-start.service
● ├─proc-sys-fs-binfmt_misc.automount
● ├─setvtrgb.service
● ├─sys-fs-fuse-connections.mount
● ├─sys-kernel-config.mount
● ├─sys-kernel-debug.mount
● ├─systemd-ask-password-console.path
● ├─systemd-binfmt.service
● ├─systemd-hwdb-update.service
● ├─systemd-journal-flush.service
● ├─systemd-journald.service
● ├─systemd-machine-id-commit.service
● ├─systemd-modules-load.service
● ├─systemd-random-seed.service
● ├─systemd-sysctl.service
● ├─systemd-timesyncd.service
● ├─systemd-tmpfiles-setup-dev.service
● ├─systemd-tmpfiles-setup.service
● ├─systemd-udev-trigger.service
● ├─systemd-udevd.service
● ├─systemd-update-utmp.service
● ├─cryptsetup.target
● ├─local-fs.target
● │ ├─-.mount
● │ ├─systemd-fsck-root.service
● │ └─systemd-remount-fs.service
● └─swap.target
● └─dev-disk-by\x2duuid-6e426d3e\x2db109\x2d45f1\x2da964\x2df6f8822b5d5b.swap
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ja, strange, aber eine kurze Suche nach dem Befehl ergab das hier: postgresql-server-doesnt-start Was mich jetzt auf die Idee bringt das bei dir mal zu prüfen mit deiner Version. Ich sehe, du hast deinen Beitrag gerade geändert. Wir haben also postgresql@10-main.service als "echtes PGSQL". Wird vermutlich von root gestartet, nicht vom eigentlichen Nutzer, so wie es aussieht. Falls der Benutzer gar nicht gebraucht wird, dann wäre die Fehlerbehebung einfach: In der /etc/passwd die shell von /bin/bash auf /bin/false setzen. Eine korrekte Lösung wäre natürlich den Fehler zu beheben, so dass PG wieder unter seinem Nutzer läuft und die user@122 sauber startet. Erklärt aber zumindest, wieso die DB läuft, obwohl der Nutzer keine eigenen Prozesse haben kann ☺
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2594
Wohnort: Linuxland
|
Hab ich getestet. Ein false ändert nichts. Postgresql startet nicht mit root sondern mit seinem eigenen Benutzer: postgres 781 0.0 0.6 320584 27336 ? S 23:49 0:00 /usr/lib/postgresql/10/bin/postgres -D /var/lib/postgresql/10/main -c config_file=/etc/postgresql/10/main/postgresql.conf
Komischerweise startet der Postgresql dann ganz normal und Odoo geht auch. Nur im CheckMK Monitoring ist es dann finster. Beim 16.04 gleich. Aber, der eine Apacheuser den ich dann die False-Shell gegeben habe, der meldet sich nun nicht mehr.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Gut, bei 16.04 muss man noch mal separat gucken. Da war systemd nur "teilintegriert" und die meisten Dinge liefen wohl im Hintergrund noch wie zuvor. PG wird dann wohl von root über systemd gestartet werden, mit den Rechten vom user postgres, da dieser ja definitiv keine eigenen Units startet. Ist also wohl wirklich nur ein "Schönheitsfehler". Wie sieht denn die postgresql@10-main.service aus? Ist in der Konfiguration von PG der Nutzer fest angegeben?
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2594
Wohnort: Linuxland
|
So. Hab nun den Server komplett frisch aufgesetzt. LXC ohne ein selbst gebasteltes Template. (vorher war es eine KVM) und... der gleich Fehler tritt wieder auf. Fazit: Da läuft anscheinend der PGSQL nicht richtig bei Ubuntu. Nur PGSQL ist ok, so bald ne Datenbank drauf ist, ists aus die Maus. Der andere Server war mittlerweile so kaputt das es Kernelpanic, immer wieder Dateiystemschaden usw. gab. Mir ist das ein Rätsel. Und jetzt ganz neu und wieder ein Fehler? Hmm, schreit nach Bug, obwohl ich nichts in der Richtung gefunden habe. Kann nur noch sein das sie Ubuntu+PGSQL+Odoo nicht verträgt. glg ☺
|