Bug#835507: Please clarify that sysvinit support decision is not going to expire
On 08/28/2016 08:37 AM, Bart Schouten wrote: > Sam Hartman schreef op 28-08-2016 1:37: >> Similarly, if the community of people who care about sysvinit is >> unwilling to spend the time keeping it working, eventually sysvinit >> as a whole will be unmaintained and buggy. > > True, but I don't think those conditions are there. Not yet, but a lot of sysvinit-related stuff still hasn't been adopted after being orphaned. > I mean that the statements: > > a) the scripts need (urgent) maintaining > > and > > b) in the context of the actual maintaining they do need, the help > that is necessary isn't there. > > Are not true. I would agree that in this specific case, a) is not true (there's no apparent problem with them that wasn't already there in Wheezy), but I'm honestly not at all sure about b). To bring out my pet example: with sysvinit systems, in Jessie it's not possible to have /usr on NFS anymore. The reason is that mount.nfs is now linked against a library in /usr. I reported the bug [1] before the release of Jessie (and I only found it because I was testing stuff with sysvinit, I don't use it regularly at all). But nothing happened. Then when the whole monster /usr-merge thread happened on debian-devel half a year ago, I brought up that bug again, and nobody seemed to care either. With systemd this bug doesn't occur, because on systemd systems the /usr partition is mounted in the initrd - so you can indeed boot /usr on nfs with Jessie - but only with systemd. To be fair: the mounting of /usr in initramfs now happens regardless of init system also in Stretch, so the bug will now only appear if you don't use an initramfs. But it was not sysvinit people who made that work, but Ben Hutchings who NMU'd initscripts. [2] Actually, the only people who appear to be improving sysvinit support in Debian at the moment appear to be systemd users. And the only thing I hear from sysvinit users are complaints. > I think the "maintainership requirement" of those scripts are > currently being exaggerated, In this specific case? Probably. When the thread that started this TC bug popped up on debian-devel, I was on your side: those scripts shouldn't have been removed. Heck, I even wrote init scripts for something I packaged recently. (Admittedly, that was a simple daemon and the init script is trivial, see [3].) However, I've been working on something for the last couple of months (on and off) to write some code to make stuff work on sysvinit for one package I maintain, which I wouldn't need to do if I just wanted to support systemd. Currently there's a huge workaround in the package that is awful in every regard. And I really want to get rid of the workaround, because it is detrimental to users in other ways (and the workaround also affects systemd users), and do it properly. But when I read stuff such as this: > ... warehouse of troubles that need a million hours of employment > each year to keep it going ... > - you will hate the day when you discover you've been scammed ... Or, when other people constantly and irrationally bring up libsystemd0 again and again (see the current debian-devel thread), then sorry, these kinds of comments make me lose any motivation in still working on helping people out with sysvinit. It's becoming more and more appealing to me to just say "screw sysvinit users", I don't care anymore. I'm not there yet, but I suspect that I'm not the only one who feels that way, so please, continue with this kind of rhetoric, and see where you'll be at in a few years. > Anyone writing an actual SysV init script would have thought of those > things. That person would have felt responsible for it, because no > one else would do it for you. That person would have built more > intelligence into the startup script. No, sorry, that's simply patently untrue. There are some good init scripts out there, but the vast majority of them are just plain horrible. They kind of work, but they make a lot of assumptions that break in a lot of corner cases. And writing good init scripts is _really_ hard, because shell programming is awful. (Useful, but awful.) Heck, even the skeleton Debian init script is completely useless for use in a Pacemaker/HA environment - because start/stop will _always_ return exit code 0, regardless of whether it worked or not. (Only status returns different exit codes.) With sysvinit I have _always_ had to patch init scripts to return proper error codes when I wanted to use them in a HA environment. (And I've done that since Squeeze, where there was no systemd.) This violates LSB btw. (No, I didn't file a bug against the initscripts package, let alone an MBF against all daemons with this problems, not even before systemd was even a thing during Squeeze times, because it was already very clear to me from just looking at the bug list that nobody seemed to care about maintaining the package properly, and I'd just be wasting my time.) So yeah, for me sysvinit scripts are
Re: Bug#762194: Automatic switch to systemd on wheezy-jessie upgrades (thoughts)
Am 2014-12-04 18:21, schrieb Adam Borowski: On Thu, Dec 04, 2014 at 05:25:26PM +0100, Christian Seiler wrote: - Switchig depends order of init [1] (sysvinit-core before systemd-sysv) - won't work, because init is Essential, but systemd-sysv isn't, so this change would default the init system to sysvinit for jessie (which is against the TC ruling from earlier this year, so unless you'd want to overrule that... ;-)) That's why in my proposal the installation of systemd-sysv by default is moved to debootstrap. Unfortunately, that has its own set of problems. People want to be able to bootstrap jessie from other distributions, and from previous Debian versions (which is why an update to debootstrap was accepted into s-p-u recently to fix a bug so that jessie could be bootstrapped from jessie, see [1]). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768444 Note that there is also cdebootstrap, which you'd also have to modify, and I honestly don't know what some other tools that can install Debian use internally do. Also, it is intuitive to keep changes to the default install in debootstrap rather than in dependencies. And it makes future changes of the default easy without breaking existing systems. With the init metapackage, if it stays the way it is, then this is not the case - because a change in the init metapackage order will not affect existing systems anymore, it will just affect new systems. So instead of hardcoding behavior in debootstrap, dependencies are precisely the right way to go, in my eyes. As for reasons not to switch, you did not mention the multitude of breaks the whole system (ie, severity:critical) bugs in common configurations. These include: * vservers/containers If you look at what most container solutions do in order to 'support' current systems, they override quite a lot of the init script logic in order not to do stuff they shouldn't do. With the current state of things, I never had the expectation that dist-upgrading a container would even remotely work, and I've never tried that. Note that containers have been painful for upgrades anyway, since Etch/Lenny had VServer and something else, Squeeze still had VServer but only if using the official kernel, if your hardware required you to use a backports kernel, then you couldn't use VServer anymore. In with Squeeze came LXC as a possible alternative, but when it came to Wheezy, subtle stuff changed again (e.g. /run directory, especially if you wanted to run the container without CAP_SYS_ADMIN). Also: jessie will be the first version of Debian that will have a kernel that supports unpriviledged (user namespace) containers. That alone is something worth reinvestigating the current setup for. So my expectation for containers has always been: build it again on the new operating system version, and then migrate the data over. In fact, systemd actually gives me hope that this might not be the case anymore in the not-too-distant future. For jessie it probably won't work that way yet, but for stretch onwards (read: strech - buster upgrades) I really am hopeful that it will finally be possible to just upgrade your container and everything will just work[tm]. Which has never been my experience so far. * chroots that run daemons What do you mean? systemd supports daemons with chroot just fine, either directly (RootDirectory=) or even using traditional init scripts. * some configurations of encrypted lvm Could you point me to a bug report on this? I'd like to help out with that. I have systemd running on my home computer with an encrypted LVM, and it does work, so what you are referencing is probably a nasty bug that could be fixed. * custom kernels (including those you can't upgrade) That is indeed a problem. * nonexistant filesystems in fstab (this one is being worked on) I did mention that in my email. Thus, the potential for breakage is simply too big. This is similar, but bigger in scope than the grub1-grub2 switch some years ago. Well, in the end, it comes down to priorities, as to how much breakage Christian -- 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/57d7f2a72b8bbe7cb5edd00c0fe0e...@iwakd.de
Bug#762194: Automatic switch to systemd on wheezy-jessie upgrades (thoughts)
Sorry, stupid webmail, sent my email to early... and only to the mailing list, not the bugtracker... :( To make sure it's recorded in the bug, and I also added something to the end: Am 2014-12-04 19:31, schrieb Christian Seiler: Am 2014-12-04 18:21, schrieb Adam Borowski: On Thu, Dec 04, 2014 at 05:25:26PM +0100, Christian Seiler wrote: - Switchig depends order of init [1] (sysvinit-core before systemd-sysv) - won't work, because init is Essential, but systemd-sysv isn't, so this change would default the init system to sysvinit for jessie (which is against the TC ruling from earlier this year, so unless you'd want to overrule that... ;-)) That's why in my proposal the installation of systemd-sysv by default is moved to debootstrap. Unfortunately, that has its own set of problems. People want to be able to bootstrap jessie from other distributions, and from previous Debian versions (which is why an update to debootstrap was accepted into s-p-u recently to fix a bug so that jessie could be bootstrapped from jessie, see [1]). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768444 Note that there is also cdebootstrap, which you'd also have to modify, and I honestly don't know what some other tools that can install Debian use internally do. Also, it is intuitive to keep changes to the default install in debootstrap rather than in dependencies. And it makes future changes of the default easy without breaking existing systems. With the init metapackage, if it stays the way it is, then this is not the case - because a change in the init metapackage order will not affect existing systems anymore, it will just affect new systems. So instead of hardcoding behavior in debootstrap, dependencies are precisely the right way to go, in my eyes. As for reasons not to switch, you did not mention the multitude of breaks the whole system (ie, severity:critical) bugs in common configurations. These include: * vservers/containers If you look at what most container solutions do in order to 'support' current systems, they override quite a lot of the init script logic in order not to do stuff they shouldn't do. With the current state of things, I never had the expectation that dist-upgrading a container would even remotely work, and I've never tried that. Note that containers have been painful for upgrades anyway, since Etch/Lenny had VServer and something else, Squeeze still had VServer but only if using the official kernel, if your hardware required you to use a backports kernel, then you couldn't use VServer anymore. In with Squeeze came LXC as a possible alternative, but when it came to Wheezy, subtle stuff changed again (e.g. /run directory, especially if you wanted to run the container without CAP_SYS_ADMIN). Also: jessie will be the first version of Debian that will have a kernel that supports unpriviledged (user namespace) containers. That alone is something worth reinvestigating the current setup for. So my expectation for containers has always been: build it again on the new operating system version, and then migrate the data over. In fact, systemd actually gives me hope that this might not be the case anymore in the not-too-distant future. For jessie it probably won't work that way yet, but for stretch onwards (read: strech - buster upgrades) I really am hopeful that it will finally be possible to just upgrade your container and everything will just work[tm]. Which has never been my experience so far. * chroots that run daemons What do you mean? systemd supports daemons with chroot just fine, either directly (RootDirectory=) or even using traditional init scripts. * some configurations of encrypted lvm Could you point me to a bug report on this? I'd like to help out with that. I have systemd running on my home computer with an encrypted LVM, and it does work, so what you are referencing is probably a nasty bug that could be fixed. * custom kernels (including those you can't upgrade) That is indeed a problem. * nonexistant filesystems in fstab (this one is being worked on) I did mention that in my email. Thus, the potential for breakage is simply too big. This is similar, but bigger in scope than the grub1-grub2 switch some years ago. Well, in the end, it comes down to priorities, as to how much breakage people consider acceptable, in contrast to the other upsides and downsides of the change. I don't think it is unreasonable that some people come down on the other side of this issue. As I said in my first email, I don't think there is an easy answer here. Christian -- 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/7a227d36ce9b9b23dcb52cc433538...@iwakd.de
Bug#746578: libpam-systemd to flip dependencies - proposal
Am 04.11.2014 17:07, schrieb Josh Triplett: This isn't a complete showstopper, since most of the time people seem to debootstrap a standard system and then install additional packages. However, it would affect a debootstrap with --include=task-desktop or --include=gnome or similar. Just as a side note: I never use debootstrap to actually include anything that wouldn't be considered 'base system', just because I've had the experience that quite a few packages don't work together with debootstrap (try doing --include=syslog-ng (and --exclude=rsyslog) while debootstrapping wheezy - the dependency resolution works properly, but the package won't install, because the preinst or postinst scripts don't like debootstrap's environment (the rsyslog exclude alone works btw., so that's what I'm doing if I want something with syslog-ng)). I have some real doubts that debootstrap is going to be able to set up something like GNOME or task-desktop or whatever, just because they probably are going to pull in lots of packages of which at least a couple are going to have similar problems to the aforementioned one I had with syslog-ng. Therefore, I always tend to use debootstrap to just install a very, very basic system and then use apt-get in a chroot to install the rest of the software, if I decide to install a Debian image like that. This in mind, looking at apt-cache rdepends libpam-systemd[1], I don't see anything in there I'd want to include in debootstrap. But maybe that's just me. Does anyone see an obvious way to structure the dependencies to avoid this result and only install systemd-sysv? I don't think that's possible if you want to keep the effect the switching the dependencies has (i.e. selecting systemd-shim as first alternative so that systems without systemd as pid1 don't try to install systemd-sysv when packages depending on logind are installed). I haven't tested the upgrade scenario. I appreciate the test you already ran. I'd love to see an upgrade test as well (from a system with sysvinit installed), but this test already revealed an issue. - Fresh install of Debian Wheezy (from netinst CD) - tasksel: Standard utilities + SSH server - aptitude full-upgrade - aptitude install --without-recommends gdm3 (package that pulls in libpam-systemd in Jessie, without installing too much, although gdm3 itself already pulls in quite a lot on wheezy, in hindsight probably should have gone with network-manager...) - Then edit sources.list, remove everything wheezy-related, add my modified mirror, apt-get update Then this gives the following consequences: - apt-get upgrade: * doesn't try to upgrade enough packages that you could call the system jessie, doesn't pull in anything systemd related other than trying to upgrade libsystemd-login0 (already installed on wheezy because of a Depends of dbus) - apt-get dist-upgrade * pulls in systemd-shim - aptitude full-upgrade * pulls in systemd-shim - aptitude upgrade (i.e. safe-upgrade) * takes a couple of minutes to resolve deps (granted, running in a VM, but I have a fast CPU, so this is really unusual, never seen aptitude working so long before, but OTOH I've never done a dist-upgrade with aptitude before, so maybe that's normal?) * DOES NOT pull in systemd-shim - didn't test any other frontends (I'm not showing any detailed package lists here because there's just too much unrelated stuff.) Christian [1] Depended on by: udisks2, policykit-1, network-manager, lightdm*, gnome-settings-daemon, gnome-bluetooth, gdm3 Recommended by (not relevant for deboostrap IIRC): xfce4-session, xfce4-power-manager, systemd, gnome-session-bin, argyll (* Depends: libpam-systemd | consolekit) PS: I tested this because I think it's better to have all the relevant information before deciding an issue, please don't interpret my email as being critical of the proposed resolution. -- 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/54592660.5000...@iwakd.de
Bug#746578: libpam-systemd to flip dependencies - proposal
Am 02.11.2014 06:59, schrieb Josh Triplett: Apart from that, I would still request that someone with the ability to produce a modified local mirror test the two critical cases mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#129 . If those two cases work, then systemd systems should not end up with systemd-shim installed under normal circumstances, making breakage far less likely. debootstrap 1.0.64 on a current Jessie box with a locally modified and otherwise up-to-date (2014-11-04T05:00Z) mirror wants to pull in the following packages[1]: acl adduser base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debianutils diffutils dmsetup dpkg e2fslibs e2fsprogs findutils gcc-4.8-base gcc-4.9-base grep gzip hostname init init-system-helpers initscripts insserv libacl1 libattr1 libaudit-common libaudit1 libblkid1 libbz2-1.0 libc-bin libc6 libcap2 libcap2-bin libcomerr2 libcryptsetup4 libdb5.3 libdebconfclient0 libdevmapper1.02.1 libgcc1 libgcrypt20 libgdbm3 libgpg-error0 libkmod2 liblocale-gettext-perl liblzma5 libmount1 libncurses5 libncursesw5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libpcre3 libprocps3 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libsmartcols1 libss2 libsystemd0 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libtinfo5 libudev1 libustr-1.0-1 libuuid1 login lsb-base mawk mount multiarch-support ncurses-base ncurses-bin passwd perl perl-base perl-modules procps sed sensible-utils startpar systemd systemd-sysv sysv-rc sysvinit-utils tar tzdata udev util-linux zlib1g apt apt-utils bsdmainutils cgmanager cpio cron dbus debian-archive-keyring dmidecode gnupg gpgv groff-base ifupdown iproute2 iptables iputils-ping isc-dhcp-client isc-dhcp-common kmod less libapt-inst1.5 libapt-pkg4.12 libboost-iostreams1.55.0 libcap-ng0 libcgmanager0 libdbus-1-3 libdns-export100 libestr0 libexpat1 libffi6 libglib2.0-0 libgmp10 libgnutls-deb0-28 libgnutls-openssl27 libhogweed2 libicu52 libidn11 libirs-export91 libisc-export95 libisccfg-export90 libjson-c2 liblogging-stdlog0 liblognorm1 libmnl0 libnetfilter-acct1 libnettle4 libnewt0.52 libnfnetlink0 libnih-dbus1 libnih1 libp11-kit0 libpam-systemd libpipeline1 libpopt0 libpsl0 libreadline6 libsigc++-2.0-0c2a libssl1.0.0 libstdc++6 libtasn1-6 libusb-0.1-4 libxtables10 logrotate man-db manpages nano net-tools netbase netcat-traditional nfacct readline-common rsyslog systemd-shim tasksel tasksel-data traceroute vim-common vim-tiny wget whiptail I've also tried debootstrap 1.0.62 on a Fedora 19 box with the same mirror, with the same results. Note that systemd-shim together with cgmanager is pulled in. My guess is that there's some greediness in the dependency resolver in debootstrap, and as long as there's no conflict, it won't try to follow other alternatives to see if the dependencies have already been met. Also note that neither --exclude=systemd-shim,cgmanager nor --exclude=systemd-shim seem to have no effect whatsoever on the list of packages. (Which is probably a bug in debootstrap, because it should at least warn you if it can't fulfill the specified --exclude, but also in this case it could actually exclude it...) I haven't tested the upgrade scenario. Christian [1] debootstrap --print-debs --no-check-gpg \ --include=libpam-systemd jessie $DIR $MIRROR PS: Diff of the stuff that is pulled in compared to the same command done in the current archive (after sorting the package list): @@ -7,6 +7,7 @@ bash bsdmainutils bsdutils +cgmanager coreutils cpio cron @@ -57,6 +58,7 @@ libcap2-bin libcap-ng0 libc-bin +libcgmanager0 libcomerr2 libcryptsetup4 libdb5.3 @@ -70,6 +72,7 @@ libgcc1 libgcrypt20 libgdbm3 +libglib2.0-0 libgmp10 libgnutls-deb0-28 libgnutls-openssl27 @@ -94,6 +97,8 @@ libnettle4 libnewt0.52 libnfnetlink0 +libnih1 +libnih-dbus1 libp11-kit0 libpam0g libpam-modules @@ -153,6 +158,7 @@ sensible-utils startpar systemd +systemd-shim systemd-sysv sysvinit-utils sysv-rc -- 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/54587669.4000...@iwakd.de
