[systemd-devel] Do we need /dev/core?

Does anybody know about something actually using /dev/core or is it yet another instance of cargo cult sysadmining? A Debian code search shows only two packages using it. In tests. Wrongly. https://codesearch.debian.net/results/%22%2Fdev%2Fcore%22/page_0 Can we officially deprecate it and then

Re: [systemd-devel] Do we need /dev/core?

On Dec 30, "Jóhann B. Guðmundsson" wrote: > You should ask that question on the kernel mailinglist and or on the Debian > devel list if they want to remove that symbolic link to /proc/kcore I am already dealing with the Debian side (and there is no point in removing the link

[systemd-devel] systemd-nspawn should not require getent initgroups

It was implemented in glibc 2.15, so it is not available in Debian stable and RHEL 6 at least, and systemd-nspawn --user does not work. -- ciao, Marco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org

Re: [systemd-devel] systemd-nspawn should not require getent initgroups

On Sep 14, Tomasz Torcz to...@pipebreaker.pl wrote: It was implemented in glibc 2.15, so it is not available in Debian stable and RHEL 6 at least, and systemd-nspawn --user does not work. Those distribution won't see systemd implemented during their lifetime, so this is not a problem I

Re: [systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service

On Aug 26, Lennart Poettering lenn...@poettering.net wrote: If it makes you happy, then I can add a big warning to configure, if people build things and don't specify their own NTP servers... The history is full of people who got burned by using somebody's else NTP servers without permission,

Re: [systemd-devel] How to get rid of this ordering cycle?

On Aug 14, Lennart Poettering lenn...@poettering.net wrote: Hmm, Debian still generates persistent rules at boot? Yuck! Experience shows that it worked better than the alternatives for our users, so I think that we will just keep it around for a while, probably until most hardware will provide

Re: [systemd-devel] [PATCH 03/10] rules: load sg module from 80-drivers.rules

On Jul 16, Kay Sievers k...@vrfy.org wrote: +SUBSYSTEM==scsi, ENV{DEVTYPE}==scsi_device, TEST!=[module/sg], RUN{builtin}+=kmod load sg We do not want to force-load the sg driver. Why would that be needed? When we tried removing this some application stopped working, but I do not remember

Re: [systemd-devel] [PATCH] systemd-detect-s390-virt: add virtualization detection on s390x

On Jul 07, Thomas Blume thomas.bl...@suse.com wrote: Hm, s390 (32 bit) is quiet ancient. Not sure if anyone would use such old systems with a pretty recent linux version shipping systemd. But if there are some use cases, of course we could do this. Debian recently killed the s390 port in

Re: [systemd-devel] mount units and symlinks

On Jun 30, Lennart Poettering lenn...@poettering.net wrote: BTW, I have now prepped a man page that codifies the assumptions and suggestions systemd makes on the file system hierarchy: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html Another difference is that Debian,

Re: [systemd-devel] mount units and symlinks

On Jun 30, Lennart Poettering lenn...@poettering.net wrote: BTW, I have now prepped a man page that codifies the assumptions and suggestions systemd makes on the file system hierarchy: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html The other major issue that I can see is

[systemd-devel] NoNewPrivileges and Postfix

I tried using NoNewPrivileges=yes in my inn package, but then I noticed that the daemon was unable to send emails: Jun 18 07:59:38 bongo boot[4623]: postdrop: warning: mail_queue_enter: create file maildrop/111862.4636: Permission denied This happens because postdrop is SGID to be able to

[systemd-devel] Restart best practices

Should upstream packages and distributions use Restart=on-failure in their default configuration unless there are package-specific reasons to not do this? -- ciao, Marco signature.asc Description: Digital signature ___ systemd-devel mailing list

Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default

On Mar 20, Lennart Poettering lenn...@poettering.net wrote: TO figure out what we can do in Fedora I have now started a discussion on fedora-devel, about getting rid of tcpwrap system-wide. Let's see where this goes. Would be interested in feedback about this from other distros too. Debian