Re: Frustration over Debian naming
rhkramer: Intentionally cross posted. Aside: For those on the debian-user lists, the thread came from the debian-backports list, but my frustration should probably be expressed more to the debian-user list (or debian-developer list, assuming there is such a list (to which I am not subscribed). [...] But the various names and use of those names gets very frustrating for me, and I suspect I am not the only one. The numbered versions, the Toy Story names, and then the testing, stable, old stable, old old stable is just frustrating. Tangentially to that, it seems that someone needs to pick up the dropped baton and update the pictures. * http://wiki.lib.sun.ac.za/images/thumb/a/aa/Timelinededebian.png/800px-Timelinededebian.png * http://blog.admin-linux.org/wp-content/uploads/2012/01/infographic_debian_history-en-v081.png * http://doc.callmematthi.eu/pictures/Understanding_Debian.png * https://i.stack.imgur.com/nLXu9.jpg * https://bsdmag.org/wp-content/uploads/2016/08/infographic_debian-v2.1.en_.png
Re: bind9 shipping outdated root hint file (etc.)
Robert Edmonds: The only package in the archive that I know of that has a seriously deficient set of root hints is djbdns; it has 11/13 of the current set of IPv4 root server addresses, and 0/13 IPv6 root server addresses. (However, I don't believe the 'djbdns' binary package ships with the IPv6 patch applied.) What you know is somewhat wrong. dnscache does not use a "hints" mechanism. It uses a list of the actual servers. People patched this list *years ago*. P. J. Pandit, publisher of ndjbdns for Fedora, updated xyr published copy of the list in 2013. I had an updated list in the very first published version of djbwares. * http://jdebp.eu./Softwares/djbwares/ I later fixed ip6.arpa and removed the egregiously outdated RBL list, too. * https://lists.debian.org/debian-user/2017/03/msg01307.html But that is as nothing. I *first* patched this list almost *a decade and a half ago*. * http://jdebp.eu./FGA/djbdns-problems.html#wrong-icann-root Debian's list in its djbdns package is actually a private Debian one that is substituted by Debian in place of the one from the djbdns itself, named debian/dnsroots.global . Debian needs to catch up.
Re: Debian Hurd installer fixed since 2014?
Samuel Thibault: > Memory management is being worked on and there have been > various fixes, yes. Jonathan de Boyne Pollard: > I'll give it another go when I get the time, then. As promised, I have given it another go, with your latest DVD image dated January 2017. The good news is that the installer succeeds, and doesn't hang trying to install exim as before. The bad news is that networking fails quite badly. ssh to 127.0.0.1, where OpenSSH is listening, works repeatedly *until* the first time that I attempt to connect to any non-loopback address, whereupon IP networking stops connecting to anything at all, loopback or no. It also breaks shutdown, which just hangs at "Deconfiguring network interfaces". Shutdown succeeds if I only touch loopback networking. Also: Exiting aptitude with "q" "y" does not complete until it is sent a SIGINT. The hurd console does not properly draw the screen at startup (resulting in an extra "login:" line at the bottom of the screen). The WWW page's assertion that there is an inetutils-ping package appears to be false. And the hurd console does odd things (that the Mach console does not) with a U.K. keyboard layout, in particular with Shift+3 .
Mass bug filing: use and misuse of dbus-launch (dbus-x11)
XDG Base Directory Specification:
If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning
message
Simon McVittie:
Are you saying that if XDG_RUNTIME_DIR is not set, D-Bus client
libraries should choose some arbitrary other directory that is
conjectured to have the same properties that the XDG_RUNTIME_DIR spec
guarantees, look for a ./bus socket in *that* directory [...]?
Simon McVittie:
Using the same concrete value for the name of the XDG_RUNTIME_DIR that
systemd does (/run/user/$numeric_uid) seems advisable, [...]
These two fit together, you know.
You think that a good "replacement directory" is /run/user/$EUID .
Alright. Then when your program is told address=unix:runtime=yes and
there's no XDG_RUNTIME_DIR, please make it fall back to using the
directory that you think is the advisable directory to use. (-:
At the moment, as far as I can see, when there's no XDG_RUNTIME_DIR
there's no fallback per the XDG specification at all. We all know that
XDG_RUNTIME_DIR has been a thorn in people's sides for years, where
there is a mismatch between the owner of the runtime directory and the
process' effective user. The irony is that you and your program would
get quite sensible behaviour without it, were you to make
address=unix:runtime=yes actually do the thing that you are here saying
is advisable. In the cases where address=unix:runtime=yes is used, and
when they are all doing what you say is advisable, your servers set up
their sockets in {/var,}/run/user/$UID/dbus_blah and your clients go
looking for those sockets in the same place, picking the right one for
the process' effective UID and rendezvousing in the right place.
And the people who still want XDG_RUNTIME_DIR still get to have it, and
all of its do-we-or-do-we-not-follow-euid-changes-maybe-sometimes joy
that the world has come to know and love.
This as well as having made address=unix:runtime=yes actually work in
the first place, of course. (-:
Mass bug filing: use and misuse of dbus-launch (dbus-x11)
Simon McVittie: This can already work. If you put XDG_RUNTIME_DIR in user programs' environment, and arrange for your favourite service manager to make a dbus-daemon (or something else that speaks the same protocol) listen on $XDG_RUNTIME_DIR/bus before any user process would try to connect to it, then modern versions of at least libdbus, GDBus and sd-bus will connect to it by default with no additional effort on your part. This client-side code path does not depend on systemd, does not depend on libsystemd (except obviously sd-bus which is part of libsystemd), and is compiled in for all supported Unix platforms. That's the problem. No the whole unix:runtime=yes mechanism is not. As I said, this is something that you and Joe Marcus Clarke and whomever else have to sort out with each other. I'm unfortunately stuck in the middle, here. Please do whatever it is that you need to do with each other to make your program understand address=systemd: and address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not do so. Simon McVittie: Meanwhile, if you want the relevant integration files (your favourite service manager's equivalent of systemd units) to be part of dbus (the reference implementation of D-Bus), please propose tested patches; if they follow the "user session" model[1], they could eventually go in dbus-user-session.deb, with its dependencies changed from the current systemd-sysv to "systemd-sysv | your-service-manager". Kudos for being the first project to offer integration, ever. (-: Yes, down the road it would be marvellous if people included service bundles in their own projects. Yes, I'd like to see the day when the number of service bundles in the nosh-bundles package actually starts going down, because people are taking on shipping their own service bundles for their own services, instead of going up. So yes, eventually you'll be taken up on that offer I hope. But one step at a time. Simon McVittie: As for what I would like, I'd like you (where that's plural, including Joe Marcus Clarke or whomever else) to please make either address=systemd: or address=unix:runtime=yes work in your program on FreeBSD/PC-BSD/OpenBSD. To the best of my knowledge, the listenable address "unix:runtime=yes" (as in "dbus-daemon --address=unix:runtime=yes") does work on generic Unix, and should interoperate fine with the XDG_RUNTIME_DIR/bus fallback used by clients with no DBUS_SESSION_BUS_ADDRESS. It is compiled and tested whenever DBUS_UNIX is defined (i.e. everything except Windows), and I haven't seen bug reports about that test failing. There you go, then. New knowledge. (-: It doesn't work with your program as ported to FreeBSD/TrueOS/OpenBSD. Joe Marcus Clarke is the porter for FreeBSD, according to the port information, and Antoine Jacoutot the porter for OpenBSD. This is why I am saying that it's something that you (plural, remember) need to sort out amongst yourselves. We users stuck in the middle cannot use address=systemd: and address=unix:runtime=yes with your program on these systems. As I said, it's something that I had to fix in November 2015, to stop trying to use address=systemd: on FreeBSD/TrueOS because it turned out that it didn't actually work. I thought that address=unix:runtime=yes might, but that did not either. Simon McVittie: I am *not* going to go looking for patches on display at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "beware of the leopard"; Luckily, you didn't need to. The page that I hyperlinked before pointed directly to Pierre-Yves Ritschard's and Cameron T. Norman's actual code, even down to positioning the window around the first lines of the functions. Now if one *did* want to follow the Debian way of having mention of these things buried down in the depths, in a bug report from years ago, then this is a truly excellent example of the genre that one could enjoy. One should begin with Cameron T. Norman's post here, roughly one thousand eight hundred messages down, in a bug report from 3 years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1859 (-: Simon McVittie: To be brutally honest, there is a fairly low limit to how much benefit I can create by giving new things to PC-BSD users, [...] That's not the right way to look at it. You yourself have just said several times that this is stuff that is supposed to be on "supported Unix platforms". This isn't giving new things to anyone. This is making existing things, that you yourself think are existing, work. I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD (now rebranded as TrueOS Desktop a few days ago -- I just got through changing a whole load of preset file and -run package names.) is the BSD that comes in the box with the desktop environments and with all of the desktop programs that use Desktop Bus. Yes, people can and do run
Subjects and threads
Adam D. Barratt: > I'm sure I'm not the only one irritated by this, Then you should be looking at the Debian software that drives https://lists.debian.org/ , which seriously mucks up subject processing, and not at us poor users who are long-suffering under it. Debian software gets References: wrong, too; which is in fact the way that one recognizes replies. See RFC 2822 §3.6.5, which points out that Re: is not what you think it is and describes just some of the processing that Debian software is not doing (Try subjects with reserved punctuation characters for even more fun!), and RFC 2822 §3.6.4, which talks about replies and the References: header. * https://jdebp.eu./Proposals/gnksoa-mua.html#ProperThreading If you had directed your irritation to the bug area for the Debian software rather than at the poor Debian software end-users, you would have found that several bugs about some of these very things were filed years ago, and remain unfixed to this day. As a Debian Developer, you could probably fix these bugs.
Is missing SysV-init support a bug?
Gerrit Pape: To me too this readiness IPC ideas and implementations look over-engineered. A good convention for service programs would be to functionally test for services it needs very early on startup, and fail if dependencies are not available. The service supervisor (any modern init scheme seems to now support this) relaunches eventually, until all dependencies are fulfilled. The problem with the thundering herd approach is twofold. Firstly, it really does matter in practice when the machine has tens if not hundreds of client processes all continually restarting whilst they wait for (say) the RabbitMQ server to come up. Secondly, these explanations never seem to take system shutdown into account. In the ordered services world, shutdown order is the reverse of startup order, and things generally work. In the thundering herd world, often the theory is just to send terminate and kill signals willy-nilly to every service on the system. This almost never works cleanly in any but the most trivial systems. (People will no doubt be thinking the classic example of NFS mounts, here. But there are all sorts of possibilities, from /var/ being unmounted before logging services are turned off to the proxy DNS server being turned off whilst other services are still doing DNS lookups.) We discussed this on the Supervision mailing list last year: http://www.mail-archive.com/supervision%40list.skarnet.org/msg00673.html
Is missing SysV-init support a bug?
Gerrit Pape: My suggestion was and still is to separate services from programs on the package level, [...] I vaguely remember from the systemd packaging Hoo-Hah someone else advocating this idea. I don't recall who it was off the top of my head. Gerrit Pape: I was not successful to convince fellows back then. I wouldn't say that. * https://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run And there's the division between systemd and systemd-sysv, too.
Debian Hurd installer fixed since 2014?
Samuel Thibault: How much memory did the box have? 2GiB. So it's not that. (-: Samuel Thibault: Memory management is being worked on and there have been various fixes, yes. I'll give it another go when I get the time, then.
Debian Hurd installer fixed since 2014?
Richard Braun: Note that installing a mail transfer agent on an isolated system actually makes sense. It's one way between local users to communicate, and it's used by apt to notify you about some important changes when you install/upgrade packages. Besides, it's a pure Debian thing, unrelated to the Hurd. It doesn't make sense on a system where I am the sole local user and I can see the installation notices on the screen right in front of me when I am doing such upgrades. It's related to the Hurd inasmuch as the Debian installer *makes it impossible for us users to install Debian Hurd*. That approach to this is backwards. Considering exim to be mandatory, even on a system with no networking, one user, and no need whatsoever for anything other than some C++ development tools, results in the installer failing when it tries to configure exim and Debian Hurd to be uninstallable by design. Whereas considering exim to be optional (which seems very likely given that there's a checkbox in the Debian installer where "mail" can be deselected) means that this is, rather, an installer problem (of some sort: I'm not ruling out the possibility that it was secretly doing something else when it said that it was configuring exim on the screen.) to be corrected.
A wide range of terminals that can do italics
Adam Borowski: Hmm... 1 out of 11¹ implementing italics plus one doing some other thing doesn't strike me as a "wide" range. I didn't bother to test terminals I don't have installed at the moment but the above sample shouldn't be much off. Aside from the tests in your list that you somehow got wrong, as M. Thibault has already pointed out, you've actually managed to carefully pick some of the very terminal emulators (the terminal emulator programs in the Linux, FreeBSD, and OpenBSD kernels) that the nosh user-space virtual terminal system is aimed at replacing, with full ECMA-48 attribute support being one of the very features that it has in comparison to them. So yes, you've got quite a skewed sample there and it is rather off. Just some of the terminals that handle control sequences for italics that you did not pick: iTerm2, fbpad, the Tandem TA6530, tilda, yakuake, Kermit 95, sakura, GNU Hurd console server, termite, Suckless simpleterm, terminix, ZOC, pantheon-terminal, IRIX xwsh, InnerSystem's TelStar, UnixSpace Terminal, fbterm, konsole, Rebex .NET terminal emulator, HyperTerm, ... Coming soon: guake (https://github.com/Guake/guake/issues/703), Terminator (https://bugs.launchpad.net/terminator/+bug/1287794/comments/6) (ZOC -> http://emtec.com/zoc/ UnixSpace Terminal -> http://unixspace.com/download/ fbpad -> http://repo.or.cz/fbpad.git Suckless simpleterm -> http://st.suckless.org/ yakuake -> https://kde.org/applications/system/yakuake/ sakura -> http://pleyades.net/david/projects/sakura/ Rebex -> http://rebex.net/terminal-emulation.net/ HyperTerm -> https://hyperterm.org/)
Is missing SysV-init support a bug?
Russ Allbery: But change sucks, and part of what accreted was decades of subtle workarounds to poorly-documented issues for which we have minimal institutional memory. Like fulfilling the 1970s Unix promise of italics in manual pages, on the wide range of terminals that /can/ /do/ /italics/: stymied on Debian and only documented by a note at the bottom of a closed and forgotten bug report filed roughly a decade and a half ago against a long since superseded version. A couple of Hitch-Hiker's Guide to the Galaxy quotations come to mind. * https://jdebp.eu./Softwares/nosh/italics-in-manuals.html Russ Allbery: And the actual position appears to be something around "we're building it as separate components because that's just good engineering, but we don't particularly care about use cases that involve picking and choosing specific components and are not really prioritizing them," which is essentially perfectly positioned to make no one happy and all discussions around modularity arrive at frustratingly inconclusive loose ends. This is another thing that falls under the umbrella of the world changing since 2014, note. There have been discussions amongst the systemd developers about modularity, more recently. They've been tentative and limited in scope, haven't resulted in any concrete outcome yet, and haven't filtered through to the Debian/Ubuntu world, but they have been there. Russ Allbery: I mostly pipe up here occasionally to poke at evidence from the "systemd is horrible" side [...] there's a bunch of nonsense on the pro-systemd side too [...] I don't think that I've pointed you to this already, but if not you definitely need to read this: * http://uselessd.darknedgy.net./ProSystemdAntiSystemd/ The same person (whose name I don't know) later wrote these: * http://blog.darknedgy.net/technology/2015/09/05/0/ * http://blog.darknedgy.net/technology/2015/10/11/0/
libsystemd
Dmitry Bogatov: Thanks history, we have pid files, not `libpid' to talk to `pidd'. Jonathan de Boyne Pollard: You have forgotten about the existence of Debian Hurd. (-: * https://jdebp.eu./FGA/hurd-daemons.html#proc Samuel Thibault: The Hurd precisely tries to expose things as files. Not in this case. I pointed earlier to the "pidd". Debian Hurd doco and GNU Hurd doco are really bad, so here's the best of a bad job; the raw API for the "libpid": * http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs
libsystemd
Russ Allbery: I think that... says the same thing I said? Read again, and let your eye dwell upon Laurent Bercot's name this time. (-: The world has changed since 2014 and the Debian systemd packaging Hoo-Hah, and I've been keeping tabs. * https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#Choice * http://skarnet.org/software/s6-rc/ * http://skarnet.org/software/s6-linux-init/ * https://github.com/OpenRC/openrc/blob/HEAD/s6-guide.md * https://news.ycombinator.com/item?id=11675129 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 * http://www.mail-archive.com/supervision@list.skarnet.org/msg01351.html * https://tracker.debian.org/pkg/runit * https://lists.debian.org/debian-user/2016/08/msg00182.html * https://www.freebsd.org/news/status/report-2015-10-2015-12.html
libsystemd
Dmitry Bogatov: Thanks history, we have pid files, not `libpid' to talk to `pidd'. You have forgotten about the existence of Debian Hurd. (-: * https://jdebp.eu./FGA/hurd-daemons.html#proc
Mass bug filing: use and misuse of dbus-launch (dbus-x11)
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
Please contact the D-Bus upstream mailing list if you are interested
in implementing a user bus without systemd. You will need something
resembling pam_xdg_support (which is what Ubuntu used before they
switched to systemd) to provide the XDG_RUNTIME_DIR,
Wrong tense. (-: I already gave it to people with nosh version 1.20
back in September 2015. The external configuration import subsystem
sets up a user-dbus service bundle for each "real person" user account
that it recognizes (i.e. not user accounts with nologin or with
well-known Debian/FreeBSD/PC-BSD system account names). I fixed up the
FreeBSD side, to not attempt the malfunctioning address=systemd:, in
nosh version 1.22 in November 2015. No, I do not need a PAM module.
In terms of needs, what I actually need is for you to respect the final
paragraph of the environment section of the XDG Base Directory
Specification, if you are not respecting it already, which I hope that
you are but suspect that you might not be.
*
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
As for what I would like, I'd like you (where that's plural, including
Joe Marcus Clarke or whomever else) to please make either
address=systemd: or address=unix:runtime=yes work in your program on
FreeBSD/PC-BSD/OpenBSD. If for the former you're relying upon a library
that the systemd authors have gradually made less and less
cross-platform since the dizzy heights of "should compile fine on the
most exotic Unixes" in 2010, then 2016 might be the time to look at
Cameron T. Norman's or Pierre-Yves Ritschard's code instead. (-:
*
https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#CrippledAdoption
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
The traditional D-Bus session bus uses abstract Unix sockets on Linux,
to ensure automatic cleanup even if the dbus-daemon is terminated
uncleanly. These sockets are always shared with container-based
sandboxes, unless you start a new network namespace (which unshares
all abstract Unix sockets, and also IP networking). The user bus uses
a single filesystem-backed socket per uid, which is easy to inspect
with standard Unix tools ("everything is a file") and is more
container-friendly: it is not shared by default, but can be shared
with a simple bind mount.
It makes it more BSD-friendly, too. As I said, make address=systemd:
work, and the nosh toolset (for one) gets you the ability to outright
*not care* about what the sockets are in the D-Bus broker at all, as
it's perfectly capable of handing your program already-open file
descriptors to listening sockets and a couple of environment variables.
systemd most definitely did not invent *that* idea, after all. The
Linux service bundles (built as aforementioned by the external
configuration import subsystem) do exactly that. The
FreeBSD/PC-BSD/OpenBSD service bundles could, were it not for the fact
that your program doesn't have a way of being told to use the protocol.
In fact, they *actually do* open the socket and pass it to your program
with the environment variables. But there's no way to tell your program
that that is happening. Please make your program actually capable of
understanding address=systemd: on FreeBSD/PC-BSD/OpenBSD.
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
Some desktop environment core components, such as GNOME's
gnome-session, will automatically start a session bus per login
session using dbus-launch if there is not already one available. [...]
["X11 autolaunching"] mode is discouraged, and not particularly
reliable: it has a tendency to start the dbus-daemon in a somewhat
precarious situation, as a child of some random GUI app with arbitrary
environment variables, resource limits, std{in,out,err} fds and so on.
PCDMd, kdm, gdm, and lxdm on PC-BSD have some fairly poor behaviour in
this area, such as for each session starting up a Desktop Bus broker
running as the superuser in addition to starting one up as the logged-in
user, because every man and his dog seems to consider it xyr
responsibility to spawn off a Desktop Bus broker process. They ignore
already-provided broker addresses in several cases, and kdeinit adds
even more "fun" to the mixture. One can run PCDMd, kdm, gdm, and lxdm
under nosh service management, and it would be good for the programs in
the login session(s) to just expect "/run/user/$UID/..." sockets, as one
already obtains from running "user" Desktop Bus brokers under nosh
service management.
In https://lists.debian.org/debian-devel/2016/08/msg00554.html, Simon
McVittie:
dbus-daemon is not a fully-featured service manager:
Quite! Are you prepared, five years on, to go another round with
Lennart Poettering then? (-:
* https://jdebp.eu./Softwares/nosh/avoi
libsystemd
Russ Allbery: All other init systems except upstart [...] Psst! * https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#Choice
libsystemd
Simon McVittie: You mean like libsystemd, which looks in /run to see whether systemd is in use, talks to it if it is, and returns some suitable error code (-ENOSYS?) if it isn't? :-) Here's interesting for you. (-: Here's libsystemd and Arturo Borrero Gonzalez's code that calls it. Please point to the line that checks in /run for systemd running. * https://github.com/formorer/pkg-conntrack-tools/blob/1ed72f0e691bbd92a78a0a944a9c448260e6ff41/src/systemd.c#L30 * https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-daemon/sd-daemon.c#L404
libsystemd
The Wanderer: IMO this level of integration between things which are not mutually interdependent is a minor bug in itself, but none of the maintainers are going to agree with me on that. Actually, they might. But this is a facet of the Debian build system in general, and not specific to systemd. You'll find a lot of packages in Debian where many binary packages are built from a single source package, and you'll see this same effect for many if not most of them. It's possible to have separate binary package changelogs within a single source tree. But it's quite hard, and like other "unusual" things (such as building packages into the current directory) the Debian build system rather fights against it.
Is missing SysV-init support a bug?
Arturo Borrero González: * systemd is starting to drop support for some sysvinit mechanisms [https://sources.debian.net/src/systemd/231-4/debian/systemd.NEWS/] Don't employ such thinking. It is a mistake; in two ways no less. Close on the heels of the Debian Technical Committee's decision about systemd being the default, one Debian package maintainer thought as you are thinking. If systemd was the now the default, xe could drop the van Smoorenburg rc scripts from xyr packages. A furore resulted, the outcome of which has already been mentioned in this discussion. You also need to look at what Debian systemd is dropping support for. Is your rc script a run-level "S" script? No, it is not. What makes you think that what is being announced for systemd 231 on Debian even applies to your package? It is a mistake to make superficial and glib analyses that systemd not supporting a very specific thing is somehow systemd not supporting anything at all; especially in light of the fact that the systemd developers have had a list of "Oddball things that you can actually do with rc scripts that systemd isn't going to support." for several years, now. Ironically, not supporting run level "S" has been on that list for a long time. What's happening is actually that Debian's special exception is being taken away. * https://wiki.debian.org/Teams/pkg-systemd/rcSMigration * https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ * https://jdebp.eu./FGA/systemd-documentation-errata.html#SingleUserRunLevel
Is missing SysV-init support a bug?
Bart Schouten: Personally I do not run a non-SystemD system, [...] Then please spell the name correctly. It is no more "SystemD" than inetd is "INetD" or rsyslogd is "RSysLogD". It is "systemd". You'll be doing yourself a favour. For better or for worse, the mis-spelling has become a shibboleth by which people tend to recognize mischievous pot-stirrers at a glance.
Nutty systemd package dependencies
Simon McVittie: Once per thread about systemd, I point out that dbus-daemon links to both libapparmor and libselinux - which results in at least one useless library for literally everyone with dbus installed, since "major" LSMs don't stack, so nobody can possibly be using both AppArmor and SELinux at the same time. Oddly enough, nobody has complained about that, only about libsystemd... Which rather neatly brings us to something that I've been wondering about for some time. It's a pointless package dependency. But for novelty it's one that the people who *use* systemd might be interested in, rather than the people who *want to avoid* systemd. Consider the "initscripts" package. The "systemd" package has an explicit package dependency from it (in both Debian 8 and the prospective Debian 9). * https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/control?h=debian/215-18&id=b1e8aa81062a0fcbcc27b99144521579ab873245#n56 The file list for the "initscripts" package (taking amd64 as an example) can be divided into five rough areas: rc scripts that live in /etc/init.d/, libraries of script functions that those scripts use, default settings in /etc/default/, an fsck shim for NFS, and doco. * https://packages.debian.org/sid/amd64/initscripts/filelist What's nutty about this is that systemd actually goes to significant lengths to exclude and disable the functionality of every single thing in the "initscripts" package. All of the rc scripts are masked or superseded. The script function libraries are largely for the benefits of said rc scripts, and end up being wholly unused by systemd. (Yes, they could be used by some other package. But that would require an explicit package dependency by that package. This is about the package dependency of the "systemd" package.) systemd explicitly checks for cases where things like fsck.nfs do not exist. And as people have observed passim on Stack Exchange and Debian/Ubuntu bug trackers over the past few years, systemd has quietly obviated things like /etc/default/tmpfs (the so-called "API filesystems" such as /run and /dev/shm being mandatory with systemd, and the systemd mechanism for setting options on such mounts being /etc/fstab via systemd-remount-fs) and /etc/default/devpts (the equivalents to TTYGRP and TTYMODE being hardwired into systemd). * https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.links?h=debian/215-18&id=b1e8aa81062a0fcbcc27b99144521579ab873245 * https://github.com/systemd/systemd/blob/7163e1ca1108d789ee8b40238ebf0f6978cd58a9/src/shared/generator.c#L108 * https://freedesktop.org/software/systemd/man/systemd-remount-fs.service.html * https://github.com/systemd/systemd/blob/2056ec192742d45aa72a851dbd22ad1fe0bc91a2/src/core/mount-setup.c#L90 This does rather beg the question of why, after ensuring that *nothing* from it is used in any way, the "systemd" package yet explicitly requires the installation of the "initscripts" package.
Re: Bug#835520: Policy 9.3.1 is inaccurate to the point of being harmful
Sam Hartman: Hi. As part of reviewing an issue for the technical committee, I just read policy section 9.3 in its entirety. Section 9.3.1 really seems to be showing its age. That section covers runlevels and the sequencing numbers after S and K in rc.d links without reference to dependency-based boot ordering, init systems other than sysinit, etc. In an ideal world I'd encourage that section to be updated to talk about how boot ordering works on modern Debian. Absent that, I'd recommend significantly trimming the section to just cover the fact that there are run levels and that there are these numbers after S and K and not go into what the numbers after S and K mean. This has just come up on the Debian Developers' mailing list, where Ansgar Burchardt also thought of filing a bug. The work has actually been done, if you want it. Long since. The Debian Policy Manual never got updated in the wake of the Debian systemd Hoo-Hah. It remains written from the viewpoint that System 5 init and rc are the defaults, and that upstart is a novelty addendum. Several people in 2014 publicly proposed starting a Policy Manual revision. They never finished, to my knowledge, and their proposals remain part-done (to this day, as far as I know, although I haven't re-checked since 2015). I didn't make a public announcement, and just got on and did a rewrite. (-: It is here, complete with SGML patch: https://jdebp.eu./Proposals/DebianPolicy/
Fixing the Debian Policy Manual to finally reflect changes from 2014 (was: "Is missing SysV-init support a bug?" on debian-devel)
Robert Edmonds: The relevant text from the policy manual, §9.11: [...] The Debian Policy Manual never got updated in the wake of the Debian systemd Hoo-Hah. It remains written from the viewpoint that System 5 init and rc are the defaults, and that upstart is a novelty addendum. Several people in 2014 publicly proposed starting a Policy Manual revision. They never finished, to my knowledge, and their proposals remain part-done (to this day, as far as I know, although I haven't re-checked since 2015). I didn't make a public announcement, and just got on and did a rewrite. (-: It is here, complete with SGML patch: https://jdebp.eu./Proposals/DebianPolicy/
Fixing the Debian Policy Manual to finally reflect changes from 2014 (was: "Is missing SysV-init support a bug?" on debian-devel)
Robert Edmonds: The relevant text from the policy manual, §9.11: [...] Ansgar Burchardt: Was that changed since the default init system was changed? It pretty much still reads like Policy still assumes that sysvinit is the default init system. It also still mentions upstart in 9.11.1; will file a bug for that. If it wasn't changed, just s/sysvinit/systemd/ mentally ;) It's not the only place where Policy lags behind what is actual practice. For your bug, please note that the grunt work of fixing Debian Policy has already been done long since, and a patch exists: * https://jdebp.eu./Proposals/DebianPolicy/
Re: Removing sysV init files
Jonathan de Boyne Pollard: It didn't start because the service unit was wrong. A quick check of the log revealed that the service was trying to create a local-domain socket at |/run/lirc/lircd| . But there was no |/run/lirc/| directory on my system to contain that. Your systemd units didn't make one; and one doesn't appear by telepathy. (-: Stefan Lippers-Hollmann's System 5 rc scripts *do* make this directory, however. [...] Alec Leamas: Now, the systemd scripts are the upstream ones, and they are used in several distributions. Hence, statements like "they are wrong" in the sense that services doesn't start should be taken with some grain of salt. In this case, it seems like the nosh utility doesn't use the systemd tmfiles.d mechanisms which is the way to create temporary files and directories in the systemd world. I'd have used that if I'd found one. I looked, as that's the other way of doing this instead of the |RuntimeDirectory| setting. There's *is no* tmpfiles snippet in your source tree, that I could find. Your |/systemd/| subdirectory (at http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/) contains only unit files, notice; and there's nothing elsewhere that I could find. So yes: your service unit files are wrong, or your source tree that you give to the world is incomplete. You don't provide complete configuration for a functional system. Also note that Lennart Poettering would like you to use |RuntimeDirectory| for this in preference to tmpfiles snippets, and have your program do that in preference to either, since you are configuring it to run as the superuser. So there's an argument, at least from the systemd people, that /your daemon//program/ is incomplete. http://lists.freedesktop.org/archives/systemd-devel/2013-July/012024.html I did enjoy the Mouse Trap nature of your lircd-setup service, that I looked at when looking for where you could be hiding your creation of the |/run/lirc/| directory. Your lircd service unit pulls in another oneshot service unit that in turn invokes a Python program (http://sourceforge.net/p/lirc/git/ci/master/tree/tools/lircd-setup), which then reads a configuration file for a string, that it in turn passes to the POSIX-compatible shell for execution as an arbitrary shell command (with superuser privileges, of course). There's definitely a middle man to be cut out, there. Learn from the mistakes in the systemd House of Horror. (-: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/systemd-house-of-horror/ Alec Leamas: That said, I have sent a question to Stefan about his role here: is the maintainer? If so, what is his plans? However, I still havn't got any reply on this. You can actually look the answer to the first question up for yourself: https://packages.debian.org/source/sid/lirc That's how I knew that xe was one of the maintainers. (-:
Re: Removing sysV init files
Michael Biebl: I wonder if nosh could be an option for non-linux. According to its website it supports native systemd service files. I have to admit though, I never looked at nosh myself, so I have no idea how far that "systemd support" goes. This caught my eye, so I thought that I'd demonstrate. Before getting to what I did, let's clear up some tangential points. Alec Leamas: The systemd setup [for lirc] is three different services, the sysV [setup] one. There is no systemd service directly corresponding to the sysV one. The Debian revision log says that that's not in fact true. http://anonscm.debian.org/viewvc/pkg-lirc?view=revision&revision=521 There have been three System 5 rc scripts since May 2014; precisely so that there *is* a correspondence between service names, according to the commentary. From a Debian point of view, I suspect that the answer that you'll get from all of the Debian people who actually look into the situation is that if Debian Maintainer Stefan Lippers-Hollmann is willing to continue doing this work to maintain System 5 rc scripts for your software, you should let xem. (-: I suggest that you should probably pay more attention to the System 5 rc scripts, because your systemd units aren't up to scratch and don't do as good a job. I discovered this by running your |lircd.socket| and |lircd.service| unit files through the nosh conversion process and seeing what resulted. Your "bad gut feeling" about your System 5 rc files is, ironically, misplaced and should be about your systemd mechanisms. Yes the nosh package can take this sort of thing and convert it to native form. There's a detailed worked example of doing so on the nosh WWW pages. http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/worked-example.html For lirc it was almost as easy as: JdeBP /tmp $ fetch 'http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/lircd.socket?format=raw' -o lircd.socket JdeBP /tmp $ fetch 'http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/lircd.service?format=raw' -o lircd.service JdeBP /tmp $ convert-systemd-units ./lircd.socket JdeBP /tmp $ sudo system-control start /tmp/lircd What resulted was a service that didn't start. Hence "almost". JdeBP /tmp $ svstat /tmp/lircd /tmp/lircd: stopped since 2016-01-16 23:06:12 +; 2m 1s ago. , initially started JdeBP /tmp $ It didn't start because the service unit was wrong. A quick check of the log revealed that the service was trying to create a local-domain socket at |/run/lirc/lircd| . But there was no |/run/lirc/| directory on my system to contain that. Your systemd units didn't make one; and one doesn't appear by telepathy. (-: Stefan Lippers-Hollmann's System 5 rc scripts *do* make this directory, however. They have this near the start: [ -d "/run/lirc" ] || mkdir -p "/run/lirc" The systemd service unit file way of doing the same thing is: [Service] RuntimeDirectory=lirc So I edited that into your |lircd.service| and had another go. This time I was hit by a problem with "quirks mode" conversion (which I don't use all that often). Since your |lircd| program doesn't actually rely upon any systemd quirks as far as I can see, I simply switched to "ideal mode" conversion and converted a third time: JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket JdeBP /tmp $ sudo system-control start /tmp/lircd Now I was hit by the fact that you'd hardwired the pathname |/usr/sbin/lircd| into your service unit. This isn't wrong from a Linux systemd operating system perspective. But I'm doing this on FreeBSD (PC-BSD 10.2, in fact) to demonstrate that the nosh toolset very much does provide the tools for non-Linux operating systems. The FreeBSD-supplied lircd installs into |/usr/local/sbin |not |/usr/sbin|, because that's the rule for non-operating-system stuff. Fortunately, there are at least two ways around this. I took the one that uses |$PATH|. The conversion tool can be told |ExecStart=lircd| and that will make a service bundle that will just work for either |/usr/sbin/lircd| or |/usr/local/sbin/lircd| . So I edited that into your |lircd.service| and had another go. JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket JdeBP /tmp $ sudo system-control start /tmp/lircd And it's up and running, converted from your socket and service units into native service bundles, on nosh-managed PC-BSD 10.2. JdeBP /tmp $ svstat /tmp/lircd /tmp/lircd: running (pid 50174) since 2016-01-16 23:39:56 +; 6s ago. JdeBP /tmp $ There are several things that you probably should take note of here. The converted service bundle uses UCSPI-TCP tools from the toolset to set up the listening socket for lircd to inherit. Unfortunately, even though this is lirc version 0.9.0, built straight from the FreeBSD port today, it doesn't have the code that takes the socket as an
Re: The sixth field (fs_passno) should be zero
Dimitri John Ledkov: > Most filesystems support destructive operations, with a goal to recover data via some-sort check/repair functionality e.g. btrfs check/rescue, xfs_repair etc. > Some filesystems also require periodic maintenance calls, e.g. something like the `harmless' fsck on each mount. > Some filesystems support both destructive recovery and periodic maintainance via fsck interface. > However most filesystems in use today, have their own native tooling for destructive recovery and don't need periodic maintenance calls. If you'd described this in terms of "preen mode", I think that it would have been clearer to other people what you are getting at. Dimitri John Ledkov: > At the moment stable debian releases configure (well partman, or partman-$foo) mountpoints in /etc/fstab with passno set to 1 or 2, which means run "fsck" in a priority order. > This leads to a following chain of events on filesystems that do not require periodic maintenance and only have their own destructive recovery tooling: (... "that have no-op for preen mode and only have a full interactive, non-preen, mode of checking" ...) Dimitri John Ledkov: > - debian-install sets passno to 1|2 > - initramfs-tools includes fsck.$foo scripts > - on each boot these are called > - $foo-progs packages ship these fsck.$foo scripts > - and said fsck.$foo scripts do nothing > > This is currently the case for xfs and btrfs, which imho is silly. > > I'm proposing to do following, for filesystems that require no periodic maintainance: (... "whose fsck tools do nothing for boot-time 'preening' anyway"... ) Dimitri John Ledkov: > - d-i to set passno to 0 > - initramfs-tools to not include fsck.$foo tools for passno=0 mountpoints > - not spend time on each boot, forking shell scripts that do nothing > - $foo-progs packages to stop shipping dummy wrapper scripts fsck.$foo > - on upgrade force set passno to zero for filesystems in question > - $foo-progs packages to still ship initramfs-tools hooks that include/update initramfs with latest disaster recovery tooling (e.g. btrfs check/rescue, xfs_repair, e2fsck etc.) The main thing that this is gaining you is the second bullet point: not spending tine forking the fsck.btrfs and xfs_fsck shell scripts that print messages and exit 0. Whether that's a major objective is debateable, but on the presumption that it is you're spending a lot of effort there for something that is achieved more simply. Don't change anything with the installer or upgrade, and just replace the no-op fsck.$fstype scripts with symbolic links to /bin/true . systemd has an undocumented mechanism that checks for that, and when it is detected as the case both makes systemd-fsck do nothing and doesn't bring in the systemd-fsck@.service for the volume in the first place. * http://lists.freedesktop.org/archives/systemd-devel/2014-June/020714.html * http://lists.freedesktop.org/archives/systemd-devel/2014-June/020737.html
Re: Re: systemd, fstab, noauto and nofail
Vincent Danjean: I found another issue with systemd and noauto. > [...] > Do you think I should do a bugreport ? Not until you've constructed a far better description, because your current description is this: 1. I have several lines in /etc/fstab that all have "noauto". 2. systemd is obeying my "noauto" instruction. 3. "and, at runtime, my photos are not mounted under /media/photos or not with the options I specify (I need to check that exactly)" It should be obvious that this is going to be rejected as a systemd bug. You should (in addition to describing the computer's behaviour properly, as you note) find out what part of your system is responsible for enacting the mounts, since you explicitly instructed systemd not to be, and file the bug against that, if it is indeed a bug. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/problem-report-standard-litany.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54788d43.1080...@ntlworld.com
Re: Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]
Octavio Alvarez: Question: is it safe to say that systemd doesn't yet support the > full /etc/fstab specification from util-linux [1]? Yes; it's safe. It's also wrong. But it's quite safe. (-: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5478885f.9020...@ntlworld.com
Re: Re: systemd, fstab, noauto and nofail
Simon McVittie: If sshd uses (or can be made to use) IP_FREEBIND to remove the > potential dependency on bringing up network interfaces, then > /lib/systemd/system/ssh.service could have DefaultDependencies=no, > RequiresMountsFor=/usr /lib /etc, and drop its dependency on > network.target. Altering sshd is altering the wrong thing. This is what FreeBind=true in a socket unit and the --bind-to-any option in nosh's tcp-socket-listen program are for. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547887e9.1080...@ntlworld.com
Re: Re: init system policy
Eric Valette:
I just mentioned that naively combining User=$TOTO or ${TOTO} TOTO
> being defined in an default/package file parsed by EnvironmentFile=
> does not seem to work as documented in man pages (seen the very same
> question being asked on various distro mailing list without
> definitive answer).
It's working exactly as documented. The man pages don't say that any
such feature is available; and it isn't. (-:
Eric Valette:
systemd for servers systems may still have some way to go
> for converting complex init scripts for firewall,openssh,VM's IMHO.
On the contrary, SSH service is one of the things that it is easy to set
up service and socket units for, with two different choices of
organization dependent from what program has the responsibility for
doing the accept()s. init.d scripts for this aren't exactly terribly
complex to start with, in the general spectrum of complexity across the
board. In FreeBSD, for example, the rc.d script is yet another ordinary
command="/usr/sbin/${name}" script:
https://gitorious.org/freebsd/freebsd/source/f1d6f4778d2044502209708bc167c05f9aa48615:etc/rc.d/sshd
. It has some non-trivial precmd tasks, but that's nowhere near as
complex as some scripts.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546f50ad.3040...@ntlworld.com
Re: Re: Re: init system policy
Eric Valette: There has been a good and valuable effort trying to split original > upstream packages provided init system scripts by debian developers > into /etc/default/X and /etc/init.d/X file and storing most commonly > changed sysv init options in the default file part (including start > or not). Wasting this work due to systemd transition would be a bad > idea IMHO. It's actually thinking that /etc/default is the right place for service enable/disable information that has traditionally been seen as the bad idea. See Debian bug #522163 for starters. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546f4baa.4070...@ntlworld.com
Re: Re: init system policy
Russ Allbery: Yeah, this seems like the right solution to me too. Drop a > configuration fragment in /etc/systemd that overrides the user and > group and then don't touch it again. I refer you to footnote #85 in that patched document that I just sent to you. (-: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546f49f5.3030...@ntlworld.com
Re: Re: init system policy
Vincent Bernat: There is chpst for this kind of task. Unfortunately, being part of > runit, it may not be suitable for a dependency. * http://superuser.com/a/72 Actually, there are chpst, s6-setuidgid, daemontools-encore setuidgid, daemontools setuidgid, freedt setuidgid, nosh setuidgid, and runuid for this kind of task. (-: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546f46f3.2020...@ntlworld.com
Re: New dash in experimental showing up a widespread bashism in configure scripts
Gerrit Pape: Hi, I'd very appreciate help on tracking down the failures and do > the appropriate analysis, reportbug, patch drafting, and the like, as > my time for this is quite limited. I took a handful of packages as a sample, and the problem could be traced to the same bug, over and over, in almost all cases. Here's the first error building fizmo_0.7.9-1 from your logs: ./configure: 2340: test: xyes: unexpected operator This is a "test" command in the configure script that is using the Bashism "==" instead of the standard "=" for string comparison. You can see from the log that it occurs in several places in that script, including where it's looking for x/usr/include at one point. In several of the packages that I looked at, this was the root of the problem, and the later more obvious symptoms were simply the result of configure picking the wrong options because its test expressions were broken. Some bloke named Lucas Nussbaum once noticed this: * https://mail.gnome.org/archives/commits-list/2011-April/msg09472.html But he wasn't the first by a long chalk: * http://lists.freebsd.org/pipermail/freebsd-questions/2009-September/204775.html I suspect that the checkbashisms crew still have a lot of small configure.ac patches to send to people. (-: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545e0544.4060...@ntlworld.com
Re: Re: Bug#741930: reportbug: add current init system information
Sandro Tosi: what is the recommended way to identify sysvinit? from the info > provided above one requires to check a dir existence and the > checking a command and then execute it to parse its output. it seems > a bit fragile, and maybe only upstart check really the running > processes There isn't really a reliable way to identify any of these as the current running system, and upstart is not checking the running processes either. * To check for systemd as the running system manager in the "official" manner, one checks for the existence of /run/systemd/system . This is a directory, in /run, that systemd itself creates at boot, and that other system managers are unlikely to create. The downside is that this check will be fooled if ever someone comes along and implements a system that creates these directories for compatibility with things that create systemd service units in /run. I suspect that that already is the case for "uselessd" and this test is already broken. * To check for upstart as the running system manager, one checks that there's an initctl command and that the output of "initctl version" contains the name "upstart" somewhere. There do exist other initctl commands, aside from the one that comes with Upstart. But they don't emit the word "upstart". root ~ #initctl version nosh version 1.10 root ~ # Again, the downside is that this is not checking what's running. In particular, it fails when one has installed Upstart but not yet rebooted in order to run it. * To check for the nosh system-manager, one can do the same "initctl version" test as with upstart, and look for "nosh". Or one can look for the /run/system-manager directory. Both share the weaknesses of the equivalent upstart and systemd checks. initctl isn't present as a command unless one has installed the nosh upstart compatibility shims package, and there's no guarantee that another initctl won't emit that string any more that there's a guarantee that a non-upstart initctl won't emit the string "upstart". And, although there's vanishingly small reason to do so, it is possible that something else might create a lookalike /run/system-manager directory. "system-control version" is the identical command to "initctl version", however, and that is part of the system management package and not a shim. But on the gripping hand this is still a test of the software that is installed and ready to run, not of what is currently running. * Ironically, and as people are belatedly discovering, one test for System 5 init installed, that is peculiar to Debian, is that no other system manager expects the existence of, and no other system management toolset Debian package has, the file /etc/inittab . Again, this is not a test for System 5 init running. To check for what system manager is running right now, as opposed to what is installed and ready to run, one really has to look at the process list or at the various APIs that system managers publish. But this isn't wholly without pitfalls. * You've already mentioned the problems with /proc/1/exe . * systemd publishes a whole RPC API over D-Bus, which even contains a version name and number; but (a) this isn't covered by the infamous "Interface Stability Guarantee" and could change tomorrow or at whim, and (b) so too does the lookalike D-Bus server in systemd-shim. * The existence of /run/systemd/private is similarly not guaranteed. * The nosh system-manager doesn't create pipes or sockets in the filesystem, and doesn't have an RPC API in the first place. * The nosh service-manager conventionally has an API socket at /run/service-manager/control, but one can run the nosh service manager under some other system manager; so this doesn't tell one what system manager is running as process #1. In any case, it doesn't set that name itself; whatever invoked it does. * The existence of the control API file /dev/initctl isn't specific to System 5 init. systemd has a (non process #1) systemd-initctl server that serves this. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545ded52.3040...@ntlworld.com
Re: Re: Arch-dependent files in /usr/share
Russ Allbery: I think it's worth considering whether we should just dump the > Lintian checks for arch-independent files in /usr/lib, and make a > corresponding change to Policy that says that packages are free to > put arch-independent files there. It would as a side-effect make you better aligned with the systemd Filesystem Hierarchy Standard. (-: * http://freedesktop.org./software/systemd/man/file-hierarchy.html "Static, private vendor data that is compatible with all architectures (though not necessarily architecture-independent)." -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545811c4.2020...@ntlworld.com
Re: init system daemon readiness protocol
Vincent Bernat: > All of them are relying on the fact that the monitored process won't fork. > They are therefore not able to handle readiness and dependencies. Also untrue. Handling dependencies has nothing to do with forking, and it's an error to think that anyone handles readiness. Readiness is not something that any service manager does reliably. There's just not the consistent mechanism for it, yet. The RabbitMQ server on one of my machines, to pick one example, can take bloody ages to start up when it so happens that it has a lot of persistent messages to scan back in from disc. And it doesn't even bind its listening sockets, let alone communicate, until it's done. The end result is that no AMQP client program can connect, and just (say) stall waiting for the login response. No service manager fixes this. RabbitMQ server doesn't fork and exit, and it doesn't yet speak any notification protocol. The service managers think that it's up and ready, so they go ahead and start all of the AMQP client services, that are all quite properly marked as depending from it and that are all quite properly not started until after the server is. The clients then repeatedly fail to connect(). (This is not the only problem with RabbitMQ and service managers. There are at least two startup races with the erlang runtime and the erlang port mapper that I know of. It would be nice if, for starters, the server could at least be passed a listening socket file descriptor. Yes, there's "rabbitmqctl". But that's the point, of course. Major softwares still work on the "Use only our package-specific XYZctl massive russian-doll-like scripts for service management." basis.) Russ Allbery, Ian Jackson, and others all discussed this, and made these same points, back in December 2013 and January 2014. I highly recommend reading the debian-ctte mailing list discussion. You'll see discussion of the lack of standardization of readiness protocols, the absence of any widely adopted readiness protocol, and (yes) both M. Jackson and M. Allbery in favour of discouraging the idea of forking in order to "daemonize" something that is already a daemon. (As M. Allbery knows, I've been encouraging people not to uselessly fork for ... ahem! ... some years. I recently revisited my FGA with an observation from my on-going project to make 155 nosh service bundles for the BSDs. A lot of BSD programs, in recent years, have quietly gained "don't fork" command line options of one sort or another.) On the subject of readiness protocols: To see another already-established mechanism, perhaps avoid reinventing the wheel, and once again see the error of thinking that all this was only just thought of and entirely missing a whole history of tools development, see Laurent Bercot's fifodir mechanism (http://skarnet.org/software/s6/fifodir.html). On the subject of forks: It's interesting to observe that an EVFILT_PROC kevent() with NOTE_TRACK works reliably on FreeBSD/PC-BSD for tracking across forking daemons. This is not to say that forking is suddenly alright. But it gives the lie to any claim that daemontools-family service managers lose track when daemons fork. The nosh service-manager is quite happy with the old you-have-to-turn-an-undocumented-debug-option-on-to-stop-it forking Vixie cron on FreeBSD, for example, and is perfectly aware of and tracking the forked child process after the parent exits. You'll notice that I didn't put a "fghack" in nosh. It's not needed on FreeBSD, and should be equally well unneeded on Debian kFreeBSD. I must remember to give M. Bercot, M. Pape, M. Guenter, and M. Sampson some good news. And as I said, dependencies have nothing to do with forking. Dependencies are a matter of having some way of specifying dependencies in service configurations, and topologically sorting the low-level start/stop tasks. Felix von Leitner's minit was doing dependencies back in 2000. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544acce6.1070...@ntlworld.com
Re: design of process #1 programs
The Wanderer: That isn't all you gain by it; you also gain the benefit of being > able to use these features no matter which init system you're > running. Which in turn helps avoid lock-in, and enable easier testing > of (or migration to) alternatives, and prevent user surprise, and so > forth. Gunnar Wolf: Yes. But it would end up finally boiling up to having your favorite > init spawning nothing but this newfangled ultra-process-supervisor, > which would then start monitoring everything. That is, you'd have > whateverinit spawn a PID 2 process, which would... Perform precisely > systemd's tasks. Not in fact correct. Apart from the fact that things that already existed 15 years ago (namely the process supervisors that are being discussed) are not really "newfangled" or in any way hypothetical, there are things that process #1 must do throughout the life of the system, and they do not move into a child process even if daemon/service supervision is not done in process #1. It's often said that process #1 is the reaper of parentless terminated processes. In fact, thanks to things that really are "newfangled", that's not really a major specific process #1 task any more. Ironically, it's one of the things that can move out of process #1, contrary to received wisdom. systemd and upstart make use of the Linux kernel's "new" (just under 3 years old) ability to set "subreapers". One only sees the effects of this with "user" service managers, because the "system" ones are still process #1. The effects are that a process other than process #1 can now have the task of reaping parentless terminated processes in its part of the process subtree. What does remain in process #1, in contrast, is system management and basic initialization of "API" devices, directories, and symbolic links. The "API" stuff is reasonably well known. Even BSD init mounts things in process #1. The system management should be, too. There's a whole load of signals that other programs expect to be able to send off to process #1 to initiate various system state changes. The kernel sends several signals to process #1, too, including SIGINT and SINWINCH. None of this stuff can move out of process #1. In a further irony, systemd has already moved one thing out of process #1 that is done in process #1 by System 5 init: the initctl socket. This is managed completely outwith process #1 by a compatibility shim in systemd. Of course, systemd replaces it with a internal, not guaranteed, D-Bus transported "systemd process" API; which is part of the hoo-hah around systemd-shim. But asking whether that would be done outwith process #1 is making the mistake of thinking that it's the right API to be implementing in such a system in the first place; and the API that is the right one to implement isn't provided by process #1 in the systemd package anyway. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/debian-systemd-packaging-hoo-hah.html#systemd-shim -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544a9c31.9010...@ntlworld.com
Re: design of process #1 programs
The Wanderer: At a glance at the sysvinit source, it doesn't look to me like /sbin/init itself does service management, in the "starting, stopping and monitoring services" form; at most, it seems to handle some subset of the "monitoring" part, in the form of noticing when something has died abnormally. (Which goes well beyond just services, when necessary.) I see that Russ Allbery has already addressed the error here. The Wanderer: If that's correct, and if the systemd PID 1 binary handles service management, then that's something it's doing which the init daemon itself has not traditionally done. Which doesn't automatically mean that it shouldn't, but which does seem to eliminate the argument that it "only does what [the init daemon is] supposed to do". Notions of what process #1 is "supposed" to do are by their natures subjective. A meaningful objective design criterion is what process #1 at minimum _must_ do. The kernel imposes several requirements on it. And there are always some operating-system-specific things of various kinds that it has to do. When it comes to what process #1 has _traditionally_ done, then we are not at that minimum and never really have been. Sadly, tradition usually isn't what people say it to be, moreover. Too many people (a) think that the world begins and ends with Linux, (b) have little knowledge of history, or (c) get rc and init mixed up. For example: System 5 init and System 5 rc date to System 5, which was almost as far after the first UNIX as we are now (say) after the first version of Linux-Mandrake. 1st Edition UNIX only had init. It did not have rc. The 1st Edition assembly language init spawned and respawned 12 getty processes, mounted 3 hardwired filesystems, and directly ran a program from the home directory of a user named "mel". The getty table was directly in the program image. The Wanderer: Looking at the sysvinit source for this, and thinking about the differences in relation to systemd, has led me to come up with some ideas in regard to possible init-system-et-al. design which I think may be interesting enough to be worth pursuing or at least discussing. Really, if that's all that you've read, you have a lot more to read. System V init/rc and systemd don't even cover half of what there is to know. There's been a lot of work in the area of init system design (for Linux and the BSDs) that has happened in the past two decades alone. All sorts of engineering decisions have been discussed, made, designed, and implemented. These include: a more human-readable configuration file for init (http://troglobit.com/finit.html); filesystem-is-the-database configuration, small memory footprints, and start/stop dependencies (http://www.fefe.de/minit/); dependencies, named targets, multiple configuration files, and a more flexible configuration syntax with a whole load more settings for child processes (http://initng.org/); pushing all of the service management out including even the getty spawning and zombie reaping, and just handling operating-system-specific "API" devices/symlinks/directories and system events (http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html); and the just spawn four shell scripts approach (http://smarden.org/runit/). About 10 years ago, there was discussion amongst daemontools users and others of using "svscan" as process #1, which led to projects like Paul Jarc's http://code.dogmap.org/svscan-1/ , Gerrit Pape's http://smarden.org/pape/djb/daemontools/noinit.html , and Laurent Bercot's http://skarnet.org/software/s6/s6-svscan-1.html . And that's just the process #1 parts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544a8cdd.9070...@ntlworld.com
Re: Re: piece of mind
The Wanderer: This is the problem. The init system should not be providing > "features" which other software might, post-boot and pre-shutdown, > want to make use of. (AFAIK sysvinit never did, and most - possibly > all? - of the other init-system candidates don't either.) Such > features should be provided separately, independent of what may > happen to be running as PID 1. Matthias Urlichs: Please explain why it should *not* provide these "features". Why > should every daemon (or its startup script) re-implement the same > code to put itself in the background, change UIDs, resource-limit > and security-enhance (private /tmp) itself, when the same thing can > be implemented once, so that I as a sysadmin (or my puppet script) > don't have to learn ten separate ways of configuring that? M. Wanderer was talking about process #1 in his message, M. Urlichs, which xe made synonymous with "the init system". Your changing that to be the systemd package, in order to then knock that argument down, is a strawman. You know, or at least should know, as well as I that one can centralize the code to do all of those things, and abstract them out of daemons into a service manager, without that service manager being process #1. daemontools actually began (version 0.51 dates from July 1997) as exactly a toolset to do this, with things like "svscan" and "svscanboot" coming a couple of years later. In the intervening years we have seen daemontools-encore, freedt, s6, perp, runit, and nosh; all of which can do this. Several of them even come documented with instructions on how to run them under various process #1 programs. daemontools, dating from when it did, had instructions for running under System V init and BSD init. So does perp. runit has a whole load of instructions at http://smarden.org/runit/useinit.html . s6 has a whole load of instructions at http://skarnet.org/software/s6/s6-svscan-not-1.html . The dichotomy that you present as your challenge, that the choice is between having process #1 do all of this or having each individual daemon program do all of this, is a fallacious one, disproven by the existence of toolsets that allow for avoiding both, for some 17 years now. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544a6df0.1050...@ntlworld.com
Re: remedying deficiencies in system 5 init
Ansgar Burchardt: Isn't that just a hack to work around deficits in sysvinit? Matthias Urlichs: The whole of sys5rc can be described as a hack to work around the > fact that sys5init does not have a whole lot of features … if > somebody had evolved it with an inittab.d directory and a more > flexible file format, we might now have something that resembles > systemd's PID1. No. You wouldn't have ended up with systemd, or even something necessarily resembling it. You would have ended up with what you HAVE ended up with, which is a lot of designs and implementations, based upon a lot of differing engineering choices, some of which bear almost no resemblance to systemd (simpleinit, jinit, minit, cinit, finit, initng, runit's runit and runsvdir, nosh's system-manager and service-manager, ...). The idea of doing better than System V init and System V rc didn't suddenly appear in the late 2000s, after all. (-: -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544a2fa1.4090...@ntlworld.com
Re: Re: apt-get install sysvinit-core removes gnome?
Dominik George: There is no GNOME without systemd. This is not specific to Debian. Florian Lohoff: Because i - aehm - cant set an icon for my system via hostnamed or something? As you've spotted, what M. George wrote is ambiguous and unspecific and liable to be further distorted. This may help: * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/debian-systemd-packaging-hoo-hah.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5441b377.2060...@ntlworld.com
