On Sat, Nov 17, 2012 at 05:48:39AM +0100, Michael Biebl wrote: > On 05.04.2012 06:03, Josh Triplett wrote: > > Package: systemd > > Version: 44-1 > > Severity: wishlist > > > > Testing systemd via the systemd package without using systemd-sysv > > typically involves setting init=/bin/systemd (or > > init=/lib/systemd/systemd) on the kernel command line. Please consider > > providing a grub.d script that automatically generates appropriate boot > > menu entries, similar to the existing script for Xen. > > Might be useful, yes. I've attached a proof-of-concept script which can > be dropped into /etc/grub.d. Make sure to chmod +x it. > > It's currently ordered *after* 10_linux, so sysvinit would still be the > default. > > What's a bit ugly is, that 10_linux is localized, but 15_linux isn't, > since it is missing translations for the string. > > title="$(gettext_quoted "%s, with Linux using systemd %s")"
Since the second %s represents the Linux kernel version, not the systemd version, that should say "%s, with Linux %s, using systemd". > So if you use a non-en locale, you'll get a mix of languages. > > > systemd-sysv should divert away that script, to avoid generating > > redundant boot menu entries when the primary boot menu entry already > > uses systemd. > > I'd be wary to do that. Diversions are ugly and having a safety-net, > i.e. a simple boot entry to start good-old sysvinit is probably not a > bad idea. With systemd-sysv installed, a sysvinit entry won't exist; both entries will launch systemd. It might make sense to do otherwise, though. Perhaps the 15_linux_systemd script could check for systemd as the default init and provide sysvinit fallback entries if the system has sysvinit still installed? You'd have to make sure installing or removing systemd-sysv triggered update-grub, but otherwise that should address the concern you raised about having a fallback entry. > > Versions of packages systemd recommends: > > pn libpam-systemd <none> > > On an unrelated note: Please consider installing libpam-systemd. > We really do recommend that you install it, especially on multi-user > systems, desktops and laptops. It is required for applying correct > devices permissions, registering user sessions (important for process > grouping) etc. > > The only place where I possibly would not install it is on a server > where no users log in via SSH. > > May I ask why you chose not to install it? Back when I originally installed systemd, I rather pointedly didn't want systemd to establish user sessions, because I'd seen several reports at the time about systemd not correctly handling processes shared between multiple user sessions (such as SSH or GPG agents), and incorrectly killing processes at logout time. Since then, I hadn't given it any further thought, but I also hadn't gotten around to experimenting further with systemd as my primary init. Might I suggest adding some of the information you just provided to the systemd package description, as an explanation for the recommendation of libpam-systemd? - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
