Systemd and ConsoleKit

[Posted May 4, 2011 by corbet]

From:		Lennart Poettering <lennart-AT-poettering.net>
To:		systemd Mailing List <systemd-devel-AT-lists.freedesktop.org>
Subject:		[RFC] merging the rest of CK into systemd
Date:		Tue, 3 May 2011 00:52:17 +0200
Message-ID:		<20110502225217.GA21418@tango.0pointer.de>
Archive‑link:		Article

Heya,

here's a little document Kay and I put together outlining our rough
plans for systemd for the next Fedora cycle:

https://docs.google.com/document/d/1_ev4f0gwBuvs6SH_N8fN5...

It mostly focusses on cleaning up seat and login management for users,
i.e. the first big steps in bringing systemd to user sessions. On the
way want to fix multi-seat support properly and running services outside
of a session, and we will get rid of CK.

The good news for embeded folks: all of this will be implemented in a
tiny new dbus service "systemd-logind", which can easily be removed for
minimal setups, when tracking unprivileged user logins is unnecessary.

Anway, we post this here as RFC, and to give you folks an idea what
we'll do next.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

to post comments

Systemd and ConsoleKit

Posted May 4, 2011 14:42 UTC (Wed) by paravoid (subscriber, #32869) [Link] (8 responses)

Google Docs used to facilitate free software development. Oh dear

Systemd and ConsoleKit

Posted May 4, 2011 14:50 UTC (Wed) by epa (subscriber, #39769) [Link] (4 responses)

When I click on the link I get a page telling me to sign up for Google Docs. Don't they provide a read-only interface for public viewing?

Access

Posted May 4, 2011 14:54 UTC (Wed) by corbet (editor, #1) [Link] (2 responses)

There was a complaint on the mailing list too, but it's supposed to be accessible to all. There seems to be some sort of weirdness that a few people are running into, though.

Access

Posted May 4, 2011 15:06 UTC (Wed) by spaetz (guest, #32870) [Link]

It asks for user login when it detects an old google cookie (not being logged in). When properly logging out via "log in as a different user", it shows the document just fine.

At least that was the case for me. Which is a weird behavior.

Access

Posted May 4, 2011 18:12 UTC (Wed) by ohj (guest, #54089) [Link]

Trying to access the document while denying cookie access for google.com
seems to trigger the login prompt too. Permitting the cookie lets me
view the document.

Systemd and ConsoleKit

Posted May 4, 2011 14:57 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

I just pasted it into Opera (with which I've never signed into google), and it worked fine, so whatever issue existed has clearly been resolved.

Systemd and ConsoleKit

Posted May 4, 2011 15:18 UTC (Wed) by mjw (subscriber, #16740) [Link] (2 responses)

It doesn't really seem to scale...

"There are currently too many people viewing this document. Please try again later."

Systemd and ConsoleKit

Posted May 4, 2011 15:46 UTC (Wed) by intgr (subscriber, #39733) [Link] (1 responses)

Google doesn't scale? That's a surprise.

But yeah, there seems to be a limit of 48 simultaneous viewers, sucks.

Systemd and ConsoleKit

Posted May 4, 2011 17:01 UTC (Wed) by Otus (subscriber, #67685) [Link]

That's because Google advocates "share as a web page" for wider sharing. That is lighter on their servers, but this document wasn't published that way.

http://docs.google.com/support/bin/answer.py?answer=183965

multiseat

Posted May 4, 2011 14:55 UTC (Wed) by eean (subscriber, #50420) [Link] (6 responses)

Currently multiseat feels like sort of a hack, since you have to write your own xorg.conf. So its good to see a move towards making this feature user visible.

Slightly scared about the talk of needing to write hal rules though...

multiseat

Posted May 4, 2011 15:05 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (5 responses)

Hal? No hal. It isnt mentioned in the text and that has a reason: it is dead.

multiseat

Posted May 4, 2011 15:41 UTC (Wed) by HelloWorld (guest, #56129) [Link] (4 responses)

hal _is_ mentioned in the text.

multiseat

Posted May 4, 2011 15:51 UTC (Wed) by eean (subscriber, #50420) [Link] (2 responses)

Yea, though now I can't prove otherwise since 'too many people are viewing the document'.

But anyways obviously if pottering says it doesn't use HAL then it wouldn't. So that's good. Certainly though you need some way to establish which mouse goes with with seat. Unless you have the esoteric hardware it references that's impossible to do automatically.

multiseat

Posted May 4, 2011 15:53 UTC (Wed) by eean (subscriber, #50420) [Link]

*Poettering

multiseat

Posted May 4, 2011 16:09 UTC (Wed) by eean (subscriber, #50420) [Link]

Ah okay, I meant udev.

multiseat

Posted May 5, 2011 1:03 UTC (Thu) by elanthis (guest, #6227) [Link]

It just mentions HAL as an example of a transition. Basically, it says switching out CK should be easier than switching out HAL was. That's it.

Systemd and ConsoleKit

Posted May 4, 2011 16:05 UTC (Wed) by josh (subscriber, #17465) [Link] (37 responses)

Pasting the full contents of the Google Docs document here, to work around the 48-anonymous-viewer limit and any access problems people have had. It seems safe to assume that the authors of the document don't have a problem with redistribution. :)

systemd work for the session

Goals:

Simplify our stack by removing CK
Automatic multi-seat support
Make systemd available in the session
Removal of XDG_SESSION_COOKIE and its security problems, emphasis on audit loginuid and cgroup names instead
On-Demand starting of VT gettys
Fix the 63 threads issue
Covering all of getty, SSH and X11 sessions
Make session exit of pam_systemd more robust
Introduce D-Bus user bus
allow systemd user services to be run outside of a session, for selected users, a la cron with cron.allow

Current ConsoleKit features:

Registration of user sessions and seats storing of meta data
fast user switching
shutdown/reboot handling
Logging of user logins/logouts
udev integration to do device node ACLs
PK integration to verify console access to certain functionality

Logging currently is done 6 times (neither are indexed, except for utmp and lastlog which are indexed by uid):

utmp
wtmp
syslog
audit
ConsoleKit logs
lastlog

Plans:

Introduce seat tags on video, input, audio, other devices in udev
Make X11 check those tags. This requires a simple patch, i.e. udev_monitor_filter_add_match_tag(), based on the tag name passed on the X command line; if no seat name is given on the command line, pick up all devices without seat tag, to mimic current behaviour
gdm will spawn one X server for each video card found as they pop up, X itself should discover matching input devices
plymouth should also make use of all video cards and input devices found, as they pop up, and and terminate as soon as gdm takes over, plymouth should ignore seat assignments however, and act on all display and input devices
A tiny udev rule will try to automatically assign seat tags for devices manufactured by Plugable. Other hardware in the beginning will require writing udev rules manually. Eventually a UI for this should be written which spits out and installs udev rules.
Most of the logic in pam_systemd will move into a tiny bus service, and which will hand out leaking pipe fds to detect when the session ends, the same way pam_consolekit_connector works right now, but built around dbus fd passing
This bus service will have a similar interface to CK, however do a few key things differently: no cookie management (rely on audit login uid instead), listening on /sys/class/tty/tty0/active, on-demand triggering of gettys (or any other service), when an allocated VC with no process is activated. VCs will be handed out strictly based on a first-come first-serve basis, no fixed mapping anymore -- except for tty1. We will pre-allocate 12 ttys by default, but not start anything on them. If X needs another tty it just takes the next free one. If a tty is activated (by keypress) which currently has no client we will start a getty on it. That means by default we run zero gettys on a graphical boot, but they become instantly available as soon as the user switches ttys.
There will be no public CK database. However we will provide a tiny library (drop-in or .so) which allows NM, PK and D-Bus query whether a PID or user is currently on an active sesssion without involving D-Bus, as fast path for auth checks
udev-acl will move into this dbus service
Separate bus service for shutting down/rebooting/suspending the system, with integration into PK and which checks whether sessions are left open
Well introduce the D-Bus user bus, as discussed with various folks at the GNOME Summit last year, and redirect the session bus to it
We will implicitly spawn a systemd instance for each user on first login, and remove it at last logout. Lifetime of XDG_RUNTIME_DIR, the user cgroup, the user bus and the systemd instance are bound together
Ideally, X would start to listen on $XDG_RUNTIME_DIR/display or a similar socket. Could be default for clients if no $DISPLAY is set. Alternatively symlink hackery
We will focus on Linux and Linux only
Introduction of PR_SET_ANCHOR and usage in g-s/systemd, to ensure that all user processes are children of systemd/g-s and not detached
gnome-session will mostly stay as it is for now, however will use the user bus if it exists
Most likely drop support for CK history log files. Only user appears to be gdm and accountsservice. option 1) move this into gdm itself, so that gdm shows its own most frequent users only; option 2) use wtmp for this, which while ugly to use offers mostly the same functionality. If we need more metadata than wtmp can provide, hijack the 20 unused bytes at the end of each utmp record. If eventually we reintroduce log files for this, then we should do this in a really convincing fashion, i.e. indexed, with live querying support and suchlike
Optionally start user session (without display) already on system bootup, to permit timer-based cron-like user-code to run, or to run network services independent of an actual login. This will be strictly optional and only permitted for users with a flag file in /var/lib/systemd/user/xxx. Flag files controllable via PK, yadda yadda
Note that there is no static configuration of seats. The tiny dbus service will provide a list of current seats only based on the udev database: if theres a display device with a seat tag, then this seat exists, otherwise it doesnt
Seats and seat names will automatically be generated for Plugable devices based on their udev path id. i.e. by plugging in a plugable device a dynamic seat seat-pci-0000-00-1f-2-usb-4711-0815 (or something like that) is generated and exists exactly as long has it is plugged in.
No stored CK database as public API, instead store everything we need in memory, and export only very few things in the fs, for example to allow fast perm checks for dbus/NM/PK
Embedded folks can work without the bus service, to get old-style behaviour

Perspective for F17:

In F17, we might want to move user service/process handling from g-s to systemd, and get a definition of running application along the lines of the cgroups for them, which transcends all layers of our stack, from kernel to the UI; an application that isnt running is simply a .desktop file, and when it runs it is the cgroup by the same name
keep in focus for later: support multi-session and session switching on secondary VGA cards, in userspace

Transition:

We will ensure CK and the new scheme can run side-by-side. Only the ACL management of CK will be disabled when the new scheme is enabled
Phase-out similar to HALs, leave things running side-by-side but port important things over quickly. Should be much easier than HAL, since less code uses it

External patches:

udev: disable udev-acl
X11: add seat support (check for tags)
X11: make x11 XDG_RUNTIME_DIR-aware
gdm: for libudev support and new seat registration
plymouth: for libudev support
dbus: for new active session detection
PK: for new active session detection
NM: for new activte session detection
accountsservice: for new login history logs
kernel: PR_SET_ANCHOR
kernel: xattr on cgroup
kdm, other dms: drop CK support. Quite possibly the PAM session hooks are sufficient for our needs, no need for patching in new support into dms

Questions left unanswered:

What about idle hint stuff?

Where is what?

CKs seat management and session switching is pushed into new tiny bus service systemd-logind (or similarly named)
CKs logging is removed, and utmp/wtmp used instead
CKs shutdown/reboot handling moves into new tiny bus service systemd-rebootd (or similarly named)
udev-acl will move into systemd-logind
most of pam_systemd will move into systemd-logind

Effective new features by doing this:

Automatic Multi-Seat
Running user services outside of session
gettys only spawned on demand
synchronization on VGA discovery can be dropped → faster bootup
Cleaner PS tree
D-Bus/systemd available for user logins

Systemd and ConsoleKit

Posted May 4, 2011 16:10 UTC (Wed) by jubal (subscriber, #67202) [Link] (27 responses)

in short: tie everything that's possible to systemd, the one and only init system.

Systemd and ConsoleKit

Posted May 4, 2011 16:26 UTC (Wed) by bredelings (subscriber, #53082) [Link] (1 responses)

Hear, hear. I like systemd's approach to starting services better than either (i) upstart or (ii) sysvinit.

However, this sounds more like lock-in. Why is it "simpler" to get rid of other ConsoleKit? (As opposed to, say, simplifying it?)

Systemd and ConsoleKit

Posted May 4, 2011 16:56 UTC (Wed) by raven667 (subscriber, #5198) [Link]

I would say that the existing sysvinit system already handles spawning X and gettys on terminals but has a lot of missing features that required the creation of ConsoleKit and other utilities. I don't see why this wouldn't be in the purview of systemd and it seems that if the services that ConsoleKit provides can be more cleanly or easily implemented as part of the systemd suite then that seems like a good idea.

It seems when systemd is the default then there will be many tens of thousands of lines of code made redundant, greatly simplifying daemon and session management and finishing the train of thought that init and inetd started but were forced to halt as *nix became "standardized".

Systemd and ConsoleKit

Posted May 4, 2011 16:53 UTC (Wed) by mjthayer (guest, #39183) [Link] (7 responses)

> in short: tie everything that's possible to systemd, the one and only init system.

Does this mean that multi-seat will only be available on systems using systemd, or will it be feasible for other init systems to handle the necessary bits too without unreasonable effort? systemd sounds great to me, but I would prefer to see it adopted on its merits rather than because it is suddenly the only replacement for a piece of infrastructure everyone depends on.

Systemd and ConsoleKit

Posted May 4, 2011 17:01 UTC (Wed) by raven667 (subscriber, #5198) [Link] (5 responses)

I can't see that ConsoleKit will magically stop working on systems not using systemd if systemd has features that make it redundant. Ubuntu for example has a lot invested in Upstart and probably won't be switching any time soon. Those features will continue to be developed as long as it still makes sense to do so.

No one is forcing distros to switch to systemd though, it is being adopted widely and quickly on its merits. It seems to be replacing not only sysvinit but tens of thousands of lines of shell scripting as well as tools like daemontools/runit, monit, maybe even ucspi-tcp and now ConsoleKit with a smaller, simpler and more robust system which seems like a very good thing.

I'm excited about it anyway :-)

Systemd and ConsoleKit

Posted May 4, 2011 17:13 UTC (Wed) by mjthayer (guest, #39183) [Link]

> I can't see that ConsoleKit will magically stop working on systems not using systemd if systemd has features that make it redundant. Ubuntu for example has a lot invested in Upstart and probably won't be switching any time soon. Those features will continue to be developed as long as it still makes sense to do so.

So in other words, people who don't want to adopt systemd will likely take over collective maintenance of ConsoleKit. Sounds reasonable if the current maintainers go along with that in some way.

> No one is forcing distros to switch to systemd though, it is being adopted widely and quickly on its merits.

As I said, I would be more than happy to see that happen.

Systemd and ConsoleKit

Posted May 4, 2011 18:11 UTC (Wed) by jubal (subscriber, #67202) [Link] (3 responses)

I'm excited about it anyway :-)

I'm a bit more cautious here. Perhaps because of a somewhat interesting systemd developers' attitude [I'm not particularly fond of the «we've seen the truth, so it's our way or highway» methodology of engaging the end-users (the end-users being in this case daemon developers and packagers)].

Systemd and ConsoleKit

Posted May 4, 2011 21:42 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Although to be fair in this case, they already included the needed functionality to handle this use case even though the stated preference was for the daemon to handle this kind of checking and init by itself.

Heck, I've run DJB software for the last decade, developers who have "seen the truth" don't scare me :-)

Systemd and ConsoleKit

Posted May 5, 2011 0:35 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (1 responses)

Really, you don't want to allow us a belief how service should best be written?

I mean seriously, if we wouldn't have an opinion on that, i.e. a vision how things should be done in an ideal world, then we'd be useless as software designers.

Systemd and ConsoleKit

Posted May 5, 2011 21:11 UTC (Thu) by Wol (subscriber, #4433) [Link]

AOL :-)

It's the self-opiniated developer, convinced that he's right, that either races down a dead end to oblivion, or drags everyone after him kicking and screaming that they "don't want to be forced to do the right thing"!

Look at me - much as I find relational theory very useful, I think relational *technology* is a dead end - a cancerous waste of resources that *cannot* work - because it ignores reality.

Am I going to drag everyone down the road I want? I'm not a Poettering, I don't think I'm going to pull it off. But it's people like him, people like me, who make others re-evaluate. And I must admit, I like Poettering's approach - "it'll only work properly if it's done right". Why *shouldn't* he take broken stuff, and break it even more? If the end result is things actually work properly, then well done!

Cheers,
Wol

Systemd and ConsoleKit

Posted May 4, 2011 20:24 UTC (Wed) by eean (subscriber, #50420) [Link]

multi-seat is already something you can do. Systemd supporting it doesn't take away the setting it up with xorg.conf manually.

Systemd and ConsoleKit

Posted May 4, 2011 18:14 UTC (Wed) by glikely (subscriber, #39601) [Link] (1 responses)

Wait. Does that mean it's the Master Control Program?

Systemd and ConsoleKit

Posted May 5, 2011 3:23 UTC (Thu) by jcm (subscriber, #18262) [Link]

Awesome :)

Systemd and ConsoleKit

Posted May 5, 2011 0:29 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (14 responses)

systemd is an offer. You don't have to take it. You can continue to maintain CK and all the other stuff if you want. Nobody stops you. I am currently doing most of the maintenance work for CK but I am happy to pass it on to a capable person who's into maintaining legacy software.

I am kinda allergic of allegations we'd force things down on anybody's throat by integrating things. That's impossible in a free software world and kinda insulting too, because we make you a free offer, and it's completely up to you to take it or not.

It is much easier for us to provide these things in systemd, since it allows us to bind seat info to the session info we already maintain for users in cgroups. Doing these things in code we ship with the same package his hence really simple and requires very little code. (Note that all this seat/session management is done in an auxiliary service -- a process with a PID != 1. You can strip it out easily (and you absolutely want to do that for embedded uses, actually).

If you keep things separate just to keep things separate you add a lot of work and a lot of duplicate code and make it very difficult actually doing the perfect 1:1:1:1 linking of the user cgroup, the XDG_RUNTIME_DIR, the user systemd and the user bus. Also, what benefit would it bring us (the developers) to keep things separate? It's a simple fact that the folks who'd benefit from that (i.e. the Upstart fans) wouldn't say "Thank you" anyway (they'd much more likely find something else to bitch about), so why should we bother?

You know, tieing this to systemd makes things a lot easier for us and the end product much simpler. That's the reason why we are doing this. While I actually do believe that systemd is the one and only init system (hey, I can be proud about the stuff I wrote can't I?) using that as the the only reason, or a reason at all would be pretty bad technical decision making.

Also, we are not the only ones who can write code. If you think you can do it better and have better ideas, then do it better, but don't complain if we try to bring Linux forward.

Lennart

Systemd and ConsoleKit

Posted May 5, 2011 9:47 UTC (Thu) by mjthayer (guest, #39183) [Link]

> I am kinda allergic of allegations we'd force things down on anybody's throat by integrating things. That's impossible in a free software world and kinda insulting too, because we make you a free offer, and it's completely up to you to take it or not.
Subject to your making it easy for someone else to take over ConsoleKit maintenance if they wish I couldn't agree more.

Systemd and ConsoleKit

Posted May 5, 2011 11:09 UTC (Thu) by marcH (subscriber, #57642) [Link] (12 responses)

I hope you know the real world is not that simple. If it were then everyone would build its systems from scratch and distributions would not even exist.

Granted, free software reduced friction and increased flexibility by several orders of magnitude. It is a brand new world full of possibilities. But it is still infinitely more difficult to select software than walk into B&Q and search the shelves for great "offers". And it always will be.

I sincerely hope your disconnection with mere mortals/basic users is not that bad.

Systemd and ConsoleKit

Posted May 5, 2011 12:14 UTC (Thu) by anselm (subscriber, #2796) [Link] (11 responses)

I sincerely hope your disconnection with mere mortals/basic users is not that bad.

Come on. System V init isn't going away any time soon if you want to hang on to it. Chances are that you will always be able to use Slackware, after all, even if at some point most other distributions (ignorant and misguided as they are) will have drunk the systemd Kool-Aid.

I'd say that if Lennart wants to waste the rest of his life getting systemd to work in the »real world« that's up to him. It seems to me personally that he has the bases pretty much covered already but then I'm only another mere mortal.

Systemd and ConsoleKit

Posted May 5, 2011 12:42 UTC (Thu) by marcH (subscriber, #57642) [Link] (10 responses)

This discussion thread was about CK, not System V.

Systemd and ConsoleKit

Posted May 5, 2011 13:24 UTC (Thu) by anselm (subscriber, #2796) [Link] (9 responses)

OK, my bad. I was under the impression that Lennart was talking about systemd and ConsoleKit together. His point that he was making a free offer that people may take or leave certainly applies to both of them.

Systemd and ConsoleKit

Posted May 5, 2011 14:42 UTC (Thu) by marcH (subscriber, #57642) [Link] (8 responses)

Yeah, just as free as his free offer to "... maintain CK and all the other stuff if you want".

You could argue with users heavily depending on CK (or ALSA hacks, or System V, or else) that they should not put themselves in such a position. If their software had been better designed they would not have been so dependent in the first place, they did the wrong thing, etc., etc.

You will probably be right. So much right that they will just switch back to an operating system that actually cares about support and backward compatibility. Even for "bad" users.

I do not blame Lennart for the great software he writes for free. I do not even blame him for how fast and how much software he buries. I was only blaming him for his extremely naive "just a free offer" above. No drug dealer is that naive.

Systemd and ConsoleKit

Posted May 5, 2011 15:10 UTC (Thu) by spaetz (guest, #32870) [Link]

@LWN, can I get an option to filter some articles' comments rather than individuals? Some articles seem to make madmen out of usually sane people, and they seem to cause logorhea too.

Ps. Sorry nothing personal against my pre-poster, it's just that I have enough of the repetitive arguments going on in these articles They will convince no one who is already 120% sure of their position. Could you please start shouting your arguments in some lone forest rather than on LWN?

Systemd and ConsoleKit

Posted May 5, 2011 16:56 UTC (Thu) by anselm (subscriber, #2796) [Link] (1 responses)

I do not blame Lennart for the great software he writes for free. I do not even blame him for how fast and how much software he buries. I was only blaming him for his extremely naive "just a free offer" above. No drug dealer is that naive.

Since when has having started a piece of free software implied that you must maintain it forever? If Lennart finds a more convenient (to him) way of doing what ConsoleKit is doing then he should be free to do what he thinks makes sense.

No one complained when Linus Torvalds decided he would much rather continue hacking on the Linux kernel than work on Git; instead, other people stepped up to take over. Similarly, if someone else wants to hang on to the original ConsoleKit they can go on using and developing that for as long as they wish. Last I checked it was under the GPL, so they don't even need Lennart's actual consent.

Finally, as has been mentioned many times before, systemd can work with unchanged old-style init scripts. It is reasonable to assume that there will also be a migration path from ConsoleKit to a version of systemd that contains the equivalent functionality (however it will be implemented). Hence chances are that most current ConsoleKit users will be unlikely to even notice the difference.

Systemd and ConsoleKit

Posted May 5, 2011 20:54 UTC (Thu) by marcH (subscriber, #57642) [Link]

> > I do not blame Lennart for the great software he writes for free. I do not even blame him for how fast and how much software he buries.

> Since when has having started a piece of free software implied that you must maintain it forever?

Read what is quoted above more slowly and realize we agree. My point was in the next sentence (not quoted).

Systemd and ConsoleKit

Posted May 6, 2011 4:09 UTC (Fri) by Kamilion (subscriber, #42576) [Link]

import humor;
import sarcasm;

Honestly? I'm sick of backwards compatibility. It only works so well. There's a limit.

Especially in this day and age of virtualization.

If I want to run DOS software, I open up dosbox. Even on windows.
Why? Well, NT's VDM emulates a soundblaster really poorly. It handles resolution switches like a two legged dog.

If I want to run Win95 software that didn't have proper NT compatibilty; I launch Virtualbox or VMware with win98se.

If it doesn't work in wine, VB or VMWare to the rescue.

"Backwards Compatibility" as a meme is dead, or at least enough of a fib these days to where even game consoles cannot get it right. (PS3 drops PSX and PS2 support, 360 can only play ~150 XBox titles)

Why should you expect a PC to get it right?

Well, more to the point, why should you expect a PC to get it right when you mix several *generations* of software on the same GUI desktop?

Okay, sure, your processor can always drop back to 32bit protected mode and run freedos on bare metal, or you can still install Windows 98 (if you can find hardware drivers) or a laundry list of everything else; but it's a horrible bitch to get all of those apps open, in a window, on the same desktop.

I've tried to do this on my windows 7 professional box (gotta run visual studio 2010 for work somewhere... Even when we use QT. *sigh*)

My ubuntu box? Hey, no problem. I can goof off playing System Shock for DOS in a window while an old VB app does OLE against excel 95 in wine, with Eclipse and Chromium 12 sitting behind them, I don't have to worry about drivers (except this damned eGalax touchscreen!), and I have not *HAD* to open a terminal window in a very very long while.

Thanks to lennart, I can also plug my USB headphones in when my boss runs his mouth and poof, silence in the office.

Also, if I'm not mistaken, wasn't ConsoleKit pretty much built to bring multiuser switching to Fedora 7? I remember everyone kvetching about having to support it when it was introduced; and somehow in those years in between, it's become incumbent to the point where people are moaning about it's loss. What's next, people complaining that PulseAudio works too well?

Systemd and ConsoleKit

Posted May 6, 2011 12:38 UTC (Fri) by mjthayer (guest, #39183) [Link] (3 responses)

> I do not blame Lennart for the great software he writes for free. I do not even blame him for how fast and how much software he buries. I was only blaming him for his extremely naive "just a free offer" above. No drug dealer is that naive.

Replying to you and quoting that last sentence. I really can't agree with your way of putting that. If you can mentally radically reformulate it though, I would say that this is one of the reasons that free (as in free beer, but possibly by extension as in free speech) software will have a hard time reaching a high number of private desktops. Many people can't afford to depend on software for which the maintainers don't have some sort of obligation to them (even just the sort "I won't buy it unless it this and that"). Lennart's obligation is to RedHat (and even then systemd started as, and possibly still is, a private initiative) and to no one else unless RedHat says so - offering systemd for free does not obligate him to anyone, a rather different situation to your drug dealer.

I suspect that this situation will persist at least until "free beer" and "free speech" can be properly separated (programmers, think orthogonality!).

Systemd and ConsoleKit

Posted May 6, 2011 12:57 UTC (Fri) by anselm (subscriber, #2796) [Link] (2 responses)

I would say that this is one of the reasons that free (as in free beer, but possibly by extension as in free speech) software will have a hard time reaching a high number of private desktops. Many people can't afford to depend on software for which the maintainers don't have some sort of obligation to them

When people decide to run Linux on their private desktop, they won't usually make that contingent on the fact that their Linux distributions run specific technology such as System V init and ConsoleKit. They're in it for the complete picture. When they install a distribution such as Debian or Fedora, they put their trust in the maintainers of that distribution to keep their systems running, not to maintain whatever selection of software packages they had originally installed, for eternity.

I don't think anyone who has made the move to Linux will consider going back to whatever they ran before simply because their Linux distribution is moving to a different type of user session switcher. If OpenOffice.org/LibreOffice were suddenly to disappear from view, that might be a problem for many users but for most of the basic infrastructure this is simply not the case because people don't tend to notice the individual software packages involved.

It is safe to say that most people will not care in the least whether their systems run System V init/ConsoleKit or systemd, as long as their systems run reliably and as long as, if they have started out with a setup based on System V init/ConsoleKit, the eventual transition to systemd happens in a way that does not lead to regressions or other noticeable problems.

Systemd and ConsoleKit

Posted May 6, 2011 13:10 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

>> I would say that this is one of the reasons that free (as in free beer, but possibly by extension as in free speech) software will have a hard time reaching a high number of private desktops. Many people can't afford to depend on software for which the maintainers don't have some sort of obligation to them

> When people decide to run Linux on their private desktop, they won't usually make that contingent on the fact that their Linux distributions run specific technology such as System V init and ConsoleKit. They're in it for the complete picture. When they install a distribution such as Debian or Fedora, they put their trust in the maintainers of that distribution to keep their systems running, not to maintain whatever selection of software packages they had originally installed, for eternity.

I will rephrase my point in this context then. They are trusting the distribution maintainers do act in their interests, but once again those maintainers have no sort of obligation to do so (yes, there is a reputation thing, but that is a very limited sort of obligation). So the maintainers will act as they see fit. For RedHat and friends, this means being answerable to enterprise customers, who have different needs to private desktop ones. In Debian there is, to my knowledge, a high overlap between maintainers and users (or at least the sort of person who uses Debian), but again, if you have different needs it may not be the right thing for you. Ubuntu looks to fulfil the needs of desktop users, sometimes in a slightly "we know what you need" sort of way, but still very well given their budget constraints. Unfortunately (I think) those constraints are too tight to make a sufficient impact in the direction of providing something really suitable to a majority of desktop users. I know there are other reasons, but I think this is still a major one.

Systemd and ConsoleKit

Posted May 6, 2011 13:45 UTC (Fri) by anselm (subscriber, #2796) [Link]

They are trusting the distribution maintainers do act in their interests, but once again those maintainers have no sort of obligation to do so (yes, there is a reputation thing, but that is a very limited sort of obligation). So the maintainers will act as they see fit.

But the same applies to any operating system. For example, Microsoft's sole obligation is to keep the company profitable on behalf of its shareholders, which probably includes putting out versions of Windows etc. that are not so atrociously horrid that nobody will buy them (again, a »reputation thing«), but which most certainly does not include an obligation to keep every existing Windows machine in the world running forever. Within these constraints, Microsoft will act as they see fit.

People don't reasonably expect to buy a computer and then hang on to it for the rest of their own lives. So they only need to trust their vendors to keep the computer going during its useful life, which for most people these days is probably three to five years. In fact, many if not most people will not install a new major release of their machine's operating system vendors tend to find it difficult enough to make people install important security updates.

There are certainly Linux distributions around that will last for three to five years (on the same machine), and if »maintainer distrust« is indeed a major factor that keeps people from running Linux desktops, then we have a PR problem, not a technical or developer-social problem. After all, the nice thing about free software is that important stuff tends to stay around basically forever, and that one does not need to depend on a single vendor, whereas, in the world of proprietary software, if your vendor calls curtains on something you use that's it then.

Xinerama and multi-seat

Posted May 4, 2011 19:58 UTC (Wed) by samlh (subscriber, #56788) [Link] (7 responses)

Overall I think this is a good idea.

> gdm will spawn one X server for each video card found as they pop up, X itself should discover matching input devices

How would this would affect using Xinerama (multiple cards, one desktop)? This currently is configured through Xorg.conf, would the multihead work make this any harder? As far as I can tell, Xinerama requires a single X server for all cards.

Xinerama and multi-seat

Posted May 4, 2011 20:22 UTC (Wed) by eean (subscriber, #50420) [Link] (1 responses)

Well to get multiseat to work currently, you have to turn off the ability of X to automatically recognize HID stuff so that you can assign it manually.

Similarly I bet you'll have to turn off some of the systemd magic so that you can do whatever you do to get multi-card Xinerama to work (I assume you write your own xorg.conf?).

Xinerama and multi-seat

Posted May 4, 2011 20:45 UTC (Wed) by samlh (subscriber, #56788) [Link]

> Similarly I bet you'll have to turn off some of the systemd magic so that you can do whatever you do to get multi-card Xinerama to work (I assume you write your own xorg.conf?).

Sure, I just hope they document how to demagic things. Not sure, but I expect there are a fair number of Xinerama users.

Yes, Xinerama is configured through xorg.conf. Essentially, you set up multiple "Screen"s and list their relative positions in "ServerLayout".

Xinerama and multi-seat

Posted May 5, 2011 9:48 UTC (Thu) by MKesper (subscriber, #38539) [Link] (1 responses)

How do you get xinerama to work with modern X (xrandr)?

Xinerama and multi-seat

Posted May 5, 2011 21:21 UTC (Thu) by Wol (subscriber, #4433) [Link]

How do you get xrandr to work :-)

I've been bitten - SEVERAL times - by the failure of settings to stick between logins. That's pretty nasty when the screen tells the computer it can do 1600x900, then when that's what X sends, it goes into 1400x800 or whatever it is ...

Cheers,
Wol

Xinerama and multi-seat

Posted May 5, 2011 21:18 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

And what happens if you've got one video card, and want to run multi-seat on multiple displays on that card?

That's the situation I'm in - I can run two monitors, one on VGA, one on HDMI, and want to have two mice and two keyboards too.

Cheers,
Wol

Xinerama and multi-seat

Posted May 6, 2011 1:03 UTC (Fri) by samlh (subscriber, #56788) [Link] (1 responses)

You could try use the experimental "ZaphodHeads" option to split one card into multiple SCREENs, but I haven't tested it myself.

See this page on the Nouveau wiki for more information on the whole mess:
http://nouveau.freedesktop.org/wiki/MultiMonitorDesktop

Xinerama and multi-seat

Posted May 6, 2011 14:46 UTC (Fri) by Wol (subscriber, #4433) [Link]

Great!

Thanks, I'll have to investigate.

Cheers,
Wol

Systemd and ConsoleKit

Posted May 5, 2011 9:52 UTC (Thu) by MKesper (subscriber, #38539) [Link]

This sounds great. It's disturbing if you wake up your notebook with a normal user and get access to a root console left open accidentally on tty1.

Systemd and ConsoleKit

Posted May 4, 2011 16:05 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

Text copied from the document:

I hope this does not bother anybody. Feel free to remove it if it does.

systemd work for the session

Goals:

Simplify our stack by removing CK
Automatic multi-seat support
Make systemd available in the session
Removal of XDG_SESSION_COOKIE and its security problems, emphasis on audit loginuid and cgroup names instead
On-Demand starting of VT gettys
Fix the 63 threads issue
Covering all of getty, SSH and X11 sessions
Make session exit of pam_systemd more robust
Introduce D-Bus user bus
allow systemd user services to be run outside of a session, for selected users, a la cron with cron.allow

Current ConsoleKit features:

Registration of user sessions and seats storing of meta data
fast user switching
shutdown/reboot handling
Logging of user logins/logouts
udev integration to do device node ACLs
PK integration to verify console access to certain functionality

Logging currently is done 6 times (neither are indexed, except for utmp and lastlog which are indexed by uid):

utmp
wtmp
syslog
audit
ConsoleKit logs
lastlog

Plans:

Introduce seat tags on video, input, audio, other devices in udev
Make X11 check those tags. This requires a simple patch, i.e. udev_monitor_filter_add_match_tag(), based on the tag name passed on the X command line; if no seat name is given on the command line, pick up all devices without seat tag, to mimic current behaviour
gdm will spawn one X server for each video card found as they pop up, X itself should discover matching input devices
plymouth should also make use of all video cards and input devices found, as they pop up, and and terminate as soon as gdm takes over, plymouth should ignore seat assignments however, and act on all display and input devices
A tiny udev rule will try to automatically assign seat tags for devices manufactured by Plugable. Other hardware in the beginning will require writing udev rules manually. Eventually a UI for this should be written which spits out and installs udev rules.
Most of the logic in pam_systemd will move into a tiny bus service, and which will hand out leaking pipe fds to detect when the session ends, the same way pam_consolekit_connector works right now, but built around dbus fd passing
This bus service will have a similar interface to CK, however do a few key things differently: no cookie management (rely on audit login uid instead), listening on /sys/class/tty/tty0/active, on-demand triggering of gettys (or any other service), when an allocated VC with no process is activated. VCs will be handed out strictly based on a first-come first-serve basis, no fixed mapping anymore -- except for tty1. We will pre-allocate 12 ttys by default, but not start anything on them. If X needs another tty it just takes the next free one. If a tty is activated (by keypress) which currently has no client we will start a getty on it. That means by default we run zero gettys on a graphical boot, but they become instantly available as soon as the user switches ttys.
There will be no public CK database. However we will provide a tiny library (drop-in or .so) which allows NM, PK and D-Bus query whether a PID or user is currently on an active sesssion without involving D-Bus, as fast path for auth checks
udev-acl will move into this dbus service
Separate bus service for shutting down/rebooting/suspending the system, with integration into PK and which checks whether sessions are left open
Well introduce the D-Bus user bus, as discussed with various folks at the GNOME Summit last year, and redirect the session bus to it
We will implicitly spawn a systemd instance for each user on first login, and remove it at last logout. Lifetime of XDG_RUNTIME_DIR, the user cgroup, the user bus and the systemd instance are bound together
Ideally, X would start to listen on $XDG_RUNTIME_DIR/display or a similar socket. Could be default for clients if no $DISPLAY is set. Alternatively symlink hackery
We will focus on Linux and Linux only
Introduction of PR_SET_ANCHOR and usage in g-s/systemd, to ensure that all user processes are children of systemd/g-s and not detached
gnome-session will mostly stay as it is for now, however will use the user bus if it exists
Most likely drop support for CK history log files. Only user appears to be gdm and accountsservice. option 1) move this into gdm itself, so that gdm shows its own most frequent users only; option 2) use wtmp for this, which while ugly to use offers mostly the same functionality. If we need more metadata than wtmp can provide, hijack the 20 unused bytes at the end of each utmp record. If eventually we reintroduce log files for this, then we should do this in a really convincing fashion, i.e. indexed, with live querying support and suchlike
Optionally start user session (without display) already on system bootup, to permit timer-based cron-like user-code to run, or to run network services independent of an actual login. This will be strictly optional and only permitted for users with a flag file in /var/lib/systemd/user/xxx. Flag files controllable via PK, yadda yadda
Note that there is no static configuration of seats. The tiny dbus service will provide a list of current seats only based on the udev database: if theres a display device with a seat tag, then this seat exists, otherwise it doesnt
Seats and seat names will automatically be generated for Plugable devices based on their udev path id. i.e. by plugging in a plugable device a dynamic seat seat-pci-0000-00-1f-2-usb-4711-0815 (or something like that) is generated and exists exactly as long has it is plugged in.
No stored CK database as public API, instead store everything we need in memory, and export only very few things in the fs, for example to allow fast perm checks for dbus/NM/PK
Embedded folks can work without the bus service, to get old-style behaviour

Perspective for F17:

In F17, we might want to move user service/process handling from g-s to systemd, and get a definition of running application along the lines of the cgroups for them, which transcends all layers of our stack, from kernel to the UI; an application that isnt running is simply a .desktop file, and when it runs it is the cgroup by the same name
keep in focus for later: support multi-session and session switching on secondary VGA cards, in userspace

Transition:

We will ensure CK and the new scheme can run side-by-side. Only the ACL management of CK will be disabled when the new scheme is enabled
Phase-out similar to HALs, leave things running side-by-side but port important things over quickly. Should be much easier than HAL, since less code uses it

External patches:

udev: disable udev-acl
X11: add seat support (check for tags)
X11: make x11 XDG_RUNTIME_DIR-aware
gdm: for libudev support and new seat registration
plymouth: for libudev support
dbus: for new active session detection
PK: for new active session detection
NM: for new activte session detection
accountsservice: for new login history logs
kernel: PR_SET_ANCHOR
kernel: xattr on cgroup
kdm, other dms: drop CK support. Quite possibly the PAM session hooks are sufficient for our needs, no need for patching in new support into dms

Questions left unanswered:

What about idle hint stuff?

Where is what?

CKs seat management and session switching is pushed into new tiny bus service systemd-logind (or similarly named)
CKs logging is removed, and utmp/wtmp used instead
CKs shutdown/reboot handling moves into new tiny bus service systemd-rebootd (or similarly named)
udev-acl will move into systemd-logind
most of pam_systemd will move into systemd-logind

Effective new features by doing this:

Automatic Multi-Seat
Running user services outside of session
gettys only spawned on demand
synchronization on VGA discovery can be dropped → faster bootup
Cleaner PS tree
D-Bus/systemd available for user logins

Systemd and ConsoleKit

Posted May 4, 2011 19:36 UTC (Wed) by nowster (subscriber, #67) [Link] (13 responses)

So... how long do we have before the kernel gets rolled into systemd?

Is fork/exec now considered harmful?

Systemd and ConsoleKit

Posted May 4, 2011 20:25 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

Wait, there are a couple of other steps to complete first

http://www.catb.org/~esr/jargon/html/Z/Zawinskis-Law.html

Systemd and ConsoleKit

Posted May 5, 2011 3:25 UTC (Thu) by jcm (subscriber, #18262) [Link] (1 responses)

I suggest we just boot emacs and be done with it.

Systemd and ConsoleKit

Posted May 11, 2011 20:03 UTC (Wed) by nix (subscriber, #2304) [Link]

You suggest rewriting systemd in emacs lisp? It's possible, I suppose, though the Emacs core would require a good few additions...

;}

Systemd and ConsoleKit

Posted May 4, 2011 20:25 UTC (Wed) by eean (subscriber, #50420) [Link]

trolololol.

anyways, apparently systemd isn't one process

Systemd and ConsoleKit

Posted May 6, 2011 4:26 UTC (Fri) by Kamilion (subscriber, #42576) [Link] (8 responses)

Nope, only fork/exec of *sh explicitly during system startup.

Makes sense. 90% of initscripts are boilerplate anyway.

Upstart and systemd are doing a great job to excise that bit of cancer from our bootup.

Can you honestly say the following upstart job isn't easier to understand than a full init shellscript? The equivalent systemd unit is one line shorter, too.

sudo tee /etc/init/nginx.conf <<-\EOA
# /etc/init/nginx.conf
# nginx - starts the nginx webserver

description "nginx"

start on (net-device-up and local-filesystems)
stop on runlevel [016]

pre-start exec /usr/sbin/nginx -t

expect fork
respawn
exec /usr/sbin/nginx
EOA

Yay, future!

Systemd and ConsoleKit

Posted May 6, 2011 11:35 UTC (Fri) by aniou (guest, #74708) [Link] (7 responses)

Hmm... There's no support for configuration test before reload? O, yeah. Great, new future.

Systemd and ConsoleKit

Posted May 6, 2011 15:15 UTC (Fri) by nybble41 (subscriber, #55106) [Link] (6 responses)

There doesn't seem to be any explicit support for reloading services, but you could use something like "pre-stop exec /usr/sbin/nginx -t" to keep the service running unless there is a valid configuration to restart into.

Systemd and ConsoleKit

Posted May 6, 2011 16:09 UTC (Fri) by aniou (guest, #74708) [Link] (5 responses)

I know that upstart has default support for reloading (HUP) daemons. But - for example - script in Debian has support for testing configuration (nginx -t) and conditional reload (HUP). And I want configuration reloading NOT service restarting.

Systemd and ConsoleKit

Posted May 6, 2011 18:55 UTC (Fri) by anselm (subscriber, #2796) [Link]

Doesn't sound like a feature that would be impossible to add.

Systemd and ConsoleKit

Posted May 7, 2011 9:31 UTC (Sat) by mezcalero (subscriber, #45103) [Link] (3 responses)

In systemd we decided not to do any kind of SIGHUP magic implicitly, and that for a reason. The thing with SIGHUP-based reloading is that it is fully async: a client requesting a reload has no way to know or wait until the reload in the daemon is actually completed. In general we however try to make behaviour of the service operations as dependable as possible and that includes that users should be able to expects synchronous reloads.

That all said we do give you the option to use SIGHUP for reloading (in in a few cases that's even OK to use, since there is no effective difference between async/sync reloading for the particular case) simply by invoking the /bin/kill command from ExecReload=.

But yeah, in general think twice: the traditional SIGHUP reloading of Unix daemons is problematic.

Lennart

Systemd and ConsoleKit

Posted May 9, 2011 8:21 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

> In general we however try to make behaviour of the service operations as dependable as possible and that includes that users should be able to expects synchronous reloads.

Having suffered a lot from it in various cases I think I understand the "fire-and-forget" programming problem with SIGHUP reloads. BTW, even some "start" commands are asynchronous by default. This is an incredible bad idea: it is trivial to make a synchronous command asynchronous (&) as a speed hack, while extremely hard to check for completion of a dependency that escapes by making itself asynchronous.

However asynchronous commands are usually not a problem for end-users. Human end-users are quite different from programs: they more often than not know how much time the command will take, are able to poll intelligently, know how to verify whether the service has actually been reloaded,... so removing the whole feature just because it cannot be made synchronous would sound a bit harsh.

I do not know about systemd (yet...), but other init systems could probably make more difference between their programming versus user interfaces. Something like: "SIGUP commands are only for end-users, do not use in scripts". I have no idea how this could be achieved though.

Systemd and ConsoleKit

Posted May 9, 2011 11:44 UTC (Mon) by vonbrand (subscriber, #4458) [Link] (1 responses)

But you said it yourself: Just "... &" the regular command.

Systemd and ConsoleKit

Posted May 9, 2011 13:41 UTC (Mon) by marcH (subscriber, #57642) [Link]

I do not see which point you are answering to.