The way that you're going right now, you're going to surprise a lot of people, possibly not pleasantly, in a little while. You've presented this as a replacement of agetty and login. But the use cases of getty+login and what you're doing are somewhat different. People expecting to get a systemd-consoled system that behaves the same as virtual terminals with gettys on them are going to instead get a system that operates somewhat differently, the way that you're going.
What you're looking at doing follows the GUI model of a single "greeter" session that spawns other "user" sessions running systemd-consoled after the "greeter" has completed a login dialogue. The TUI model of VTs+gettys, even as modified by systemd-logind, in contrast has multiple "greeter" sessions that (conceptually) exec into "user" sessions once /bin/login has spawned a login shell. In other words: What people expect from the TUI system is multiple (systemd-logind) sessions, each with an individual login dialogue, and each of which, serially, can comprise multiple login sessions (switch to systemd-logind session #3, log in as user A, do things in a user A login session, log out, log in as user B, do things in a user B login session, log out). What you're actually going to give them instead is one single login dialogue in a "greeter", which spawns a new (systemd-logind) session that can only comprise a single login session. There's nothing inherently wrong with this. In fact I did a similar design myself some years ago, for that non-Linux system that I mentioned. But you are going to surprise people who think that you're going to give them an it-works-just-like-init+getty+login-did TUI login system. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
