Hi Ingo,
On Fri, Mar 19, 2010 at 23:13:28 +0100, Ingo Jannick wrote:
Ich moechte screen als Loginshell nutzen: kein Problem - ab damit in /etc/passwd, bein einloggen kommt die Session hoch,
Auf screen als Loginshell verzichte ich aus folgendem Grund: Beim lokalem oder remote Login ist nie eindeutig entscheidbar, ob man eine neue Session haben will, oder ob eine bereits laufende detached/reattached werden soll. Wenn man immer die bereits laufende Session uebernimmt, kann das Environment darin zu alt sein (z.B. falsch gesetzte DISPLAY oder SSH_AGENT_PID).
allerdings moechte ich die Screen-Session schon beim booten starten, und dann da gleich noch schwuppdiwupp ein paar kleine Prograemmchen, die dann nett in den einzelnen Fenstern ihren Text schreiben.
Das hat zunaechst mal nichts mit Logins zu tun.
Aber da steckt der Floh: Sie meint dann immer zu mir, dass screen keine Konsole hat (/dev/console oder /dev/pts/1 ...), und startet die screen Session nicht (screen -m -d -U -S pommeranze )
Die Frage ist: Wann genau wird das rc.local-Skript beim Booten ausgefuehrt? Die verschiedenen Distributoren haben bezueglich des Zwecks von rc.local durchaus unterschiedliche Ansichten. Wird es zu frueh ausgefuehrt, kann das devpts-Pseudodateisystem tatsaechlich noch nicht gemountet sein.
Ansonsten wuerde ich etwa in Debian eher ein eigenes Initskript verwenden und dieses ueber einen passenden Snn-Symlink im Default-Runlevel starten. In Ubuntu ist durch Verwendung von Upstart statt SysV-Init die Reihenfolge der Init-"Skripte" nicht mehr fest, sondern ergibt sich aus den Abhaengigkeiten, die man angeben muss. Wie Redhat und SuSE aktuell beim Booten Dienste starten... keine Ahnung.
Wenn devpts zu dem Zeitpunkt vorhanden ist, sollte folgendes Fragment in einem Initskript funktionieren:
su -c "screen -d -m -c /pfad/zur/screenrc" username
Gruss, Chris