Re: [systemd-devel] Removing unnecessary includes
On Sun, Feb 15, 2015 at 11:53 PM, Thomas H.P. Andersen pho...@gmail.com wrote: On Tue, Feb 10, 2015 at 10:05 PM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 07.02.15 10:29, Thomas H.P. Andersen (pho...@gmail.com) wrote: Hi, I am looking at ways to automatically trim the unnecessary includes. One way to do it is a script[1] which simply tests if the compile still works after removing each include one at a time. It does this in reverse order for all includes in the .c files. Using -Werror we catch any new warnings too. I think this is quite useful, but I'd also be really careful with this. glibc versions sometimes require different headers to be included to get some functionality, thus automatic removal of headers that are unnecessary on one system doesn't mean this is universally the case... Moreover depdending on compile-time options you might different headers... I have used IWYU to only drop headers that we do not use any symbols from. There are no automatically added headers nor includes replaced by forward declarations.I have manually checked all removals from files that contain a #ifdef or #if defined() to catch issues from various compile-time option combinations. No includes of missing.h were removed and I tried to be careful with endianness. Are there specific headers I should be extra careful with or ignore completely? For info I am attaching a diff with the changes so far: 1309 includes removed out of the current 7707. It is only compile and make check-tested. I am only looking for comments (and perhaps compile testing on an AppArmor system as I do not have a system with that). The patch bitrots quickly. I have updated it and also dropped a few removals of architecture.h and endian.h. It passes make check and I have not seen any issues with using it on my own system. Still not tested with AppArmor though. I moved the patch to github: https://github.com/phomes/systemd-1/commit/cf3c313747ebae18b63effb251f801ac4c370f05 Here is a list the headers removed and number of times removed: 74 sys/types.h 69 unistd.h 65 string.h 63 assert.h 53 util.h 45 fcntl.h 42 stdlib.h 38 inttypes.h 29 errno.h 28 sys/stat.h 21 strv.h 19 label.h 17 sys/socket.h 16 path-util.h 16 fileio.h 16 def.h 15 stdio.h 15 dirent.h 15 arpa/inet.h 14 unit.h 14 mkdir.h 14 log.h 14 ctype.h 13 sys/un.h 13 dbus-unit.h 12 stdarg.h 12 set.h 12 poll.h 12 netinet/ether.h 11 limits.h 11 bus-message.h 10 stdbool.h 10 signal.h 9 time.h 9 sys/wait.h 9 socket-util.h 9 sd-bus.h 9 pwd.h 9 network-internal.h 9 list.h 8 sys/ioctl.h 8 sd-id128.h 8 net/if.h 8 load-fragment.h 8 getopt.h 7 sys/param.h 7 macro.h 7 hashmap.h 7 event-util.h 7 bus-error.h 6 utf8.h 6 sys/time.h 6 sys/prctl.h 6 grp.h 6 conf-parser.h 6 capability.h 6 bus-util.h 6 build.h 5 udev-util.h 5 sys/timex.h 5 sys/timerfd.h 5 sys/syscall.h 5 sys/epoll.h 5 load-dropin.h 4 virt.h 4 termios.h 4 sys/signalfd.h 4 sys/mount.h 4 stddef.h 4 sd-messages.h 4 resolved-manager.h 4 netinet/in.h 4 manager.h 4 logind-seat.h 4 linux/vt.h 4 libudev.h 4 exit-status.h 4 execute.h 4 conf-files.h 4 cgroup-util.h 4 byteswap.h 4 bus-control.h 4 bus-common-errors.h 4 audit.h 3 time-util.h 3 sys/utsname.h 3 sys/resource.h 3 stdint.h 3 special.h 3 smack-util.h 3 resolved-dns-scope.h 3 net/ethernet.h 3 logind-session.h 3 logind.h 3 libudev.h 3 in-addr-util.h 3 endian.h 2 wchar.h 2 unit-name.h 2 sys/xattr.h 2 systemd/sd-login.h 2 systemd/sd-journal.h 2 sys/statvfs.h 2 sys/mman.h 2 synthesize.h 2 siphash24.h 2 sd-rtnl.h 2 sd-event.h 2 sd-dhcp-client.h 2 sd-bus-protocol.h 2 rtnl-util.h 2 rtnl-internal.h 2 resolved-dns-stream.h 2 resolved-dns-server.h 2 resolved-dns-rr.h 2 network-util.h 2 netinet/if_ether.h 2 mount-setup.h 2 mount.h 2 logind-device.h 2 linux/types.h 2 linux/limits.h 2 linux/ioctl.h 2 linux/fs.h 2 libudev-private.h 2 journal-authenticate.h 2 install.h 2 fsprg.h 2 fnmatch.h 2 failure-action.h 2 driver.h 2 dhcp-lease-internal.h 2 dbus-kill.h 2 clock-util.h 2 cgroup.h 2 bus-label.h 2 asm/types.h 2 arpa/nameser.h 1 xml.h 1 xkbcommon/xkbcommon.h 1 unaligned.h 1 target.h 1 sys/vfs.h 1 sys/uio.h 1 sys/swap.h 1 sys/select.h 1 sys/inotify.h 1 sys/file.h 1 sys/eventfd.h 1 strxcpyx.h 1 specifier.h 1 service.h 1 sd-lldp.h 1 sd-dhcp-lease.h 1 sd-daemon.h 1 resolved-dns-transaction.h 1 resolved-dns-query.h 1 resolved-dns-domain.h 1 pthread.h 1 path-lookup.h 1 networkd-netdev.h 1 networkd-link.h 1 mntent.h 1 machine.h 1 logind-user.h 1 logind-session-device.h 1 logind-inhibit.h 1 locale.h 1 linux/veth.h 1 linux/sched.h 1 linux/ppp_defs.h 1 linux/oom.h 1 linux/netlink.h 1 linux/input.h 1 linux/in6.h 1 linux/if_link.h 1 linux/if.h 1 linux/if_ether.h
Re: [systemd-devel] pam_limits: Could not set limit for ...: Operation not permitted
Kai Krakow hurikha...@gmail.com schrieb: But now I got a new message in the log: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 Hmm, maybe Gentoo ships some dbus hookup for systemd user sessions that triggers this? It's triggered by gnome-keyring-daemon... I already set DISPLAY=:0 in user.conf just to try. This allows me to systemctl --user start obex.service so the change was applied but didn't fix the messages. Essentially, the messages may have been there before and I just didn't discover them until now. So I reverted my change and wait for the following: Simon is working on getting this cleaned up in dbus-daemon upstream, see the other threads about that. Yeah I already discovered that and thus currently won't work that out further in this thread. I'll follow the discussion and jump in when I feel I'd like to. BTW: This error message is gone since 219. I guess this is because this version of systemd now exports some extra variables. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] heads-up: chasing journal(?) related regression in 219 causing boot hang/fail
Lennart Poettering [2015-02-20 17:02 +0100]: To me this appears as if dbus is hanging for some reason. Have you checked what dbus is doing? D-Bus itself seems to be fine. There are services on it, busctl works, etc. Anyway, I now have a capable enough arsenal to reproduce that hang fully automatically and a git bisect run script, which after a few hours of grinding spat out that this is the culprit: http://cgit.freedesktop.org/systemd/systemd/commit/?id=13790add4bf64 (journald: allow restarting journald without losing stream connections) and indeed reverting that on top of current git master (reverts cleanly) makes things work perfectly again. I haven't drilled down into the patch itself yet, that's not something I want to start doing on a Sunday :-) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A use case for staged startup
On Sun, Feb 22, 2015 at 6:04 PM, Andrei Borzenkov arvidj...@gmail.com wrote: Do you really need to fully overlay root? I.e. is it possible to just (bind-)mount /etc, /var? /usr should be possible to retain read-only. Once the upper layer of the overlayfs is JFFS2 (as intended), then it's more interesting to have all of / overlayed. - and dutifully starts them all again once we're headed towards multi-user.target That's a *lot* of noise in the startup process! But does it actually work? Yes, it does! It's so awesome that all of this machinery is built in, and doesn't require reams of shell scripts. So, it totally works, it just has performance warts because of my weird use case. :-) I believe that if you just overlay /etc with probably new default.target and run daemon-reload followed by isolate it /should/ detect that some services are missing from new default.target and continue. systemd can do all of that for me. The problem right now is that during the initrd stage, it has access to *all* of the system services, so dutifully starts them all up. Then isolates (kills them), switches root, and starts them all up again. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Removing image from /var/lib/machines
Does it make sense to avoid copying /etc/resolv.conf to a container if the filesystem is read-only? sudo /usr/bin/systemd-nspawn --read-only -M docker-centos-nginx --read-only /usr/sbin/nginx Failed to copy /etc/resolv.conf to /var/lib/machines/docker-centos-nginx/etc/resolv.conf: Read-only file system ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A use case for staged startup
Hi, Jeff Waugh: - systemd dutifully starts all the services it knows about during the initrd.target run, because they're all right there on the read-only filesystem … and because, I assume, they're implied by default.target. So why don't you start the system with some different target that does just enough to switch roots and then calls systemctl start default.target? -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Tue, Feb 17, 2015 at 9:35 PM, Michael Biebl mbi...@gmail.com wrote: There is no such dependency in Debian either [1]. Luke simply has no idea what he is talking about. It would be great if Luke did some basic research and educate himself and not spread such misinformation. michael, greg's approach is something that i'm going to ask you to learn from: it was exemplary. he trusted that i had done the research, questioned how i had arrived at the conclusion that i had, indicated implicitly that he wanted to verify the research himself, and presented me with an opportunity to provide him with the method by which he could do that, when i had *deliberately* chosen, as a way to reduce the length of an already-long post, to not pollute it with unnecessary commands. commands which, conceivably, could be interpreted as trying to teach highly experienced programmers how to suck eggs, and given the level of competence of the people on this list i decided it would be a good idea to trust in people's expertise implicitly. in complete contrast, what you are saying - some of this is actually explicit rather than implicit - is that i cannot be trusted, i am incapable of doing basic research, i am illiterate, undereducated, incompetent, deluded, unable to assess my own mental state and degree of expertise, unable to learn, and, perhaps worst of all, willing to waste other people's time by even talking to them. would that be an accurate assessment of what you wished to convey? if that is the case, i have to ask: what on earth are your motives for making such views so plainly clear on this list? what do you hope to achieve by saying what you did, in the way that you said it? can i leave you to think about that? l. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] po: update French translation
Le 19 février 2015 23:31, Sylvain Plantefève sylvain.plantef...@gmail.com a écrit : --- po/fr.po | 76 +--- 1 file changed, 68 insertions(+), 8 deletions(-) diff --git a/po/fr.po b/po/fr.po index 8e44e0c..58a0b85 100644 --- a/po/fr.po +++ b/po/fr.po @@ -7,7 +7,7 @@ msgid msgstr Project-Id-Version: systemd\n Report-Msgid-Bugs-To: \n -POT-Creation-Date: 2015-01-22 16:03+0100\n +POT-Creation-Date: 2015-02-18 19:48+0100\n PO-Revision-Date: 2014-12-28 13:04+0100\n Last-Translator: Sylvain Plantefève sylvain.plantef...@gmail.com\n Language-Team: French\n @@ -27,11 +27,11 @@ msgid msgstr Authentification requise pour renvoyer la phrase secrète au système. #: ../src/core/org.freedesktop.systemd1.policy.in.in.h:3 -msgid Manage system services or units +msgid Manage system services or other units msgstr Gérer les services système ou les unités #: ../src/core/org.freedesktop.systemd1.policy.in.in.h:4 -msgid Authentication is required to manage system services or units. +msgid Authentication is required to manage system services or other units. msgstr Authentification requise pour gérer les services système ou les unités. @@ -46,10 +46,24 @@ msgstr unités. #: ../src/core/org.freedesktop.systemd1.policy.in.in.h:7 +msgid Set or unset system and service manager environment variables +msgstr +Définir ou supprimer des variables d'environnement du système ou du +gestionnaire de services + +#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:8 +msgid +Authentication is required to set or unset system and service manager +environment variables. +msgstr +Authentification requise pour définir ou supprimer des variables +d'environnement du système ou du gestionnaire de services. + +#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:9 msgid Reload the systemd state msgstr Recharger l'état de systemd -#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:8 +#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:10 msgid Authentication is required to reload the systemd state. msgstr Authentification requise pour recharger l'état de systemd @@ -89,8 +103,8 @@ msgstr Télécharger une image de machine virtuelle (VM) ou de conteneur #: ../src/import/org.freedesktop.import1.policy.in.h:2 msgid Authentication is required to download a VM or container image msgstr -Authentification requise pour télécharger une image de -machine virtuelle (VM) ou de conteneur. +Authentification requise pour télécharger une image de machine virtuelle +(VM) ou de conteneur. #: ../src/locale/org.freedesktop.locale1.policy.in.h:1 msgid Set system locale @@ -383,15 +397,59 @@ msgstr Authentification requise pour mettre le système en hibernation alors qu'une application a demandé de l'empêcher. +#: ../src/login/org.freedesktop.login1.policy.in.h:49 +msgid Manager active sessions, users and seats +msgstr Gérer les sessions actives, les utilisateurs et les postes (seats) + +#: ../src/login/org.freedesktop.login1.policy.in.h:50 +msgid +Authentication is required for managing active sessions, users and seats. +msgstr +Authentification requise pour gérer les sessions actives, les utilisateurs +et les postes (seats). + +#: ../src/login/org.freedesktop.login1.policy.in.h:51 +msgid Lock or unlock active sessions +msgstr Verrouiller ou déverrouiller des sessions actives + +#: ../src/login/org.freedesktop.login1.policy.in.h:52 +msgid Authentication is required for locking or unlocking active sessions. +msgstr +Authentification requise pour verrouiller ou déverrouiller des sessions +actives. + #: ../src/machine/org.freedesktop.machine1.policy.in.h:1 msgid Log into a local container msgstr Connexion dans un conteneur local #: ../src/machine/org.freedesktop.machine1.policy.in.h:2 -msgid Authentication is required to log into a local container +msgid Authentication is required to log into a local container. msgstr Authentification requise pour permettre la connexion dans un conteneur local. +#: ../src/machine/org.freedesktop.machine1.policy.in.h:3 +msgid Manage local virtual machines and containers +msgstr Gérer les machines virtuelles (VM) et conteneurs locaux + +#: ../src/machine/org.freedesktop.machine1.policy.in.h:4 +msgid +Authentication is required to manage local virtual machines and containers. +msgstr +Authentification requise pour gérer les machines virtuelles (VM) et les +conteneurs locaux. + +#: ../src/machine/org.freedesktop.machine1.policy.in.h:5 +msgid Manage local virtual machine and container images +msgstr Gérer les images locales de machines virtuelles (VM) et de conteneurs + +#: ../src/machine/org.freedesktop.machine1.policy.in.h:6 +msgid +Authentication is required to manage local virtual machine and container +images. +msgstr +Authentification requise pour gérer les images locales de machines
Re: [systemd-devel] feature request: dlopen
On Tue, Feb 17, 2015 at 9:25 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Feb 17, 2015 at 08:24:37PM +, Luke Kenneth Casson Leighton wrote: so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt it's an enormous list, comprising some 15% of the packages present in debian today. it includes apache2-dev, bluetooth / bluez, the gimp, php, *all* of the video players (xine, mplayer, vlc), *all* of the games and 3D packages that use SDL or pulseaudio (which is most of them), *all* of the major desktop environments including xfce4, lxde, Gnome and KDE/Plasma, cups-daemon, one of the anti-virus daemons, most of the music software packages and services, most of the VoIP clients, the android SDK, the eclipse IDE, OpenJDK 7, erlang, Apache Tomcat. i'm just absolutely blown away by the extent of the dependencies. How exactly did you create such a dependancy list? apt-rdepends -r libsystemd0 | a bit of awk-style manual magic | sort | uniq someone else did a visual-style version of the same thing... i forget exactly where i saw it - they removed thousands of packages, limiting it to only about 400, otherwise it would be far too big. Perhaps you might wish to just file a Debian bug so that they fix their build systems? Arch Linux doesn't have this kind of requirement, so something must be odd here... https://wiki.archlinux.org/index.php/systemd they moved to systemd, wholesale. converting to systemd has become a very rapid, widespread and wholesale decision that has completely locked out sysvinit, openrc, *everything*. the reason why is because there's no precedent for using dlopen, it's all compile-time hard dependencies in cups, libpulseaudio, libsdl and a hundred other immediate dependencies that you can check with apt-cache rdepends libsystemd0. the only major (i say major, they're pretty low down on the list these days) GNU/Linux distro left which anyone has heard of not using systemd is slackware. and that's most likely - this is speculation btw - because the basis of slackware is minimal maintainer work. as systemd hasn't stabilised, they are probably leaving it. gentoo are the only team working to provide alternative infrastructure. *all* other major GNU/Linux distros have converted to systemd and completely abandoned all other options. debian does provide systemd-shim, but because of the immediate hard-compile-time dependencies, you are still left with libsystemd0. Also, this is a distro choice to make, the Debian developers seem pretty happy with systemd and how it is being loaded in their systems, so perhaps you might wish to ask them about this hard-requirement. Other distros do not have such a hard-requirement at this time, yeah, they do. perhaps you might wish to try one of them if you do not want to use systemd? i manage a dozen systems for clients, many of them remotely, with absolutely no console access except a computer-illiterate individual at the keyboard. i just tried upgrading a system tonight, adding in the angband.pl nosystemd repository and upgrading it to jessie. it completely failed to come back on the VPN network, and because it is remote i have absolutely no idea why. this is *real* bad stuff, greg. i now have to spend hours, tomorrow, walking my computer-illiterate friend through the process of recovering his computer. i cannot possibly take the risk of doing such risky upgrades on systems where my clients are paying money. i cannot possibly even _remotely_ contemplate doing a *remote* conversion of a debian system on which i have five lxc virtual machines for clients. it would be completely insane to do so, as i would not only need to convert the base machine but also the five client machines all at the same time. if the base host machine fails to come up, it costs me a fortune in KVM access time at the hosting company. during the time in which that base machine fails to come up, i have 5 clients all screaming at me why is my machine not up? then when it is finally up i would have to convert them all over to the replacement OS as well. that's _days_ of work, greg, none of which may be done in a transitional manner (i moved away from xen two years ago because after four years of operation it was proving to be too unstable long-term) and i am just one systems administrator. there will be others just like me - world-wide - who aren't brave enough to speak to you guys directly, who will be going oh crap... and who recognise that they are being press-ganged into a major decision with absolutely no choice in the matter. even if i was to accept the downtime on my business, unlike many others in this situation i can't even convert my laptop to FreeBSD because it has hardware that is too modern and
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
Andrei Borzenkov arvidj...@gmail.com writes: В Fri, 20 Feb 2015 10:56:42 +0100 Jan Synacek jsyna...@redhat.com пишет: To be more consistent with how dracut parses rd.luks.key, it is now allowed to specified it in the format keyfile[:keyfile_device]. Should keyfile_device be provided, it needs to be in UUID=uuid-here format. Also, keyfile path is then treated relatively to the root of the keyfile device. What makes UUID special? Why it cannot be anything mount understands (like LABEL=..., /dev/disk/by-uuid/...). systemd already has code to resolve it. UUID uniquely identifies the device and is always there. AFAIK that is not true for LABEL. Supporting LABEL would complicate things and since I wasn't even sure if my solution was the way to go, I didn't bother with it. -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
Luke Kenneth Casson Leighton [2015-02-23 2:08 +]: the problem, zbigniew, is that the intended use of this silent noop feature - to make it *possible* to have an alternative PID1 - *hasn't happened*. It sure has. Debian supports systemd, SysV init, and to a lesser degree OpenRC and upstart. any upstream software developer who has added in support for systemd has done so by *ripping out* the former alternative code. not a single upstream system that i've seen has done *any* kind of run-time detection *at all*. it's all compile-time. libsystemd does that very run-time detection, and upstream software usually falls back to the normal way of opening sockets if socket activation via libsystemd fails (either because you aren't running systemd or the service isn't socket activated). aside from getting the message across to upstream developers about doing runtime detection, i feel that what you guys really need to do is to set up conferences with everyone, to talk - urgently - about ways to ensure that the alternative systems which the wholesale adoption of systemd has excluded may be reinstated as *runtime* choices (not compile-time). You didn't follow, or see the results of the big Debian systemd debate at all, did you? :-) Pretty please do some actual research about the situtation first, and keep apart libsystemd (harmless, works with any init system) from systemd (the init system, pid 1, services around it, etc). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
El 22/02/15 a las 23:08, Luke Kenneth Casson Leighton escribió: the problem, zbigniew, is that the intended use of this silent noop feature - to make it *possible* to have an alternative PID1 - *hasn't happened*. any upstream software developer who has added in support for systemd has done so by *ripping out* the former alternative code. not a single upstream system that i've seen has done *any* kind of run-time detection *at all*. it's all compile-time. This is because software is written mostly by sane people who has at least a clue about what they are doing and talking, they are not doing what you wish, because what you are proposing is batshit insane. aside from getting the message across to upstream developers about doing runtime detection, i feel that what you guys really need to do is to set up conferences with everyone, to talk - urgently - about ways to ensure that the alternative systems which the wholesale adoption of systemd has excluded may be reinstated as *runtime* choices (not compile-time). Ha! that's a funny one.. why should we do that? the burden on doing that is on the people that want this theorical alternatives. that may mean discussing a set of APIs that end up being DL'd (like PAM is, right now), PAM is not dlopen'ed.. pam *modules* are.. and PAM is not something to cite as an example how to do things *today* in 2015.. the situation now is one where people believe that systemd is being heavily promoted to the exclusion of all other PID1 alternatives, developed with a focus on fedora / redhat to the exclusion of all other distros, developed for desktop systems *only* to the exclusion of servers and embedded systems... it's no wonder that there's a lot of upset people in the software libre community! You dropped your tinfoil hat now.. i know it sounds weird to go backwards, but the situation is - amongst other not very nice things - that the GNU/Linux world now has a new monoculture attack vector at the PID1 level in code that's being *actively developed and extended, dramatically*. Please go and learn how and particulary *why* things work a certain way before telling people how to do it, in fact don't tell.. .post patches or experiment yourself. You can dlopen systemd libraries at your own risk, if you know exactly what you are doing and why it will work..in most cases it will end in a terrible mess that we will get the blame for it.. I just wrote a patch to disallow dlopen of libsystemd alltogether..I hope it won't be needed because I still trust developers not to be that misguided. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
El 22/02/15 a las 22:37, Luke Kenneth Casson Leighton escribió: well, you could provide hints in the documentation (and force them to be read by deliberately changing the API) Wow.. so what you want is even nuttier than I thought.. that would be a good place to start, showing people how to begin the process of dlopen()ing libsystemd0, documenting it well so that it was easy to follow. No, again. using dlopen with libsystemd is crazy, you will only turn software even more complex and ugly than already is. and with this little gem: -- a/Makefile.am +++ b/Makefile.am @@ -3046,7 +3046,7 @@ libsystemd_la_CFLAGS = \ $(libsystemd_journal_internal_la_CFLAGS) libsystemd_la_LDFLAGS = \ - $(AM_LDFLAGS) \ + $(AM_LDFLAGS) -Wl,-z,nodlopen \ we can stop the madness from becoming reality :-) * distros are forced to follow suit on upstream decisions, without consulting what any other distros do No, distros are welcome to come here and influence the direction of the project and its components, before reality imposes itself. those who do the work, make decisions. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Tue, Feb 17, 2015 at 12:24 PM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: i don't know if you've seen this yet: http://news.slashdot.org/story/15/02/15/1959209/removing-libsystemd0-from-a-live-running-debian-system my name's luke leighton, i'm a software libre advocate, and the first major contribution that i made to software libre was to help bridge the impossible chasm between the microsoft world and the unix world, back in 1996 to 1999, by implementing and documenting NT Domains as well as a proper Network Neighbourhood (features of which, interestingly, have since been completely reimplemented in the form of avahi and zeroconf). i now tend to keep to myself except in circumstances where i perceive something similar occurring in the software libre community: a polarisation or an opportunity to extend (or reduce) the reach of software libre. a decision that has been made which makes the lives of huge numbers of ordinary users and systems administrators incredibly difficult, forcing them to make impossible decisions - that sort of thing. i note that there was announcement recently that the systemd team 'listens to users', so i am taking you at your word on that. now, i'm keenly aware of the views (technical and more) of systemd: i'm aware that there have been polls. most of them remind me of mother theresa's refusal to go to a war protest rally - she pointed out that next time they had a *peace* rally, to give her a call. so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt it's an enormous list, comprising some 15% of the packages present in debian today. it includes apache2-dev, bluetooth / bluez, the gimp, php, *all* of the video players (xine, mplayer, vlc), *all* of the games and 3D packages that use SDL or pulseaudio (which is most of them), *all* of the major desktop environments including xfce4, lxde, Gnome and KDE/Plasma, cups-daemon, one of the anti-virus daemons, most of the music software packages and services, most of the VoIP clients, the android SDK, the eclipse IDE, OpenJDK 7, erlang, Apache Tomcat. i'm just absolutely blown away by the extent of the dependencies. oh - and php as well. what the heck php5 is doing with a hard dependency on libsystemd0 i cannot imagine. now, because those are hard compile-time dependencies, the only possibility for the average debian user who chooses *not* to have libsystemd0 present on their system is for them to simply... not use *anything* on that list of over four and a half THOUSAND packages. i think the most important question to ask you at this point is: as a team, were you aware of the extent to which libsystemd0 has become a hard compile-time dependency on so many critical software packages in use today? and the second question, which is just as important, is: does this shock or alarm you enough to appreciate why people find the rapid introduction of libsystemd0 to be so objectionable? before answering, please bear in mind that i have done an analysis of a similar library and runtime (which i worked with a decade ago and am a minor contributor on): libselinux1 and SE/LInux. i can tell you right now that the way in which SE/Linux was introduced is *genuinely* completely different from the one that has brought us libsystemd0 (and has nothing to do with the technical debate, merits or otherwise of the software *or* its alternatives). in fact, the way in which libselinux1 was introduced - the careful research, the definition of its scope, how its instigators stuck to a clear roadmap, and its gradual introduction as an *optional* component that could be tested, deployed and rolled back *without* inconvenience or attempting to reverse impossiblly challenging or irreversible decisions if found to be troublesome, could be said (with understatement) to be a humbling model that libsystemd0 should learn from, retrospectively, very very fast. now, since beginning to write this a couple of days ago, i have encountered this: * https://lists.debian.org/debian-devel/2015/02/msg00189.html * http://forums.debian.net/viewtopic.php?f=20t=119836 there, we see that a debian developer has created unofficial packages that, if installed, provide replacements for key strategic packages entirely recompiled *without* systemd and without libsystemd0 being present. the key here is that they *are* entirely unofficial, making the decision to install them a difficult one, and flat-out impossible for many deployments where there are rules and contracts in place that prevent and prohibit the use even of debian-backports, let alone unofficial repositories. also, adam's work is only going to get harder and harder as time goes by, as the depth and extent of systemd's
Re: [systemd-devel] feature request: dlopen
On Sun, Feb 22, 2015 at 11:58:25PM +, Luke Kenneth Casson Leighton wrote: On Wed, Feb 18, 2015 at 9:10 AM, Tobias Hunger tobias.hun...@gmail.com wrote: Hi Luke, I am mostly a lurker on the systemd mailing list, so my opinion does not carry weight in this community. On Tue, Feb 17, 2015 at 9:24 PM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt I understood most of these dependencies to be indirect: Packages that depend on other packages that in turn depend on libsystemd. Is that correct? that's right. so, what that means is that the actual number of packages which would need to be converted to dynamic loading is actually very small (about 100), and the remaining 4,483 would be fine (not need any work done on them at all). On the other hand the library is tiny and basically falls back to being a no-op in the case where systemd is not PID1, so it does not hurt non-systemd systems to have this library in any way. ...except that its introduction (usually --with-libsystemd) in those 100 (or so) packages has been done in a mutually-exclusive, hard-compile-time switch that *excludes* the possibility of dynamic (runtime) decision-making. I think this is the crux of the matter. Please accept the fact that this compile time switch does not preclude runtime decision making at all. When not running under systemd, calls into libsystemd degrade into silent noops. So they only cost that is an extra unused 600kb library, which is completely insignificant. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Sun, Feb 22, 2015 at 4:52 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Feb 22, 2015 at 11:58:25PM +, Luke Kenneth Casson Leighton wrote: On Wed, Feb 18, 2015 at 9:10 AM, Tobias Hunger tobias.hun...@gmail.com wrote: Hi Luke, I am mostly a lurker on the systemd mailing list, so my opinion does not carry weight in this community. On Tue, Feb 17, 2015 at 9:24 PM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt I understood most of these dependencies to be indirect: Packages that depend on other packages that in turn depend on libsystemd. Is that correct? that's right. so, what that means is that the actual number of packages which would need to be converted to dynamic loading is actually very small (about 100), and the remaining 4,483 would be fine (not need any work done on them at all). On the other hand the library is tiny and basically falls back to being a no-op in the case where systemd is not PID1, so it does not hurt non-systemd systems to have this library in any way. ...except that its introduction (usually --with-libsystemd) in those 100 (or so) packages has been done in a mutually-exclusive, hard-compile-time switch that *excludes* the possibility of dynamic (runtime) decision-making. I think this is the crux of the matter. Please accept the fact that this compile time switch does not preclude runtime decision making at all. When not running under systemd, calls into libsystemd degrade into silent noops. So they only cost that is an extra unused 600kb library, which is completely insignificant. And when it is significant you are usually in situation where you are compiling your own packages and can remove the systemd compile time option. -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Mon, Feb 23, 2015 at 1:25 AM, Cameron Norman camerontnor...@gmail.com wrote: ...except that its introduction (usually --with-libsystemd) in those 100 (or so) packages has been done in a mutually-exclusive, hard-compile-time switch that *excludes* the possibility of dynamic (runtime) decision-making. I think this is the crux of the matter. Please accept the fact that this compile time switch does not preclude runtime decision making at all. When not running under systemd, calls into libsystemd degrade into silent noops. So they only cost that is an extra unused 600kb library, which is completely insignificant. And when it is significant you are usually in situation where you are compiling your own packages and can remove the systemd compile time option. *thinking this scenario through* yes. typically the outlier OSes and build environments (the embedded ones). openwrt, buildroot, openembedded, and so on. emdebian is an interesting corner-case, there, which is probably going to be adversely affected. emdebian is unique in that it isn't a pure from-source embedded OS, it's a half-way house between precompiled (best of debian) and a base on which you are encouraged to cross-compile further packages. unlike other scenarios (all of which are from-scratch complete source recompiles, usually cross-compiled), emdebian _is_ going to be caught between a rock and a hard place on that one. l. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
On Wed, Feb 18, 2015 at 9:10 AM, Tobias Hunger tobias.hun...@gmail.com wrote: Hi Luke, I am mostly a lurker on the systemd mailing list, so my opinion does not carry weight in this community. On Tue, Feb 17, 2015 at 9:24 PM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt I understood most of these dependencies to be indirect: Packages that depend on other packages that in turn depend on libsystemd. Is that correct? that's right. so, what that means is that the actual number of packages which would need to be converted to dynamic loading is actually very small (about 100), and the remaining 4,483 would be fine (not need any work done on them at all). On the other hand the library is tiny and basically falls back to being a no-op in the case where systemd is not PID1, so it does not hurt non-systemd systems to have this library in any way. ...except that its introduction (usually --with-libsystemd) in those 100 (or so) packages has been done in a mutually-exclusive, hard-compile-time switch that *excludes* the possibility of dynamic (runtime) decision-making. we see that a debian developer has created unofficial packages that, if installed, provide replacements for key strategic packages entirely recompiled *without* systemd and without libsystemd0 being present. Good for them. I see very little value in replacing a ~150KiB library that does nothing for the users these packages are targeting, but everybody is free to spend their time however they want. they made it possible to remove systemd entirely. they had to recompile cups, stunnel, udisks2, upower, util-linux and many more... here's the list: http://angband.pl/debian/dists/nosystemd/main/binary-amd64/Packages but here's the problem: because there is no dynamic run-time decisions possible here, people are forced to adding that (unofficial) repo and to risk their systems in the process. reverting is also just as risky. but, the worst thing is that because it's not an official repo, any corporation that has for example a support contract is *prevented and prohibited* from using the angband.pl repo because it would violate their support contract. moving on: in what adam wrote (rather hot-headedly, initially), he goes on to mention that it would be perfectly reasonable to replicate the effects of how he removed libsystemd0, in a way that would be far less disruptive to end-users and sysadmins, and far less divisive: dynamic library loading. Libsystemd's job is basically to provide exactly what you ask for: A wrapper around systemd functionality, that fails gracefully in case systemd is not used. honestly, i find it hard to argue with that. i think i know what the problem is. the problem is, i believe, that the detection is not user-controllable. question: does libsystemd have a config-file option that it reads, where if systemd = disabled is present, for example, it is effectively equivalent to not having systemd installed? i'm going with the flow here, btw, even though it actually partially undermines the case that i'm endeavouring to get across to the team. That wrapper is nicely packaged up into a library so that upstream projects do not need to keep reimplementing the same dlopen, error handling, etc. over and over again. Your proposal is to ask every upstream project to add that same snippet of code? yes. in a dynamic way that includes a config file option which allows run-time disabling of systemd. How about putting that into a library for easier reuse: Maybe libsystemdwrapper. That can then be wrapped in another wrapper when somebody freaks out about everything is linking to libsystemdwrapper. haha yehh, it would look like that wouldn't it. except that at the first opportunity where it is configurable via a plain text file to disable the chain-of-loading-loaders, the purpose would have been achieved, so there would be no need for another loader-of-loaders. ok i'm going with the silliness, here, but you know what i mean. Maybe just renaming libsystemd would suffice? I am sure hardly nobody would object to having a tiny libyzy on their system:-) :) in all seriousness, any kind of modification outside of what's available from the distros is... it can't be done. really. this is too low-level. one mistake renaming a library without knowing the consequences and people would end up with unbootable systems. and would be in violation of their support contracts. etc. etc. so can i leave it with you to consider whether the current situation is tolerable or not? Again: I can in no way speak for the systemd project. But from where I stand the systemd project went out of their way to provide you with exactly what
Re: [systemd-devel] feature request: dlopen
On Wed, Feb 18, 2015 at 10:00 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 17.02.15 20:24, Luke Kenneth Casson Leighton (l...@lkcl.net) wrote: i note that there was announcement recently that the systemd team 'listens to users', so i am taking you at your word on that. Hmm, I am not aware of such an announcement. somewhere there was a blog post i read of yours where (probably garbled) i got the impression that that was the case. a possible explanation is that i generally perceive blogs to be announcements. I generally listen though, but I don't always agree. that's good to hear I particularly don't listen to badly researched conspiracy theories. good! i trust you're happy to discern the difference between such and an attempt to understand - from a cross-project perspective - what the heck is going on here. i'm applying my reverse-engineering hat, here (normally reserved for assembly code or network systems) to the situation surrounding systemd's... rejection, shall we say. as i mentioned to tobias's post a few minutes ago, the situation - the bad feeling that's got sysadmins and experienced unix users worried and has made enemies out of decades-established acquaintances in high profile GNU/Linux distros - is completely without precedent in the history of free software. i don't have all the answers, but i _can_ tell that something's drastically wrong. so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt Well, I doubt this is correct, lennrt, smacked wrist! :) greg's answer (asking me to provide the information on how that file was created) is the exemplary one. apologies that i wasn't keeping up-to-date with the incoming messages, otherwise i would potentially have provided you with the commands to replicate the above list, earlier, so there would be no doubt. ohh ok i'll work out the commands rather than do it by hand like i did for that list last week, here it is: lkcl@bigmac:~$ apt-rdepends -r libsystemd0 | grep Reverse Depends | cut -f2 -d: | cut -f2 -d' ' | sort | uniq | wc Reading package lists... Done Building dependency tree Reading state information... Done 45834583 70416 the other one (which provides the list of *immediate* dependencies), is apt-cache rdepends libsystemd0 and even if it was, I am not sure what systemd upstream has to do with it. i went over this in the [now that i re-read it, very long... sorry...] reply to tobias. Convince the upstream developers in question not to link against systemd's libraries, or convince the distros not to package it like that. well, you could provide hints in the documentation (and force them to be read by deliberately changing the API) and you could provide an example by leading the conversion. for example, i understand that you're the developer behind portaudio? that would be a good place to start, showing people how to begin the process of dlopen()ing libsystemd0, documenting it well so that it was easy to follow. We just offer a library, which apparently is interesting to people to use, but whether they use it is really not up to us. well... they've used it, alright. so much so that there isn't a single major GNU/Linux distro left, nor a major GNU/Linux desktop environment, that may be used *without* systemd or a systemd-compatible component. xfce4, lxde, kde, gnome - they're all now critically and exclusively dependent on systemd. clarification, there: i'm aware for example that KDE5 now uses the dbus logind API, so the FreeBSD team are considering writing a replacement logind rather than fishing through the old commits that removed the previous code. and that's the problem in a nutshell - the chain if you like of decisions that have got us to this very bad situation: * distros are forced to follow suit on upstream decisions, without consulting what any other distros do * distros are (with the exception of gentoo, freebsd and macports as they are all source-based) forced to hard-code the best possible compile-time options that are *available* to them * the upstream decisions on a per-app basis have been made in isolation without a proper across-the-board cross-project analysis. * the development of systemd has been done in the perfectly reasonable way of using fedora as the proving-ground... in isolation from other distros. end result: systemd is now *the* de-facto PID 1 across all major GNU/Linux distros in the space of something like under a year, with all other work almost completely locked out and being forced to be compatible with systemd in some way (via replicating the API in some way, by forking older versions of systemd, writing function-for-function API-compatible equivalent d-bus services which is *really* hard to get right, and so on).
Re: [systemd-devel] feature request: dlopen
On Mon, Feb 23, 2015 at 12:52 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Feb 22, 2015 at 11:58:25PM +, Luke Kenneth Casson Leighton wrote: ...except that its introduction (usually --with-libsystemd) in those 100 (or so) packages has been done in a mutually-exclusive, hard-compile-time switch that *excludes* the possibility of dynamic (runtime) decision-making. I think this is the crux of the matter. Please accept the fact that this compile time switch does not preclude runtime decision making at all. When not running under systemd, calls into libsystemd degrade into silent noops. So they only cost that is an extra unused 600kb library, which is completely insignificant. the problem, zbigniew, is that the intended use of this silent noop feature - to make it *possible* to have an alternative PID1 - *hasn't happened*. any upstream software developer who has added in support for systemd has done so by *ripping out* the former alternative code. not a single upstream system that i've seen has done *any* kind of run-time detection *at all*. it's all compile-time. aside from getting the message across to upstream developers about doing runtime detection, i feel that what you guys really need to do is to set up conferences with everyone, to talk - urgently - about ways to ensure that the alternative systems which the wholesale adoption of systemd has excluded may be reinstated as *runtime* choices (not compile-time). that may mean discussing a set of APIs that end up being DL'd (like PAM is, right now), it may mean doing something similar to apache loadable modules, or something like the infrastructure behind python objects, i don't know, but you *need to talk*. and you know what? if you were to say, we're genuinely concerned that the alternatives to systemd are being locked out, let's talk, urgently. we really mean it, i think you'd find that people would respond positively. the situation now is one where people believe that systemd is being heavily promoted to the exclusion of all other PID1 alternatives, developed with a focus on fedora / redhat to the exclusion of all other distros, developed for desktop systems *only* to the exclusion of servers and embedded systems... it's no wonder that there's a lot of upset people in the software libre community! i know it sounds weird to go backwards, but the situation is - amongst other not very nice things - that the GNU/Linux world now has a new monoculture attack vector at the PID1 level in code that's being *actively developed and extended, dramatically*. it was bad enough that shellshock meant that sysvinit was vulnerable right across the board of every GNU/Linux distribution. but at least sysvinit is old enough to have had significant security audit and review over the decades, such that when shellshock was fixed, that was it, problem solved [until the next vulnerability...] contrast that to the situation now: with systemd being so actively developed and then deployed across literally every major GNU/Linux distro without exception, the possibility for serious vulnerabilities having a disproportionately large adverse effect is much higher than i feel it should be. l. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
