Re: Bug#762194: Alternative proposal for init switch on upgrades.
On Sat, Nov 29, 2014 at 11:15 PM, Tollef Fog Heen tfh...@err.no wrote: ]] Cameron Norman On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski kilob...@angband.pl wrote: On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: I would like to propose a different one. [...] So, the change would be that: the sysvinit package would cease being a transition / shim package, however it would not signal that a user explicitly installed sysvinit; sysvinit-core would be a simple package that just depended on sysvinit, and the presence of this package *would* signal that the user explicitly installed sysvinit; init would (pre-)depend on systemd-sysv | sysvinit | sysvinit-core | upstart. I'm afraid this doesn't allow partial upgrades from wheezy to use systemd-sysv, as sysvinit is an essential package there, and apt considers packages to be essential if they're present in any source. I take it you mean that the user will have to remove an essential package to install systemd-sysv, not that the package will not be installable, correct? That seems reasonable to me. If the user has packages from Wheezy installed, those packages could reasonably depend on sysvinit as PID 1 without expressing that dependency. No. They could reasonably depend on sysvinit being installed. We ship alternative inits in wheezy, some of which does not require sysvinit to be uninstalled (systemd and runit comes to mind, I would not be surprised if there are more). However, in the tradition of Essential packages, nowhere is it well-defined which of sysvinits interfaces were part of the essentialness and which are not. I kinda wish we'd fix that at some point, to make it easier to swap out (or get rid of) Essential packages. Would systemd-sysv having a `Provides: sysvinit` fix this issue? I think if the pre-installation /etc/inittab checking that has been discussed is implemented then systemd could reasonably be considered to provide sysvinit's interfaces (especially with the /dev/initctl compatibility). Thank you, -- Cameron -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CALZWFRL_8DtvpvM=gunqtnfpwo3lszvku6pvtve3sc3eabg...@mail.gmail.com
Bug#762194: Alternative proposal for init switch on upgrades.
On Sat, Nov 22, 2014 at 6:10 PM, Adam Borowski kilob...@angband.pl wrote: On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote: I would like to propose a different one. [...] So, the change would be that: the sysvinit package would cease being a transition / shim package, however it would not signal that a user explicitly installed sysvinit; sysvinit-core would be a simple package that just depended on sysvinit, and the presence of this package *would* signal that the user explicitly installed sysvinit; init would (pre-)depend on systemd-sysv | sysvinit | sysvinit-core | upstart. I'm afraid this doesn't allow partial upgrades from wheezy to use systemd-sysv, as sysvinit is an essential package there, and apt considers packages to be essential if they're present in any source. I take it you mean that the user will have to remove an essential package to install systemd-sysv, not that the package will not be installable, correct? That seems reasonable to me. If the user has packages from Wheezy installed, those packages could reasonably depend on sysvinit as PID 1 without expressing that dependency. It would be a bug, IMO, if sysvinit was not PID 1 while Wheezy packages were installed and the user had not expressed that he or she understood the implications of removing sysvinit. Thus, I maintain that my proposal is an appropiate approach. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calzwfr+g3rqjwecw08xkjm8hxjihb5e11qzkzvxbwbamvzp...@mail.gmail.com
Bug#762194: a technical proposal
Hello, On Sat, Nov 22, 2014 at 5:21 AM, Adam Borowski kilob...@angband.pl wrote: Hi! As Ansgar requests technical solutions, here's one: just like systemd-shim|systemd-sysv, switch the init package from Pre-Depends: systemd-sysv | sysvinit-core | upstart to Pre-Depends: sysvinit-core | systemd-sysv | upstart The set of packages installed by d-i / debootstrap is steered by hard-coded scripts, thus new systems can default to whatever is set there. On the other hand, during upgrades, the init system is driven by apt's resolution of the above pre-dependency. If systemd-sysv or upstart were already installed, no change is done; if none of these three packages is present, apt would install sysvinit-core, preserving existing init system. One of Steve Langasek's criticisms of not switching by default was the pain of having systems still running sysvinit for many years to come, which makes the distribution more difficult to support. If there was an intention to do so, how would we go about switching systems over to systemd in the next release, if we use the solution displayed here in Jessie? Thanks, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CALZWFR+c=a6hrefjsqndhcs-fmntmufosu5h+bmqm5httug...@mail.gmail.com
Bug#762194: a technical proposal
On Sat, Nov 22, 2014 at 9:01 AM, Cameron Norman camerontnor...@gmail.com wrote: Hello, On Sat, Nov 22, 2014 at 5:21 AM, Adam Borowski kilob...@angband.pl wrote: Hi! As Ansgar requests technical solutions, here's one: just like systemd-shim|systemd-sysv, switch the init package from Pre-Depends: systemd-sysv | sysvinit-core | upstart to Pre-Depends: sysvinit-core | systemd-sysv | upstart The set of packages installed by d-i / debootstrap is steered by hard-coded scripts, thus new systems can default to whatever is set there. On the other hand, during upgrades, the init system is driven by apt's resolution of the above pre-dependency. If systemd-sysv or upstart were already installed, no change is done; if none of these three packages is present, apt would install sysvinit-core, preserving existing init system. One of Steve Langasek's criticisms of not switching by default was the pain of having systems still running sysvinit for many years to come, which makes the distribution more difficult to support. Here is the message which I am referencing. Please see the footnote. I hope I did not misrepresent you, Steve, please correct me if so. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#66 -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CALZWFRL22BKRHHkTatFQ1HPM-8kJb9m+=g7raubwd9uzzeq...@mail.gmail.com
Bug#762194: Alternative proposal for init switch on upgrades.
Hello everyone, Since I myself and some others had some criticisms and/or doubts of Adam Borowski's proposal, I would like to propose a different one. With this I hope to: * make new installations use systemd-sysv (with no reliance on undefined or inconsistent behavior from the various ways of setting up a Debian install or chroot) * make current installations that have sysvinit stick with it * allow for the automatic switch from sysvinit to systemd-sysv in stretch, buster, or another later release So, the change would be that: the sysvinit package would cease being a transition / shim package, however it would not signal that a user explicitly installed sysvinit; sysvinit-core would be a simple package that just depended on sysvinit, and the presence of this package *would* signal that the user explicitly installed sysvinit; init would (pre-)depend on systemd-sysv | sysvinit | sysvinit-core | upstart. If an automatic switch is something that the project wants, but after Jessie, then then the init dependency would be changed to systemd-sysv | sysvinit-core | upstart. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calzwfrj_qv1vpwrcvtr7hakj1ivw8nn_dmzp8h1q8xkbbzk...@mail.gmail.com
Bug#765803: Status of prompting / notification on upgrade for init system switch?
On Thu, Oct 23, 2014 at 8:13 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote: Josh == Josh Triplett j...@joshtriplett.org writes: Josh - It can't check for generated lines for serial consoles or Josh similar; finish-install can generate various additional Josh inittab lines, which the check should include. Since when did systemd actually handle these correctly? I've generally found that systemd will give me a serial console only if the kernel console is that serial console. I've found that if I manually enable a serial console but have the kernel console go somewhere else, I end up with a system I cannot log into when I upgrade to systemd. This has been no end of frustration and I hope that your check correctly prompts in this case even when the line I generate is exactly the same as a line generated by the installer. If it's gotten better and I'd actually get a console in that case, that's of course fine too. It should either let me know I'm about to hurt myself or work:-) Either behavior is fine. TTBOMK, you'll automatically get a console on a serial port in a few cases: - If the kernel console points there (console=ttyS0); note that this works even if you change that console. - If the console is identified as a default system console (works for virtual machine serial ports, and for systems with unusually named standard console serial ports). See systemd-getty-generator. In other cases, you have to manually systemctl enable serial-getty@ttyX.service. I wonder if it might make sense to do a one-time migration that parses /etc/inittab, looks for serial console getty lines, and enables serial-getty@.service for any consoles it finds gettys for? If you are going to the work of parsing it all, would it not make sense to make a systemd generator out of it? -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CALZWFRJsMWVXXx5iz=kstt82dn3ovddc9xrhn8asqon-wvk...@mail.gmail.com
Bug#765803: Status of prompting / notification on upgrade for init system switch?
to be taken on their own. -- Tollef Fog Heen, on behalf of the systemd team UNIX is user friendly, it's just picky about who its friends are Thanks, -- Cameron Norman
Bug#765803: tech-ctte: Ask before changing init system when upgrading to jessie and Inform about init systems when installing jessie
On Sat, Oct 18, 2014 at 3:56 PM, Vincent Bernat ber...@debian.org wrote: ❦ 18 octobre 2014 13:32 +0200, Svante Signell svante.sign...@gmail.com : In summary, the CTTE is asked to make a decision on debconf warnings on: 1) Changing init system on upgrades (including sid) 2) Inform about alternate init systems for new installations 2 is quite far-fetched. Why not a debconf warning to tell there are alternatives to nano? And another one to tell there are alternatives to bash? The installation will take several hours to let the user know there are alternatives to almost any component. Well one good reason is that when you install nano or bash, vi/vim/emacs and zsh/fish are not uninstalled. Furthermore, these components are not necessary to boot your system into a stage where you can login, have internet capabilities, and can install or remove packages. The exception to this is when you remove bash, and you get a loud warning at that point. Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calzwfrlegcpuv2gi3nrdkuawytwb9wnu2yzmavomrfnopor...@mail.gmail.com
Bug#746578: Reasons to keep systemd-sysv as the first alternative
On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett j...@joshtriplett.org wrote: I'm pulling a quote from the bottom of Steve's mail to the top, to call attention to a new and critical point that I didn't see raised anywhere in the debian-devel discussion: On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek vor...@debian.org wrote: If we decide that init *should* be automatically changed on upgrade, then (Which I'm assuming from your footnote [1] that you *are* in favor of?) the ordering of the dependencies on libpam-systemd is immaterial except in the specific case that someone has upgraded to (or newly installed) jessie, selected an init system other than the default, and subsequently installed a desktop environment on a system that didn't initially have one. In this case, installing the DE *definitely* should not override the user's explicit selection of init system. *This* is a point that I haven't seen raised in the entire previous discussion on debian-devel, and I think it's a completely valid point. Personally, in this case, I'd argue that the desirable dependency (which we can't easily express) would be sysvinit-core ? systemd-shim : systemd-sysv. To be more precise, it would be !systemd-sysv ? systemd-shim : systemd-sysv so that other alternate inits are treated equally. As you hopefully can see, this can be condensed to systemd-sysv ? systemd-sysv : systemd-shim AKA systemd-shim | systemd-sysv :) One question: if `init` and `libpam-systemd` (with the inversed dependency) are installed simultaneously on a system with only sysvinit installed (i.e. Wheezy), apt would know that systemd-sysv is going to be installed (to satisfy init package's dependency) and would not install systemd-shim, correct? Although, according to Steve that would be simply an aesthetic issue, as systemd-shim does not impede operation of systemd as init. Best regards, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CALZWFR+DKFwoR=dcarpea5czesyiaupywuwuoa+nmpdjf8l...@mail.gmail.com
Bug#746578: More systemd fallout :-/
On Thu, Sep 18, 2014 at 11:59 AM, Josh Triplett j...@joshtriplett.org wrote: On Wed, 17 Sep 2014 15:34:48 +0100 Ian Jackson ijack...@chiark.greenend.org.uk wrote: In #746578, a user requests that the dependency from libpam-systemd to systemd be changed from systemd-sysv | systemd-shim to systemd-shim | systemd-sysv The maintainers of libpam-systemd have rejected this change. I would like the TC to set out the applicable principle(s), and overrule the maintainer in this case. As I understand it from reading the threads in the bug and on debian-devel, the effect of this would be: * New jessie installations would still get systemd. * squeeze-jessie upgrades which are not already using systemd would not be switched silently to systemd but would use systemd-shim instead. * Attempts to upgrade non-systemd systems in some other circumstances would no longer switch silently to systemd. The latter two points are not actually accurate. I just tested this by installing a wheezy minbase chroot using debootstrap and upgrading it to jessie. The list of packages installed as part of the wheezy minbase chroot: apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname initscripts insserv libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0 libc-bin libc6 libcomerr2 libdb5.1 libgcc1 liblocale-gettext-perl liblzma5 libmount1 libncurses5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libtinfo5 libusb-0.1-4 libustr-1.0-1 libuuid1 login lsb-base mawk mount multiarch-support ncurses-base ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar tzdata util-linux xz-utils zlib1g The upgrade: /# apt-get --no-install-recommends dist-upgrade Reading package lists... Done Building dependency tree... Done Calculating upgrade... Done The following NEW packages will be installed: acl adduser dmsetup gcc-4.9-base init libaudit-common libaudit1 libcap2 libcap2-bin libcryptsetup4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper1.02.1 libgcrypt11 libgcrypt20 libgpg-error0 libkmod2 libncursesw5 libpcre3 libprocps3 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libwrap0 procps startpar systemd systemd-sysv udev The following packages will be upgraded: apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname initscripts libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0 libc-bin libc6 libcomerr2 libgcc1 liblocale-gettext-perl libmount1 libncurses5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtinfo5 libusb-0.1-4 libuuid1 login lsb-base mount multiarch-support ncurses-base ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar tzdata util-linux zlib1g 70 upgraded, 31 newly installed, 0 to remove and 0 not upgraded. Need to get 33.7 MB of archives. After this operation, 27.5 MB of additional disk space will be used. (Including recommends would install a few additional packages, including libpam-systemd because systemd Recommends it, but I used --no-install-recommends to prove that libpam-systemd was *not* the driver of the transition, nor was it involved in the upgrade.) This transition is driven not by libpam-systemd as suggested in this bug report, but by the sysvinit transitional package (which depends on init) and by moving the Essential: yes bit from sysvinit to init. Note that that transition was coordinated between the sysvinit, systemd, and upstart maintainers, and that the init package also supports sysvinit and upstart. If the transition is already happening, why have the dependency be like it is anyway? User's systems will be switched regardless, so there is no use in having a second pass at changing the init. Also, although the squeeze/wheezy - jessie bit Ian wrote seems to be incorrect, his last point still stands: on a jessie minbase (with init shifted to !systemd-sysv), if you install libpam-systemd, your init is changed back to systemd. So the systemd-sysv | systemd-shim bit is either pointless and redundant (upgrading to Jessie) or actively disruptive (installation of libpam-systemd on jessie+ systems). Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https
Bug#741573: Two menu systems
On Thursday, June 26, 2014, Colin Watson cjwat...@debian.org wrote: On Thu, Jun 26, 2014 at 05:50:38PM +0100, Ian Jackson wrote: I see Keith has committed a draft to git. As discussed, I disagree with this approach. This amounts to nonconsensually abolishing someone's work when it is still being maintained, and the global cost is minimal. My feelings on this draft are mixed. On the one hand, I happen to agree with the position that the categorisation system in .desktop files (and X-Show-In etc.) should be able to cover the bulk of the practical requirements of the trad menu system: * There's no reason that has a .desktop file should imply shows up in modern desktop environments, and so I think that the question of coverage is to some extent a red herring; the systems have different coverage because they've always had different coverage, not because the .desktop format is inherently unable to meet the needs of trad menu consumers. * We might have to look into the presentation of menu item names, although Name / GenericName offers some support for the different names that people are likely to want, and if all else fails the .desktop file format does have extension mechanisms. I would be very happy to see additional .desktop files being added to packages with suitable categorisation such that they don't need to interfere with how the maintainers of modern DEs want to present their desktops, so that menu-xdg (or similar) can supplant the current menu system with negligible loss of functionality for users of trad menus. I think this would make a great project for people interested in unifying the two worlds a bit more, which doesn't even have to step on anyone's toes. Perhaps for instance it would be a good project for Debian's Google Summer of Code efforts. On the other hand, Keith's draft seems highly aspirational to me. While it seems to me to be broadly the right kind of long-term technical direction, there is an awful lot of work in there for people who want something like trad menus which is being glossed over. So, I prefer Ian's position in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the purposes of how the policy text should remain for the time being, and in terms of the philosophy of not ripping out work from under people's feet. I disagree with its argument that it follows directly from the two sets of competing requirements that we must have these two file formats. I prefer Keith's position as a long-term direction, but agree with Ian that it is lacking an awful lot of transitional thought, and feel that it has a lot of things-should-be-done without it being clear who will do them. Thirdly, IMO the resolution needs to acknowledge (in the whereas section) that consuming a trad Debian menu entry is simpler and easier than consuming a .desktop file. I think this is really overstated. .desktop files are in a long-standing and popular basic file format for which plenty of parsing libraries in various languages exist, so you can get to the point of having a parsed data structure trivially. In contrast the menu entry format is a bespoke thing. While the .desktop file format has more bells and whistles, many of them can be ignored if you don't support whatever it is. I don't think it's worth emphasising ease of consumption either way. I believe the major aspect of .desktop files that makes them harder is the icon handling. Perhaps debian policy should instruct that a certain icon size must always be available in a particular format (e.g. 32x32 png) so that WMs do not have to handle so many corner cases in that area. Best, -- Cameron Norman
Bug#746715: the foreseeable outcome of the TC vote on init systems
El Tue, 6 de May 2014 a las 7:54 PM, Russ Allbery r...@debian.org escribió: Faidon Liambotis parav...@debian.org writes: I haven't gotten any such bug reports, so this is still theoretical, but I think I'd simply reject anything more complicated than simply adding a debian/foo.upstart file to the tree, including adding (and maintaining) hacks or modifying existing SysV init scripts. I certainly won't work on adding an upstart job to my packages myself. The hacks we're talking about here are pretty minimal: just three lines in the init script that we're mentioning. I think it's pretty straightforward and think that maintainers should just add that support. In addition, as has been mentioned, they will soon be unnecessary, as Dimitri Ledkov is working to put the functionality into a init-functions.d hook. [snippity snip] 3 Hope that stuff clears up! Stress is very stressful, and that is never good. I do not know your taste in music, but maybe you will like this: https://www.youtube.com/watch?v=tNygDLi9gb4. Top of the day, -- Cameron Norman
Bug#746715: the foreseeable outcome of the TC vote on init systems
El Tue, 6 de May 2014 a las 8:41 PM, Bdale Garbee bd...@gag.com escribió: Russ Allbery r...@debian.org writes: I can see your point that the future of upstart is possibly unclear, but my feeling is that if anyone filed a bug against a package requesting upstart support, that's sufficient indication of interest to merge upstart support patches, including this sort of minor modification of the init script. I agree. From your other message I was under the impression that you thought it was ok to remove Upstart support, but now you agree that if there was interest, then it should be kept (as long as it does not cause issues). Is the maintainer supposed to accept the support then remove it a few months later :) ? Are those interested in Upstart support supposed to hawk over packages and never get a wink of sleep? I do not think that is what you want, but the wording of your other message (that you would not be surprised if upstart support was removed) seems like it is. Would you mind clarifying a little? Thanks y buenos noches, -- Cameron Norman
Bug#746715: the foreseeable outcome of the TC vote on init systems
El Fri, 2 de May 2014 a las 3:01 PM, Ian Jackson ijack...@chiark.greenend.org.uk escribió: Russ Allbery writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): Steve Langasek vor...@debian.org writes: An Ubuntu developer just brought the following Debian changelog entry to my attention: tftp-hpa (5.2-17) experimental; urgency=low * Removing upstart hacks, they are ugly and upstart is dead now. Since various members of the Technical Committee argued that choosing a default would not prevent Debian from supporting other init systems, I would like to hear from those members how they think this should be addressed. Well, one, in the abstract this seems like a bad idea. I certainly don't intend to remove upstart support in my packages, any more than I would reintroduce a bunch of PATH_MAX expressions and intentionally drop Hurd support. The removed change is presumably what was added here: tftp-hpa (5.2-9) experimental; urgency=low * Adding upstart exit codes in initscript. There we go! As somebody who likes Upstart, _this is an ugly hack_. It is mandated by Debian policy [0], as most of you may know, though. Perhaps the simplest solution to the immediate problem is to perform the actions suggested by Dimitri Ledkov in BTS #712763 [1]. That said, there is obviously a bigger question here for the TC to address. [0] https://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712763 Best regards, -- Cameron Norman
Bug#727708: call for votes on default Linux init system for jessie
El Sat, 8 de Feb 2014 a las 3:56 PM, Michael Gilbert mgilb...@debian.org escribió: On Sat, Feb 8, 2014 at 6:40 PM, Paul Tagliamonte wrote: I understand you think that, and I empathize, but I disagree. The fact is, I have limited time. If I'm going to focus on making a bigger impact with my work, I'm going to stick to dealing with issues that effect the most users. I don't care about the init system all that much, in the end, it's not important. I do care about ensuring we have something maintainable and stable. Why bring such a controversial and polarizing issue before the TC if the outcome doesn't matter much to you? sysvinit is maintainable and stable, so why seek to change it? Perhaps the movement in GNOME to depend on a number of systemd provided interfaces has led Paul to believe that sysvinit is unmaintainable? AFAIR, systemd-shim was not available when he presented the question to the TC (or am I mistaken?). -- Cameron
Bug#727708: I'd like to voice my opinion
El Thu, 6 de Feb 2014 a las 7:41 PM, Schlacta, Christ aarc...@aarcane.org escribió: I'd like to request that upstart be chosen over systemd mainly because there's already a large availability of deb packages that support init mainly due to ubuntu. Ubuntu acts as a gateway distro to the debian universe, and is a basis upon which numerous other distros are based as well. As such, a lot of packages are developed for ubuntu instead of debian. Making upstart the default init package allows for compatibility with the majority of these ubuntu specific packages. Furthermore, I know upstart is capable of maintaining backward compatibility with systemvinit scripts as debian implements them currently. Hello Christ. systemd proponents have been hard at work in getting systemd units packaged up and installed. Just load up Sid to see how many there are. Furthermore, systemd supports sysv scripts just like Upstart (actually, they are integrated into systemd's dependency chain, so the implementation is better in that way). I understand that you had the best of faith in writing this, but I assure you that the availability of init configurations will not be a problem for systemd, Upstart, or OpenRC (OpenRC supports sysv scripts). That said, Upstart could be a good choice because of the number of desktop environments that have their main focus as Ubuntu (Pantheon, Cinnamon, MATE) and could be encouraged to adopt Upstart as a session init if Debian goes with it. The same could be said of systemd, though (with GNOME and KDE instead of Pantheon and Cinnamon), though. Have a great day, Cameron
Bug#727708: Processed: block 726763 with 727708
On Sat, Feb 1, 2014 at 3:48 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: On Sat, 2014-02-01 at 15:24 -0800, Steve Langasek wrote: While I think the Depends: systemd should be dropped (via a split of the systemd package), that's not required for fixing the present problem. That can be addressed by having gnome-settings-daemon Depends: systemd, systemd-shim | systemd-sysv. Would the GNOME maintainers be willing to upload such a change? Or would they be ok with me NMUing gnome-settings-daemon for it? I have the impression that systemd-shim diverts systemd files and you don't want to have it installed if you're actually booting with systemd. If this is accurate (I didn't check), then such a dependency change would not be appropriate - the recommended way to install systemd is still to NOT use systemd-sysv, while the above dependency would either force installation of systemd-sysv or would incorrectly install systemd-shim on systemd-booting systems. I think there is a huge problem with recommending that systemd be installed by the user changing the init line in grub: a package can not depend on an init system being PID 1. Can a package be made that changes the init line to systemd? I think that is preferable, because it folows the upstream convention of installing systemd by changing the init value, while also allowing packages to depend on systemd being PID 1. Nevertheless, there still needs to be a org-freedesktop-login1 virtual package. This will allow the systemd packagers to bump to systemd(-logind) v209 and let someone else maintain a systemd(-logind) v204 package in order to use logind without requiring systemd to be PID 1. I think that, with these two packages (one virtual), the systemd packagers will be happy and GNOME can actually function properly with no intervention. -- Cameron Norman
Bug#727708: Thoughts/Summary on the init-system
On Sun, Jan 19, 2014 at 10:27 AM, Steven Chamberlain ste...@pyro.eu.org wrote: On 19/01/14 18:15, Andreas Metzler wrote: could you provide a little bit of background why you consider both Systemd on Linux, openrc/sysv-rc on non-Linux and Upstart everywhere viable long-term but not systemd on Linux and upstart on !Linux? As a porter, I'd slightly prefer we switch to OpenRC on GNU/kFreeBSD. But, if Upstart were chosen as the default on Debian GNU/Linux, that might be sufficient to change my mind; we could stay more closely in sync with the Linux ports and avoid so much duplication of effort that way. So, I would agree exactly with what Andi said. I suspect that init job/service/script/thingy writers would prefer a systemd-OpenRC combo as well, because they are both dependency based and the logic of the thingy can be more easily transferred to the other format. Best, -- Cameron Norman
Bug#727708: init system thoughts
On Fri, Jan 17, 2014 at 12:50 AM, Anthony Towns a...@erisian.com.au wrote: On 31 December 2013 12:55, Colin Watson cjwat...@debian.org wrote: The criticisms of Upstart's event model in the systemd position statement simply do not make sense to me. Events model how things actually happen in reality; dependencies are artificial constructions on top of them, and making them work requires the plethora of different directives in systemd (e.g. Wants, which is sort of a non-depending dependency) to avoid blocking the boot process on a single failing service. Riffing off this more than replying to it. I tend to think dependencies and events are both useful ways of describing when to start up parts of the system. In particular, it seems like: - when a network is connected, start web server - when a usb disk is connected, mount it - when a VPN is started, sync various things are best described by an event model, while: - in order to run GNOME, logind must be started - in order to run logind, dbus must be available - as part of making the system ready for a user, network-manager should be running You could express that as an event because GNOME and logind communicate with logind and dbus (respectively) through IPC. So you can say when GNOME tries to use logind's dbus interface, start logind, or you can say when //anything// tries to use logind's dbus interface, start logind and have that done for. Same for starting dbus, just change a dbus interface to dbus's port. make the most sense when described by dependencies. In particular, in many of those cases, the reverse might not be true: For debugging, I might want to start the web server manually without connecting the network; or I might want logind running without GNOME, or network-manager running without the other parts of my desktop environment. With the above method, this problem is avoided because GNOME does not start when logind starts, it just starts whenever the runlevel is right and then logind is started automatically. So if GNOME is stopped/waiting, you can start logind without GNOME starting. -- Cameron Norman
Bug#727708: Thoughts on Init System Debate
On Fri, Jan 17, 2014 at 8:41 PM, Don Armstrong d...@debian.org wrote Upstart's CLA is problematic, and coupled with the fact that the rest of the non-Debian distributions appear to be standardizing on systemd gives me pause. I'm not sure if this is actually a major concern, though, as long as Ubuntu continues using upstart. If you have the time, I must ask: if Upstart had no CLA, would you prefer it over systemd? -- Cameron Norman
Bug#727708: init system discussion status
On Fri, Jan 3, 2014 at 7:17 PM, Russ Allbery r...@debian.org wrote: Clint Adams cl...@debian.org writes: As loath as I am to participate in this discussion, I have to ask if your intent is to suddenly outlaw all the packages which depend on runit. I don't think runit (or daemontools) are init systems. If you feel like that may be ambiguous, we should say that explicitly. (This is one of the problems with how to word matters around OpenRC, since in a way it's actually closer to daemontools or runit. The latter just never attempted to deal with *all* the startup scripts.) Upstart running as a session init is not really an init system either, then, under that definition. Perhaps we should ban packages that depend on a certain init system being PID 1. Upstart, runit, daemontools, Circus, God etc. can run as session inits on top of any other init system, and therefore will have a small, confined effect when doing so and should be allowed. Regards, Cameron
Bug#727708: upstart dependency handling
On Thu, Jan 2, 2014 at 8:35 AM, Russ Allbery r...@debian.org wrote: I wanted to lift this out of the thread it was buried in and see if I'm understanding it correctly, since if I am, it seems like a significant issue. Cameron Norman camerontnor...@gmail.com writes: I think you raise a lot of good points in this email, but here you are saying something which may demonstrate your (understandable) confusion about the Upstart event model. Upstart does not treat dependencies as events. Often times, Upstart //jobs// treat dependencies as events (and the ones you wrote below do), but events do not signal a dependency. Just because you said that jobOne starts with jobTwo does not mean that jobOne needs jobTwo, just that during boot up jobOne will start with jobTwo. To express a dependency, jobTwo needs to have a start on (event where I am needed). If, for example, jobOne depends on a dbus interface of jobTwo, then jobTwo could have a start on dbus ... to show that dependency. But does that actually provide a dependency? In other words, if the sysadmin manualy starts jobTwo, does that either prevent jobTwo from starting becaus the dbus service isn't available, or start the dbus service? Or is jobTwo just started without dbus to cope as best it can? That is where you have to start going down the dependency list and make sure that dbus is (a) pretty much always started when it is possible for jobTwo to be started or (b) started when any service connects to dbus's socket (I think /run/dbus/system_bus_socket or whatever for the system socket, and then ~/.dbus/session-bus). The dbus socket address is actually stored in an environment variable, so it is pretty easy to handle in Upstart jobs. Having actual dependencies strikes me as an important technical feature. I don't like the idea of the init system not caring about whether the prerequisites for a job are met and just blindly starting it anyway. We're all somewhat used to that behavior, since that's what we get with sysvinit, but it's inherently fragile. We can try to hold all software packaged in Debian to the standard that it will fail cleanly and without problems if started in the wrong sequence, but it still seems to preserve the possibility of a whole class of bugs that systemd would close. Assuming, that is, that the understanding expressed on this thread is correct. Note that dependency handling is relevant to socket activation as well. As I discovered when experimenting with systemd, for reproducible behavior, you want to ensure that the job is always started with socket activation if that's how you have it configured; if not, such things as bind addresses may not be honored, which could even pose security issues. That includes the case where the job is configured to not start by default but is manually started by the administrator. Now, you could introduce a new dependency model just for socket activation or treat socket activation as part of that service rather than (as systemd does) a separate service that's tightly coupled with the daemon. So this is addressable by making socket setup a special case of sorts, such as by converting the request for the socket into a method event that is triggered before starting the daemon itself. But all that does feel harder to understand to me, particularly since you really want the sockets started independently of the jobs and early in the boot process so that other services can start talking to them, which makes the method call approach tricky. AFAIU, one can just use: start on socket PROTO=unix SOCKET_PATH=/run/dbus/system_bus_socket for the system job and: start on socket PROTO=unix SOCKET_PATH=DBUS_SESSION_BUS_ADDRESS for the session job. If I am correct, this will ensure that dbus will be started whenever a job tries to create a dbus interface (or access one). This is much less verbose than every single dbus using service listing dbus as a dependency. I would very much like to know what Steve Langasek's thoughts are on this. Something else that is relevant to this discussion is this Upstart cookbook section: http://upstart.ubuntu.com/cookbook/#critique-of-dependency-based-init-systems . Cheers, Cameron Norman -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwjeqr45.fsf...@windlord.stanford.edu
Bug#727708: init system discussion status
by that init system. | |C. However, a maintainer is entitled to consider a patch unreasonable | if it: | (i) Requires additional build-dependencies; or | (ii) Requires additional runtime dependencies except sysv-rc; or | (iii) Introduces other than trivial new code into the daemon; or | (iv) Abuses SIGSTOP as done by the upstart expect stop | protocol and as disliked by the systemd community. | |Code to write to an already-open fd and close it, or to raise a |signal, will usually be trivial for these purposes. (This includes |enabling the new protocol via command-line switches or environment |variable tests, and removing any small fixed set of associated |variables from the environment.) Code to connect to an AF_UNIX |socket and send a message will not usually be considered trivial. | |We are aware that at present it is not possible to provide a patch |for any of systemd's or upstart's main non-forking daemon startup |readiness protocols which is necessarily reasonable by this |definition. | |Therefore if the upstart and systemd communities in Debian want the |widest adoption in the project, these problems should be addressed |by changes to the upstart and systemd package to widen their |support for different startup protocols. Ideally each init should |in any case provide support for the main protocols supported by |their competition. | |Failure to apply reasonable patches, including failure to explain |promptly and constructively why a patch is not reasonable, is |likely to lead to the maintainer being overruled. ] | | Detailed policy specifications: | | 7. [ No package in Debian should use expect fork or expect daemon |in upstart jobs. The corresponding code in upstart may be disabled |or compiled out on some or all architectures. ] | | 8. Policy rules for support for init systems must: | |(a) Specify the use of a non-forking startup protocol (for |upstart and systemd), | |(b) Use facilities documented in the reference manuals for the init |system in question (as found in sid). [ This requirement |cannot be met until the init system has a suitable reference |manual. ] | |(c) Require that environment variables and fds involved in the |daemon startup protocol should not in general be inherited by |the daemon's descendants. | |(d) Forbid the introduction of embedded copies of library code |(or the use of any embedded copies included by upstream). | | 9. [ Policy should provide non-binding suggestions to Debian |contributors who are converting daemons to upstart and/or systemd, |for example: | |(a) If changes are necessary to the core daemon code, make those |changes acceptable to the daemon's upstream if possible. | |(b) It is fine to introduce new code in the main body of the daemon |to support non-forking startup, socket activation or readiness |signalling. | |(c) Support for upstart is usually best provided with the |raise(SIGSTOP) non-forking daemon readiness protocol, unless |and until a better protocol is available. | Should it not be added that raise(SIGSTOP) should only be used with a command line option (like --debian-Z) to ensure that the daemon does not hang on sysv or systemd? Cheers, Cameron Norman
Bug#727708: loose ends for init system decision
On Thu, Jan 2, 2014 at 11:46 AM, Josselin Mouette j...@debian.org wrote: Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit : I would hope that we can standardise on a single API to the system's single cgroup writer. I have already explained why this is not going to happen. The cgroups API in systemd is already part of the core systemd interface and subject to the stability promise. The only other existing implementation (cgmanager) is merely wrapping in D-Bus the existing kernel API, which is going to die when a single writer becomes necessary. It seems like you just explained how it has already happened. systemd's cgroup interface is covered under the stability promise, and seems like a good fit for a standard interface to the single cgroup arbitrator. Cameron
Bug#727708: init system other points, and conclusion
On Wed, Jan 1, 2014 at 4:56 AM, Colin Watson cjwat...@debian.org wrote: On Tue, Dec 31, 2013 at 04:27:16AM -0008, cameron wrote: On Mon, Dec 30, 2013 at 7:17 PM, Colin Watson cjwat...@debian.org inotify is used to notice changes to configuration files. This is certainly helpful for users, but it isn't critical as initctl reload-configuration works without it. We could probably do without this with the aid of a dpkg trigger. inotify use can easily be ported to kqueue within Upstart, or libinotify-kqueue can be used. Note that I'm talking about the Hurd here. kqueue is a kFreeBSD thing, as far as I know. (Compare e.g. https://lists.debian.org/debian-hurd/2013/10/msg00021.html) prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work properly when Upstart is supervising a user session. This isn't a required feature and could easily be compiled out until suitable kernel support is available (this actually seems like the sort of thing that could be done in the Hurd without too much difficulty, but I haven't looked into it). If absent, it might well impede the ability to do an advanced desktop port, but it wouldn't get in the way of porting the bulk of services. Unity, likely the only desktop environment using Upstart as a session init, is not in Debian. The sacrifice of this functionality on non-linux systems is perfectly acceptable. While this is true today, we need to look to the future. Using Upstart as a session init is not conceptually tied to Unity in any way, and I expect that other desktop environments will want to use more advanced session supervision soon enough. I place less importance on the session init capabilities of Upstart, as alternative home grown solutions ww.ritten by the environments are in place and are portable. Furthermore, portability of these environments hinges on a session and seat manager, ConsoleKit support in GNOME is quickly disappearing, and ConsoleKit itself is completely abandoned. What this means, to me, is there is a lot more effort required to accomplish this than to port Upstart's session init capabilities or use the current portable session inits. Sincerely, Cameron Norman -- Colin Watson [cjwat...@debian.org]
Bug#727708: init system thoughts
On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath nikol...@rath.org wrote: Colin Watson cjwat...@debian.org writes: The criticisms of Upstart's event model in the systemd position statement simply do not make sense to me. Events model how things actually happen in reality; dependencies are artificial constructions on top of them, and making them work requires the plethora of different directives in systemd (e.g. Wants, which is sort of a non-depending dependency) to avoid blocking the boot process on a single failing service. Yes, there are some bugs possible in the Upstart design, but I don't agree that those are world-ending fundamental issues and I think they're generally incrementally fixable. The systemd design appears to me to expose far more complexity to the user writing unit files, and I think it's important that their mental model be as straightforward as possible. (Now, I've been working with Upstart's model for years, and it's now a pretty fundamental way of how I think of system operation; so if people who are new to *both* models rather than partisans of one side or the other consistently tell me that the systemd model is easier to grasp, then I'll listen.) For what it's worth, I consider myself new to both the upstart and the systemd model, and for me the upstart event model has been pretty much the only reason to prefer systemd over upstart (though after reading Russ' opinion, that has changed a bit). For me, upstart was actually the reason for me switching from Debian to Ubuntu for a while. I am less familiar with systemd, so it may well be that I underestimate the complexities of the systemd model. However, I am very certain in my dislike for the upstart approach. My first point of criticism has already been described by Russ, but maybe I can make it clearer by giving an example. In my opinion, the following job looks completely harmless, and should not result in an unbootable system (but at least on Ubuntu 13.10 it does, you have to reboot with init=/bin/sh and remove/fix the evilJob.conf file): $ cat evilJob.conf start on (mounted MOUNTPOINT=/var and started lightdm) stop on runleves [016] respawn script exec /bin/sleep 60 end script I believe that the equivalent systemd unit (where dependencies are specified with Requires=) works just fine. It is not clear to me how this can be incrementally fixed in upstart without fundamentally changing the design. My second point is that by treating dependencies as events, upstart does not seem to truly recognize dependencies as such and is then unable to resolve them. For example, with the following two job files (created according to the upstart cookbook, 6.32.2): I think you raise a lot of good points in this email, but here you are saying something which may demonstrate your (understandable) confusion about the Upstart event model. Upstart does not treat dependencies as events. Often times, Upstart //jobs// treat dependencies as events (and the ones you wrote below do), but events do not signal a dependency. Just because you said that jobOne starts with jobTwo does not mean that jobOne needs jobTwo, just that during boot up jobOne will start with jobTwo. To express a dependency, jobTwo needs to have a start on (event where I am needed). If, for example, jobOne depends on a dbus interface of jobTwo, then jobTwo could have a start on dbus ... to show that dependency. Basically, to express dependencies in Upstart you express all the ways a job is needed inside of that job, not inside others. That said, Upstart developers and Ubuntu developers do not use Upstart this way and write jobs like you did below, so an Upstart system will most likely not act like I explained above (however this is not an inherent flaw in Upstart). I would also like to note that launchd acts the same exact way as I have described and had similar limitations. Furthermore, SystemStarter (Apple's previous init) acted in a very similar way to systemd: The hardest part to manage during a launchd boot is dependencies. SystemStarter had a very simple system of dependencies that used the Uses, Requires, and Provides keys in the plist of a startup item. There are two main strategies when creating launch dependencies on [OS X] . Using IPC will allow the daemons to talk amongst themselves to work it out, or you can watch files or paths for changes. Using IPC is much more subtle than the SystemStarter's keys and requires more work from the developer, but it may* https://en.wikipedia.org/wiki/Wikipedia:Citation_needed*lead to cleaner and quicker startups. -- https://en.wikipedia.org/wiki/Launchd#launchd I still think your points are relevant, however, because Upstart in Ubuntu acts in the same way as the below jobs, and Debian will most likely inherit that behavior if it uses Upstart. Happy New Year, Cameron Norman $ cat jobOne.conf start on (starting jobTwo and runlevel stop on runlevel [016]) stop
Bug#727708: init system thoughts
On Wed, Jan 1, 2014 at 5:09 PM, Nikolaus Rath nikol...@rath.org wrote: Cameron Norman camerontnor...@gmail.com writes: On Wed, Jan 1, 2014 at 4:00 PM, Nikolaus Rath nikol...@rath.org wrote: Colin Watson cjwat...@debian.org writes: The criticisms of Upstart's event model in the systemd position statement simply do not make sense to me. Events model how things actually happen in reality; dependencies are artificial constructions on top of them, and making them work requires the plethora of different directives in systemd (e.g. Wants, which is sort of a non-depending dependency) to avoid blocking the boot process on a single failing service. Yes, there are some bugs possible in the Upstart design, but I don't agree that those are world-ending fundamental issues and I think they're generally incrementally fixable. The systemd design appears to me to expose far more complexity to the user writing unit files, and I think it's important that their mental model be as straightforward as possible. (Now, I've been working with Upstart's model for years, and it's now a pretty fundamental way of how I think of system operation; so if people who are new to *both* models rather than partisans of one side or the other consistently tell me that the systemd model is easier to grasp, then I'll listen.) For what it's worth, I consider myself new to both the upstart and the systemd model, and for me the upstart event model has been pretty much the only reason to prefer systemd over upstart (though after reading Russ' opinion, that has changed a bit). For me, upstart was actually the reason for me switching from Debian to Ubuntu for a while. I am less familiar with systemd, so it may well be that I underestimate the complexities of the systemd model. However, I am very certain in my dislike for the upstart approach. My first point of criticism has already been described by Russ, but maybe I can make it clearer by giving an example. In my opinion, the following job looks completely harmless, and should not result in an unbootable system (but at least on Ubuntu 13.10 it does, you have to reboot with init=/bin/sh and remove/fix the evilJob.conf file): $ cat evilJob.conf start on (mounted MOUNTPOINT=/var and started lightdm) stop on runleves [016] respawn script exec /bin/sleep 60 end script I believe that the equivalent systemd unit (where dependencies are specified with Requires=) works just fine. It is not clear to me how this can be incrementally fixed in upstart without fundamentally changing the design. My second point is that by treating dependencies as events, upstart does not seem to truly recognize dependencies as such and is then unable to resolve them. For example, with the following two job files (created according to the upstart cookbook, 6.32.2): I think you raise a lot of good points in this email, but here you are saying something which may demonstrate your (understandable) confusion about the Upstart event model. Upstart does not treat dependencies as events. Often times, Upstart //jobs// treat dependencies as events (and the ones you wrote below do), but events do not signal a dependency. Just because you said that jobOne starts with jobTwo does not mean that jobOne needs jobTwo, just that during boot up jobOne will start with jobTwo. To express a dependency, jobTwo needs to have a start on (event where I am needed). If, for example, jobOne depends on a dbus interface of jobTwo, then jobTwo could have a start on dbus ... to show that dependency. I think I understand what you're saying, thanks for the explanations! However, I can't say that this improved understanding has improved my opinion about upstart. If I understand correctly, this means that either a) every upstart job definition needs to explicitly list every possible way in which another service may depend on it (and, furthermore, every possible such dependency needs to have upstart integration so that it can actually be used as an event) Pretty much all IPC mechanisms have integration into Upstart, so a lot of dependencies are covered. or b) a package providing jobOne that depends on jobTwo from another package needs to patch the *other* package's configuration to add the dependency information to jobTwo's definition. Yes. The patch would, however, be limited to a or (...) in the start on section. So it is not like the patch is going to change a ton. Neither of this sounds appealing to me at all, especially compared to systemd, where all you have to do is drop a Requires= line into jobOne's configuration. I agree, especially when one can have a Requires=*.socket or Requires=*.bus and get the same benefits. Basically, to express dependencies in Upstart you express all the ways a job is needed inside of that job, not inside others
