[systemd-devel] Misc patches from the Debian systemd package
Hi I'm part of the team working on updating the Debian systemd package to v214. As part of that work I have been rebasing and updating the Debian specific patches, and found several that might be appropriate for upstream. While I'm not the original author of these I have been rebasing and updating them, so while most the credit goes to the original autors, any blame should fall on me :-P Regards Jon Severinsson ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 07/10] units: order remote-fs.target after local-fs.target
From: Michael Biebl bi...@debian.org This change was part of the old debianisation branch created by Tollef and reflects the fact that on Debian the $remote_fs system facility depends on $local_fs. --- units/remote-fs.target | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/units/remote-fs.target b/units/remote-fs.target index 43ffa5c..655621f 100644 --- a/units/remote-fs.target +++ b/units/remote-fs.target @@ -8,7 +8,7 @@ [Unit] Description=Remote File Systems Documentation=man:systemd.special(7) -After=remote-fs-pre.target +After=remote-fs-pre.target local-fs.target DefaultDependencies=no Conflicts=shutdown.target -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 09/10] kmod-static-nodes: condition execution on kmod binary
From: Michael Biebl bi...@debian.org Creating the list of dead device nodes requires kmod. Inside containers this is not strictly required so we don't want a hard dependency on the kmod package. If the binary does not exist kmod-static-nodes.service will fail, so add a condition to check if the binary is available. --- units/kmod-static-nodes.service.in | 1 + 1 file changed, 1 insertion(+) diff --git a/units/kmod-static-nodes.service.in b/units/kmod-static-nodes.service.in index 0934a87..076e316 100644 --- a/units/kmod-static-nodes.service.in +++ b/units/kmod-static-nodes.service.in @@ -11,6 +11,7 @@ DefaultDependencies=no Before=sysinit.target systemd-tmpfiles-setup-dev.service ConditionCapability=CAP_SYS_MODULE ConditionPathExists=/lib/modules/%v/modules.devname +ConditionFileIsExecutable=@KMOD@ [Service] Type=oneshot -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 05/10] rules: skip 99-systemd.rules when not running systemd as init
From: Tollef Fog Heen tfh...@err.no --- rules/99-systemd.rules.in | 1 + 1 file changed, 1 insertion(+) diff --git a/rules/99-systemd.rules.in b/rules/99-systemd.rules.in index c3ef81b..df83a38 100644 --- a/rules/99-systemd.rules.in +++ b/rules/99-systemd.rules.in @@ -6,6 +6,7 @@ # (at your option) any later version. ACTION==remove, GOTO=systemd_end +TEST!=/run/systemd/system, GOTO=systemd_end SUBSYSTEM==tty, KERNEL==tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*, TAG+=systemd -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 01/10] build-sys: don't move libgudev to /lib
From: Michael Biebl bi...@debian.org It depends on libgobject and libgmodule which are installed in /usr/lib. --- Makefile.am | 10 -- 1 file changed, 10 deletions(-) diff --git a/Makefile.am b/Makefile.am index a492a1f..94cd402 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3373,16 +3373,6 @@ typelibs_DATA = \ CLEANFILES += $(gir_DATA) $(typelibs_DATA) endif # HAVE_INTROSPECTION - -# move lib from $(libdir) to $(rootlibdir) and update devel link, if needed -libgudev-install-hook: - libname=libgudev-1.0.so $(move-to-rootlibdir) - -libgudev-uninstall-hook: - rm -f $(DESTDIR)$(rootlibdir)/libgudev-1.0.so* - -INSTALL_EXEC_HOOKS += libgudev-install-hook -UNINSTALL_EXEC_HOOKS += libgudev-uninstall-hook endif EXTRA_DIST += \ -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 06/10] tmpfiles: fix permissions of /run/lock and /run/lock/lockdev
From: Tollef Fog Heen tfh...@err.no --- tmpfiles.d/legacy.conf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tmpfiles.d/legacy.conf b/tmpfiles.d/legacy.conf index 3219672..a634c17 100644 --- a/tmpfiles.d/legacy.conf +++ b/tmpfiles.d/legacy.conf @@ -10,7 +10,7 @@ # These files are considered legacy and are unnecessary on legacy-free # systems. -d /run/lock 0755 root root - +d /run/lock 1777 root root - L /var/lock - - - - ../run/lock # /run/lock/subsys is used for serializing SysV service execution, and @@ -24,7 +24,7 @@ d /run/lock/subsys 0755 root root - # On modern systems a BSD file lock is a better choice if # serialization is needed on those devices. -d /run/lock/lockdev 0775 root lock - +d /run/lock/lockdev 0775 root root - # /forcefsck, /fastboot and /forcequotecheck are deprecated in favor of the # kernel command line options 'fsck.mode=force', 'fsck.mode=skip' and -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 08/10] units: make it possible to disable tmp.mount using systemctl
From: Michael Stapelberg mich...@stapelberg.de But enable it by default in make install and systemd preset. --- Makefile.am | 4 ++-- system-preset/90-systemd.preset | 1 + units/tmp.mount | 3 +++ 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index 94cd402..68f2c5b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -5545,8 +5545,7 @@ SYSINIT_TARGET_WANTS += \ ldconfig.service LOCAL_FS_TARGET_WANTS += \ - systemd-remount-fs.service \ - tmp.mount + systemd-remount-fs.service MULTI_USER_TARGET_WANTS += \ getty.target \ @@ -5591,6 +5590,7 @@ USER_UNIT_ALIASES += \ GENERAL_ALIASES += \ $(systemunitdir)/remote-fs.target $(pkgsysconfdir)/system/multi-user.target.wants/remote-fs.target \ $(systemunitdir)/getty@.service $(pkgsysconfdir)/system/getty.target.wants/getty@tty1.service \ + $(systemunitdir)/tmp.mount $(pkgsysconfdir)/system/local-fs.target.wants/tmp.mount \ $(pkgsysconfdir)/user $(sysconfdir)/xdg/systemd/user \ $(dbussystemservicedir)/org.freedesktop.systemd1.service $(dbussessionservicedir)/org.freedesktop.systemd1.service diff --git a/system-preset/90-systemd.preset b/system-preset/90-systemd.preset index e4a9e17..8169554 100644 --- a/system-preset/90-systemd.preset +++ b/system-preset/90-systemd.preset @@ -8,6 +8,7 @@ # These ones should be enabled by default, even if distributions # generally follow a default-off policy. +enable tmp.mount enable remote-fs.target enable getty@.service enable systemd-readahead-* diff --git a/units/tmp.mount b/units/tmp.mount index 00a0d28..8777171 100644 --- a/units/tmp.mount +++ b/units/tmp.mount @@ -19,3 +19,6 @@ What=tmpfs Where=/tmp Type=tmpfs Options=mode=1777,strictatime + +[Install] +WantedBy=local-fs.target -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 03/10] rules: load sg module from 80-drivers.rules
From: Martin Pitt martin.p...@ubuntu.com
Taken from the Debian specific rules, this is the remaining difference over the
upstream 80-drivers.rules.
Bug-Debian: http://bugs.debian.org/657948
---
rules/80-drivers.rules | 1 +
1 file changed, 1 insertion(+)
diff --git a/rules/80-drivers.rules b/rules/80-drivers.rules
index 8551f47..f764075 100644
--- a/rules/80-drivers.rules
+++ b/rules/80-drivers.rules
@@ -9,5 +9,6 @@ SUBSYSTEM==memstick, RUN{builtin}+=kmod load ms_block
mspro_block
SUBSYSTEM==i2o, RUN{builtin}+=kmod load i2o_block
SUBSYSTEM==module, KERNEL==parport_pc, RUN{builtin}+=kmod load ppdev
KERNEL==mtd*ro, ENV{MTD_FTL}==smartmedia, RUN{builtin}+=kmod load sm_ftl
+SUBSYSTEM==scsi, ENV{DEVTYPE}==scsi_device, TEST!=[module/sg],
RUN{builtin}+=kmod load sg
LABEL=drivers_end
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 10/10] shared: include stdbool.h in mkdir.h
From: Sjoerd Simons sjo...@luon.net --- src/shared/mkdir.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/shared/mkdir.h b/src/shared/mkdir.h index d15ede6..dd5b41e 100644 --- a/src/shared/mkdir.h +++ b/src/shared/mkdir.h @@ -22,6 +22,7 @@ along with systemd; If not, see http://www.gnu.org/licenses/. ***/ +#include stdbool.h #include sys/types.h int mkdir_safe(const char *path, mode_t mode, uid_t uid, gid_t gid); -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 06/10] tmpfiles: fix permissions of /run/lock and /run/lock/lockdev
Why do you think this should be changed? On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson j...@severinsson.net wrote: From: Tollef Fog Heen tfh...@err.no --- tmpfiles.d/legacy.conf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tmpfiles.d/legacy.conf b/tmpfiles.d/legacy.conf index 3219672..a634c17 100644 --- a/tmpfiles.d/legacy.conf +++ b/tmpfiles.d/legacy.conf @@ -10,7 +10,7 @@ # These files are considered legacy and are unnecessary on legacy-free # systems. -d /run/lock 0755 root root - +d /run/lock 1777 root root - L /var/lock - - - - ../run/lock # /run/lock/subsys is used for serializing SysV service execution, and @@ -24,7 +24,7 @@ d /run/lock/subsys 0755 root root - # On modern systems a BSD file lock is a better choice if # serialization is needed on those devices. -d /run/lock/lockdev 0775 root lock - +d /run/lock/lockdev 0775 root root - # /forcefsck, /fastboot and /forcequotecheck are deprecated in favor of the # kernel command line options 'fsck.mode=force', 'fsck.mode=skip' and -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 06/10] tmpfiles: fix permissions of /run/lock and /run/lock/lockdev
On Wed, Jul 16, 2014 at 1:09 PM, Jon Severinsson j...@severinsson.net wrote: -d /run/lock 0755 root root - +d /run/lock 1777 root root - Won't any user be able to break the system by filling /run, if it has world-writable directories? IIRC, this was one of the reasons /run/user/* are separate 'tmpfs'es. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 05/10] rules: skip 99-systemd.rules when not running systemd as init
On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson j...@severinsson.net wrote: From: Tollef Fog Heen tfh...@err.no --- rules/99-systemd.rules.in | 1 + 1 file changed, 1 insertion(+) The file should not do any harm. If it does, we should check if something needs to be fixed in a different way. This patch looks like distro material who decide to support that. Systemd does not want to support any such setups with the upstream code base. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: do not generate 'Wants' symlinks to generated service files that will be shadowed by a native unit.
On Wed, Jul 16, 2014 at 11:57 AM, Jon Severinsson j...@severinsson.net wrote:
---
src/sysv-generator/sysv-generator.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/src/sysv-generator/sysv-generator.c
b/src/sysv-generator/sysv-generator.c
index 5206279..aff5fd6 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -113,7 +113,26 @@ static int add_symlink(const char *service, const char
*where) {
return 1;
}
-static int generate_unit_file(SysvStub *s) {
+static int native_unit_exists(LookupPaths lp, char *name) {
+char **p;
+
+STRV_FOREACH(p, lp.unit_path) {
+struct stat st;
+_cleanup_free_ char *path = NULL;
+
+path = strjoin(*p, /, name, NULL);
+if (!path)
+return -ENOMEM;
+
+if (lstat(path, st) 0)
+continue;
+
+return 1;
+}
+return 0;
+}
+
+static int generate_unit_file(LookupPaths lp, SysvStub *s) {
char *unit;
char **p;
_cleanup_fclose_ FILE *f = NULL;
@@ -190,6 +209,12 @@ static int generate_unit_file(SysvStub *s) {
if (s-reload)
fprintf(f, ExecReload=%s reload\n, s-path);
+/* Do not generate 'Wants' symlinks to the generated service file if
it
+ * will be shadowed by an existing native unit, as the symlinks would
+ * not be shadowed but would pull the native unit instead. */
+if (native_unit_exists(lp, s-name))
+return 0;
+
Any reason that we should not just put the native_unit_exists check in
enumerate_sysv instead and skip generating a unit at all?
STRV_FOREACH(p, s-wanted_by) {
r = add_symlink(s-name, *p);
if (r 0)
@@ -918,7 +943,7 @@ int main(int argc, char *argv[]) {
if (q 0)
continue;
-q = generate_unit_file(service);
+q = generate_unit_file(lp, service);
if (q 0)
continue;
}
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 03/10] rules: load sg module from 80-drivers.rules
On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson j...@severinsson.net wrote:
From: Martin Pitt martin.p...@ubuntu.com
Taken from the Debian specific rules, this is the remaining difference over
the
upstream 80-drivers.rules.
Bug-Debian: http://bugs.debian.org/657948
---
rules/80-drivers.rules | 1 +
1 file changed, 1 insertion(+)
diff --git a/rules/80-drivers.rules b/rules/80-drivers.rules
index 8551f47..f764075 100644
--- a/rules/80-drivers.rules
+++ b/rules/80-drivers.rules
@@ -9,5 +9,6 @@ SUBSYSTEM==memstick, RUN{builtin}+=kmod load ms_block
mspro_block
SUBSYSTEM==i2o, RUN{builtin}+=kmod load i2o_block
SUBSYSTEM==module, KERNEL==parport_pc, RUN{builtin}+=kmod load ppdev
KERNEL==mtd*ro, ENV{MTD_FTL}==smartmedia, RUN{builtin}+=kmod load
sm_ftl
+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?
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/10] build-sys: don't move libgudev to /lib
On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson j...@severinsson.net wrote: From: Michael Biebl bi...@debian.org It depends on libgobject and libgmodule which are installed in /usr/lib. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] conf parser: introduce milisecond parsing
On 07/16/2014 01:07 PM, Susant Sahani wrote: Add millisecord parsing support to conf parser. Immediate usage of this function is to parse bond options such as MIIMonitor, UpDelayMSec, DownDelayMSec which is represented in milli seconds. Dropped the idea . Please ignore the patch. Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 07/10] units: order remote-fs.target after local-fs.target
On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson j...@severinsson.net wrote: From: Michael Biebl bi...@debian.org This change was part of the old debianisation branch created by Tollef and reflects the fact that on Debian the $remote_fs system facility depends on $local_fs. If this is merely for sysv compat, it feels wrong to add this in the native unit files (but maybe the argument could be made regardless?). If it is just for bacwards compatibility, I would rather put it in the sysvgenerator itself (to add a drop-in if something pulls in $remote_fs). Not sure if this should be upstream or downstream though, depends if this makes sense outside of Debian. Cheers, Tom --- units/remote-fs.target | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/units/remote-fs.target b/units/remote-fs.target index 43ffa5c..655621f 100644 --- a/units/remote-fs.target +++ b/units/remote-fs.target @@ -8,7 +8,7 @@ [Unit] Description=Remote File Systems Documentation=man:systemd.special(7) -After=remote-fs-pre.target +After=remote-fs-pre.target local-fs.target DefaultDependencies=no Conflicts=shutdown.target -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 08/10] units: make it possible to disable tmp.mount using systemctl
On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson j...@severinsson.net wrote: From: Michael Stapelberg mich...@stapelberg.de But enable it by default in make install and systemd preset. tmp.mount is part of our default expected setup and should behave like this by default without any presets or configuration. It can be overridden by an entry in fstab just fine. Why is that needed? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 10/10] shared: include stdbool.h in mkdir.h
On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson j...@severinsson.net wrote: From: Sjoerd Simons sjo...@luon.net --- src/shared/mkdir.h | 1 + 1 file changed, 1 insertion(+) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: do not generate 'Wants' symlinks to generated service files that will be shadowed by a native unit.
onsdagen den 16 juli 2014 12:48:23 skrev du: On Wed, Jul 16, 2014 at 11:57 AM, Jon Severinsson j...@severinsson.net wrote: +/* Do not generate 'Wants' symlinks to the generated service file if it + * will be shadowed by an existing native unit, as the symlinks would + * not be shadowed but would pull the native unit instead. */ +if (native_unit_exists(lp, s-name)) +return 0; + Any reason that we should not just put the native_unit_exists check in enumerate_sysv instead and skip generating a unit at all? That was indeed my first attempt [1], but doing so confused set_dependencies_from_rcnd (which I papered over by removing the log_warning), would change the ordering of non-LSB init scripts (as fix_order would not know about the shadowed init script), and seems to have been rejected by Lennart Poettering already [2]. [1] https://github.com/jonseverinsson/debian-systemd/blob/3375f1cc4faf3dec61974af5a06b48004fdfaaeb/debian/patches/Do-not-generate-systemd-units-from-sysv-init-scripts.patch [2] http://lists.freedesktop.org/archives/systemd-devel/2014-July/020924.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 04/10] rules: set default polling interval on removable devices as well
On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson j...@severinsson.net wrote: From: Martin Pitt martin.p...@ubuntu.com The events_dfl_poll_msecs rule will not trigger if block is not a module, but built in. This will avoid udisks etc. having to poll from userspace, and provide proper ejection when the hardware eject button is pressed. This is all backwards, block can never be a module. The setiings from the rules should be applied just fine by coldplug, triggering the /sys/module/ directory. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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 which ones.
--
ciao,
Marco
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] [PATCH 06/10] tmpfiles: fix permissions of /run/lock and /run/lock/lockdev
onsdagen den 16 juli 2014 12:15:09 skrev du: Why do you think this should be changed? Mostly because this is the way it has always been done in Debian, and changing it breaks some existing init scripts, but I'm ok with continuing to carry it as a Debian specific patch if it is not considered appropriate for upstream. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 06/10] tmpfiles: fix permissions of /run/lock and /run/lock/lockdev
]] Jon Severinsson From: Tollef Fog Heen tfh...@err.no This one shouldn't be forwarded upstream, /run/lock has historically had different permissions in Debian and I'd rather get that fixed than pushing this upstream. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 02/10] rules: updates to default device permissions in 50-udev-default.rules
Hello Jon, Jon Severinsson [2014-07-16 12:09 +0200]: Taken from the previous Debian specific rules, this is the remaining difference over the upstream 50-udev-default.rules. I deliberately didn't forward that upstream, as most of these are ancient hacks which are mostly required for not breaking backwards compatibility on upgrades. Definitively not upstream material. 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] [PATCH 03/10] rules: load sg module from 80-drivers.rules
Kay Sievers [2014-07-16 12:53 +0200]:
On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson j...@severinsson.net
wrote:
From: Martin Pitt martin.p...@ubuntu.com
Taken from the Debian specific rules, this is the remaining difference over
the
upstream 80-drivers.rules.
Bug-Debian: http://bugs.debian.org/657948
---
rules/80-drivers.rules | 1 +
1 file changed, 1 insertion(+)
diff --git a/rules/80-drivers.rules b/rules/80-drivers.rules
index 8551f47..f764075 100644
--- a/rules/80-drivers.rules
+++ b/rules/80-drivers.rules
@@ -9,5 +9,6 @@ SUBSYSTEM==memstick, RUN{builtin}+=kmod load ms_block
mspro_block
SUBSYSTEM==i2o, RUN{builtin}+=kmod load i2o_block
SUBSYSTEM==module, KERNEL==parport_pc, RUN{builtin}+=kmod load ppdev
KERNEL==mtd*ro, ENV{MTD_FTL}==smartmedia, RUN{builtin}+=kmod load
sm_ftl
+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?
Most things don't need it. This was re-added because of
https://bugs.debian.org/657948 as a user complained that without it
some tape devices don't work any more with mtx.
Again, I deliberately didn't forward that upstream as this really
should be fixed in mtx. It's just a rule which the Debian package has
had for many years.
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] [PATCH 05/10] rules: skip 99-systemd.rules when not running systemd as init
Jon Severinsson [2014-07-16 12:09 +0200]: ACTION==remove, GOTO=systemd_end +TEST!=/run/systemd/system, GOTO=systemd_end I'm fairly sure that this is obsolete. Can you please test without this? 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] [PATCH 08/10] units: make it possible to disable tmp.mount using systemctl
tmp.mount is part of our default expected setup and should behave like this by default without any presets or configuration. Which is why I made `make install` enable it, which wasn't in the original patch for Debian. It can be overridden by an entry in fstab just fine. Why is that needed? To my knowledge you can not create an fstab entry that would make /tmp not be mounted at all but remain part of /. It can be done by masking the unit, but enable/disable seems more appropriate than unmask/mask. Note that when Debian tried to change the default from /tmp being part of / to being a tmpfs several applications broke and the default was eventually reverted. Most applications have probably been fixed since then, but even if we are able to change the default we will need a supported way of disabling it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: do not generate 'Wants' symlinks to generated service files that will be shadowed by a native unit.
On Wed, Jul 16, 2014 at 01:00:18PM +0200, Jon Severinsson wrote: onsdagen den 16 juli 2014 12:48:23 skrev du: On Wed, Jul 16, 2014 at 11:57 AM, Jon Severinsson j...@severinsson.net wrote: +/* Do not generate 'Wants' symlinks to the generated service file if it + * will be shadowed by an existing native unit, as the symlinks would + * not be shadowed but would pull the native unit instead. */ +if (native_unit_exists(lp, s-name)) +return 0; + Any reason that we should not just put the native_unit_exists check in enumerate_sysv instead and skip generating a unit at all? That was indeed my first attempt [1], but doing so confused set_dependencies_from_rcnd (which I papered over by removing the log_warning), would change the ordering of non-LSB init scripts (as fix_order would not know about the shadowed init script), and seems to have been rejected by Lennart Poettering already [2]. [1] https://github.com/jonseverinsson/debian-systemd/blob/3375f1cc4faf3dec61974af5a06b48004fdfaaeb/debian/patches/Do-not-generate-systemd-units-from-sysv-init-scripts.patch [2] http://lists.freedesktop.org/archives/systemd-devel/2014-July/020924.html In the light of your patch, the idea of *not* generating units at all seems like the best option. When we have both sysv and native: - Currently we always generate compat units, but like you say, their dependencies are summed, but the gist is taken from the native one. - With your patch, we would generate the unit file itself, which would be shadowed, but not its dependencies, so it would be useless anyway. - Third option is to skip wrapper unit generation at all IMHO, one is wrong, two is confusing. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-socket-proxyd slapd
want to start slapd with socket activation via 'systemd-socket-proxyd' ,
I can see that slapd is listening to port 400 sytemd create socket at
401. But ldapsearch doesn't work with port 401. Any help !!
---
1.
$ cat proxy-to-directory-400.socket
[Socket]
ListenStream=401
[Install]
WantedBy=sockets.target
--
2.
$ cat proxy-to-directory-400.service
[Unit]
Requires=vgp.master-ldap-400.
service
After=vgp.master-ldap-400.service
[Service]
ExecStart=/usr/lib/systemd/systemd-socket-proxyd ${HOSTNAME}:400
PrivateTmp=yes
PrivateNetwork=yes
---
3.
[Unit]
Description=Local OpenLDAP server
After=vgp.master-ldapdb-400-get.service
Requires=vgp.master-ldapdb-400-get.service
[Service]
Type=simple
LimitNOFILE=4096
LimitCORE=infinity
WorkingDirectory=/etc/ldapfiles/
ExecStart=/usr/local/libexec/slapd -d 0 -f /tmp/fsldap_400.conf -h
ldap://${HOSTNAME}:400; -l LOCAL1
--
Suvendu Mitra
GSM - +358504821066
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misc patches from the Debian systemd package
On 07/16/2014 10:09 AM, Jon Severinsson wrote: Hi I'm part of the team working on updating the Debian systemd package to v214. As part of that work I have been rebasing and updating the Debian specific patches, and found several that might be appropriate for upstream. While I'm not the original author of these I have been rebasing and updating them, so while most the credit goes to the original autors, any blame should fall on me :-P Given that there already has been Debian developer involved with pushing and integrating systemd into Debian so I have to ask are you sure these patches are not downstream with Debian simply because they are Debian specific or atleast at this point I would think they would have been submitted and merged already if they where not... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misc patches from the Debian systemd package
On Wed, Jul 16, 2014 at 01:03:15PM +, Jóhann B. Guðmundsson wrote: On 07/16/2014 10:09 AM, Jon Severinsson wrote: Hi I'm part of the team working on updating the Debian systemd package to v214. As part of that work I have been rebasing and updating the Debian specific patches, and found several that might be appropriate for upstream. While I'm not the original author of these I have been rebasing and updating them, so while most the credit goes to the original autors, any blame should fall on me :-P Given that there already has been Debian developer involved with pushing and integrating systemd into Debian so I have to ask are you sure these patches are not downstream with Debian simply because they are Debian specific or atleast at this point I would think they would have been submitted and merged already if they where not... Hi Jóhann, Kay already merged a few from this series. As for the other ones, revisiting them might give Debian the necessary energy to get rid of them. This seems like a useful exercise. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 08/10] units: make it possible to disable tmp.mount using systemctl
On Wed, Jul 16, 2014 at 2:57 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, Jul 16, 2014 at 01:51:13PM +0200, Jon Severinsson wrote: tmp.mount is part of our default expected setup and should behave like this by default without any presets or configuration. Which is why I made `make install` enable it, which wasn't in the original patch for Debian. It can be overridden by an entry in fstab just fine. Why is that needed? To my knowledge you can not create an fstab entry that would make /tmp not be mounted at all but remain part of /. It can be done by masking the unit, but enable/disable seems more appropriate than unmask/mask. Yeah, especially that this makes it possible for the distribution to nicely use presets to override the default. I don't think so. The common default of systemd should be /tmp on tmpfs, and it should be statically enabled. Tools should be fixed if needed to use /var/tmp for anything larger, and not systemd use preset stuff to setup core mount points. I think that having /tmp on rootfs is legitimate, e.g. on memory starved systems. The solution for such systems is called swap. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misc patches from the Debian systemd package
On Wed, Jul 16, 2014 at 3:03 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 07/16/2014 10:09 AM, Jon Severinsson wrote: I'm part of the team working on updating the Debian systemd package to v214. As part of that work I have been rebasing and updating the Debian specific patches, and found several that might be appropriate for upstream. While I'm not the original author of these I have been rebasing and updating them, so while most the credit goes to the original autors, any blame should fall on me :-P Given that there already has been Debian developer involved with pushing and integrating systemd into Debian so I have to ask are you sure these patches are not downstream with Debian simply because they are Debian specific or atleast at this point I would think they would have been submitted and merged already if they where not... It is probably just not obvious enough. The packagers who add patches to the Debian package should probably leave notes in the patch there why this patch isn't upstream, or not meant to go upstream. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 07/10] units: order remote-fs.target after local-fs.target
On Wed, Jul 16, 2014 at 12:57:41PM +0200, Tom Gundersen wrote: If this is merely for sysv compat, it feels wrong to add this in the native unit files (but maybe the argument could be made regardless?). That was indeed the original reason for the patch, but I believe it to be the right thing to do anyway. At Wednesday 16 July 2014 14:50:39 Zbigniew Jędrzejewski-Szmek wrote: It does not provide anything for the services which are part of remote- fs.target, they have to carry their own dependencies on local-fs.target if necessary. Correct, or prefferably only on the mount-points in local-fs.target they actually need... So the only thing it does is that it'll delay remote-fs.target if it were to be reached before local-fs.target. Which in my oppinion is a good thing, as writers of service files, as well as legacy init scripts, should rightfully be able to assume that if they request all remote file systems to be mounted, local file systems will be too. Also I would have a hard time explaining why a change of a remote mount to a local one should be allowed to cause regressions... / Jon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misc patches from the Debian systemd package
At Wednesday 16 July 2014 15:14:59 Jóhann B. Guðmundsson wrote: It should not come as a surprise to anyone given that Debian has such an diverse user base that there exist mass hacks in the distribution to please them all so filtering is needed/expected before things are being submitted upstream hence one would think they as in the Debian systemd team would have collaborated/communicated better amongst themselves before mass pushing downstream carried patches upstream so only the *relevant* upstream patches would be pushed. Perhaps next time ;) Well, I did filter out 30 Debian-specific hacks, and did gather feedback from several other team members over IRC before sending it, but obviously that didn't reach everyone... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misc patches from the Debian systemd package
On 07/16/2014 01:56 PM, Jon Severinsson wrote: Well, I did filter out 30 Debian-specific hacks, 40 downstream distribution specific hacks for just component in Debian ( and one init system ). It would be interesting to see how much added maintenance burdens takes place in the Debian community for the sake of choice. You dont happen to know if Debian collects that data do you? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 07/10] units: order remote-fs.target after local-fs.target
On Wed, Jul 16, 2014 at 03:56:27PM +0200, Jon Severinsson wrote: So the only thing it does is that it'll delay remote-fs.target if it were to be reached before local-fs.target. Which in my oppinion is a good thing, as writers of service files, as well as legacy init scripts, should rightfully be able to assume that if they request all remote file systems to be mounted, local file systems will be too. Also I would have a hard time explaining why a change of a remote mount to a local one should be allowed to cause regressions... local-fs.target is part of sysinit.target, so all normal units get it by default. Explicit relationships with local-fs.target are only necessary for special early-boot services, which have to carefully set all dependencies, so are out of scope here. Everything else should be fine. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 09/10] kmod-static-nodes: condition execution on kmod binary
On Wed, 16.07.14 12:09, Jon Severinsson (j...@severinsson.net) wrote: From: Michael Biebl bi...@debian.org Creating the list of dead device nodes requires kmod. Inside containers this is not strictly required so we don't want a hard dependency on the kmod package. If the binary does not exist kmod-static-nodes.service will fail, so add a condition to check if the binary is available. This appears unnecessary. The unit is conditionalized anyway on CAP_SYS_MODULE, which is something a container should never ever have. if you have a container that has CAP_SYS_MODULE, please consider simply dropping that flag instead of adding more conditions to this unit. Thanks, --- units/kmod-static-nodes.service.in | 1 + 1 file changed, 1 insertion(+) diff --git a/units/kmod-static-nodes.service.in b/units/kmod-static-nodes.service.in index 0934a87..076e316 100644 --- a/units/kmod-static-nodes.service.in +++ b/units/kmod-static-nodes.service.in @@ -11,6 +11,7 @@ DefaultDependencies=no Before=sysinit.target systemd-tmpfiles-setup-dev.service ConditionCapability=CAP_SYS_MODULE ConditionPathExists=/lib/modules/%v/modules.devname +ConditionFileIsExecutable=@KMOD@ [Service] Type=oneshot Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 08/10] units: make it possible to disable tmp.mount using systemctl
On Wed, 16.07.14 13:51, Jon Severinsson (j...@severinsson.net) wrote: tmp.mount is part of our default expected setup and should behave like this by default without any presets or configuration. Which is why I made `make install` enable it, which wasn't in the original patch for Debian. It can be overridden by an entry in fstab just fine. Why is that needed? To my knowledge you can not create an fstab entry that would make /tmp not be mounted at all but remain part of /. It can be done by masking the unit, but enable/disable seems more appropriate than unmask/mask. (Not that it matters, but actually you can. Just make it a bind mount on itself...) Note that when Debian tried to change the default from /tmp being part of / to being a tmpfs several applications broke and the default was eventually reverted. Most applications have probably been fixed since then, but even if we are able to change the default we will need a supported way of disabling it. I think for cases like this use systemctl mask... Note that Fedora has been shipping with tmpfs on /tmp for a while now. A few things broke, but they got fixed. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] conf parser: introduce milisecond parsing
On Wed, 16.07.14 16:28, Susant Sahani (sus...@redhat.com) wrote: On 07/16/2014 01:07 PM, Susant Sahani wrote: Add millisecord parsing support to conf parser. Immediate usage of this function is to parse bond options such as MIIMonitor, UpDelayMSec, DownDelayMSec which is represented in milli seconds. Dropped the idea. Please ignore the patch. Soem background, for the sake of the mailing list archives: Our generic parser implies seconds as units, but if another unit is specified it will honour that. The parsing code will always parse things as accuracte as 1us into a usec_t. This is documented in systemd.time(7). We also have a second parser, which has nanosecond granularity, since we cannot use the usual usec_t for that, but need to use nsec_t... Explicit parsers for the various other time units should not be necessary, the normal second-parser should be good enough. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logind error - Failed to abandon session scope: Connection reset
On Wed, 16.07.14 14:53, Roger Qiu (roger@polycademy.com) wrote: Hello everybody, I always receive this error: ``` |Jul 14 08:27:57 matrix-node systemd-logind[1339]: Failed to abandon session scope: Connection reset by peer| ``` When I shutdown a NixOS instance. Googling around didn't bring up any useful results. What does this error mean, and why does it happen. Here's the journald excerpt surrounding the error (reversed - top is most recent): You are shutting down the machine, at which point logind and dbus are both terminated. In your case dbus got terminated first, logind second, which is why logind got tripped up. It should be mostly a cosmetic issue, but I do wonder why this never happened for me... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: do not generate 'Wants' symlinks to generated service files that will be shadowed by a native unit.
On Wed, 16.07.14 11:57, Jon Severinsson (j...@severinsson.net) wrote:
I am a bit concerned about this, as we will never be able to find all
the units that PID 1 will find, for example because generated units are
not included in the client's search paths...
What's the precise issue that this fixes? Aren't there better fixes for
that? For example by ensuring that chkconfig always also runs systemctl
enable/disable and vice versa, so that it never happens that a unit
might be enabled by one, but not by the other?
---
src/sysv-generator/sysv-generator.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/src/sysv-generator/sysv-generator.c
b/src/sysv-generator/sysv-generator.c
index 5206279..aff5fd6 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -113,7 +113,26 @@ static int add_symlink(const char *service, const char
*where) {
return 1;
}
-static int generate_unit_file(SysvStub *s) {
+static int native_unit_exists(LookupPaths lp, char *name) {
+char **p;
+
+STRV_FOREACH(p, lp.unit_path) {
+struct stat st;
+_cleanup_free_ char *path = NULL;
+
+path = strjoin(*p, /, name, NULL);
+if (!path)
+return -ENOMEM;
+
+if (lstat(path, st) 0)
+continue;
+
+return 1;
+}
+return 0;
+}
+
+static int generate_unit_file(LookupPaths lp, SysvStub *s) {
char *unit;
char **p;
_cleanup_fclose_ FILE *f = NULL;
@@ -190,6 +209,12 @@ static int generate_unit_file(SysvStub *s) {
if (s-reload)
fprintf(f, ExecReload=%s reload\n, s-path);
+/* Do not generate 'Wants' symlinks to the generated service file if
it
+ * will be shadowed by an existing native unit, as the symlinks would
+ * not be shadowed but would pull the native unit instead. */
+if (native_unit_exists(lp, s-name))
+return 0;
+
STRV_FOREACH(p, s-wanted_by) {
r = add_symlink(s-name, *p);
if (r 0)
@@ -918,7 +943,7 @@ int main(int argc, char *argv[]) {
if (q 0)
continue;
-q = generate_unit_file(service);
+q = generate_unit_file(lp, service);
if (q 0)
continue;
}
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: do not generate 'Wants' symlinks to generated service files that will be shadowed by a native unit.
At Wednesday 16 July 2014 17:17:40 Lennart Poettering wrote: I am a bit concerned about this, as we will never be able to find all the units that PID 1 will find, for example because generated units are not included in the client's search paths... Right, but those cases have never been a problem for us, at least not yet... What's the precise issue that this fixes? Aren't there better fixes for that? For example by ensuring that chkconfig always also runs systemctl enable/disable and vice versa, so that it never happens that a unit might be enabled by one, but not by the other? We actually already do that, but I have yet to find a native service whose [Install] section exactly matches the Default-Start: field of the LSB header of the init script it is replacing... It gets even worse in Debian were we are forced to still support early boot init scripts (eg /etc/rcS.d/) that must run before basic.target, which are then replaced by native unit files on case-by-case basis, most of which are reworked to use DefaultDependencies=yes. Backwards compatibility is a bitch. While upstream systemd will not get the dependency cycle we do, in principle the problem is the same for any native service file shadowing a sysv init script. signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] smack: check smack cache after /sys mount
use_smack_cached is capability of smack. That is not changed on
runtime. So that should be a cache for performance. But the cache is
updated as wrong value(maybe 0) upon calling first mount_one. At this
time, until v210 /proc will be tried. After v211 /sys will be
tried. But both of first trial of mount_one /sys is NOT mounted
yet. Because even if the first trial is /sys, use_smack is called
before mount by label_mkdir. So the cache will always have 0.
To avoid, smack cache should be updated when only /sys is mounted
and smack cache is have initial value.
---
src/shared/smack-util.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/shared/smack-util.c b/src/shared/smack-util.c
index 8f83562..1887ab8 100644
--- a/src/shared/smack-util.c
+++ b/src/shared/smack-util.c
@@ -31,7 +31,8 @@ bool use_smack(void) {
#ifdef HAVE_SMACK
static int use_smack_cached = -1;
-if (use_smack_cached 0)
+if (use_smack_cached 0
+path_is_mount_point(/sys, false) 0)
use_smack_cached = access(/sys/fs/smackfs/, F_OK) = 0;
return use_smack_cached;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 08/10] units: make it possible to disable tmp.mount using systemctl
]] Lennart Poettering (Also I see little point in /tmp not being a tmpfs anyway. If you want a lot of space there, then use swap -- of which you can have up to 2G even on 32bit systems. tmpfs on on swap has the great benefit that it relieves the kernel from always having to utimately flush things to disk) Swap doesn't scale well, though. To the point where if the amount of swapped-out data is 2x physical memory, kswapd starts gobbling CPU. Yes, that's a bug that should be fixed, but it's been that way for years in Linux. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 05/10] rules: skip 99-systemd.rules when not running systemd as init
onsdagen den 16 juli 2014 16:49:55 skrev Lennart Poettering: On Wed, 16.07.14 12:09, Jon Severinsson (j...@severinsson.net) wrote: From: Tollef Fog Heen tfh...@err.no If you really want to support systems without systemd installed, then I'd recommend placing this rules file in the systemd pacakge, so that it is gone if you uninstall systemd. That said, nothing of what the file does is in any way something that could break things on non-systemd systems, hence the whole excercise sounds pointless... The file still contains one RUN+=@rootlibexecdir@/systemd-sysctl ..., which I don't think is desirable when systemd is installed but not running as PID 1 (which we also have to support). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 08/10] units: make it possible to disable tmp.mount using systemctl
On Wed, 2014-07-16 at 20:22 +0200, Tollef Fog Heen wrote: ]] Lennart Poettering (Also I see little point in /tmp not being a tmpfs anyway. If you want a lot of space there, then use swap -- of which you can have up to 2G even on 32bit systems. tmpfs on on swap has the great benefit that it relieves the kernel from always having to utimately flush things to disk) Swap doesn't scale well, though. To the point where if the amount of swapped-out data is 2x physical memory, kswapd starts gobbling CPU. Yes, that's a bug that should be fixed, but it's been that way for years in Linux. At least when I tested things a few years ago, tmpfs+swap seemed to have a more significant performance problem than CPU use. Apparently the kernel does not remember that the data is still on disk after it has been read back to RAM; where a normal fs would simply drop disk-backed data from RAM, tmpfs seems to do a new write each time. When the working set is large, this means every read from tmpfs requires an equally big write later. I tested something like writing a file 2x RAM size to tmpfs and reading it back several times. On a normal filesystem it's written to disk once and then read 10 times. With tmpfs the reads generate both read and write IO every time, and it's a lot slower. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] smack: check smack cache after /sys mount
On Thu, Jul 17, 2014 at 01:29:38AM +0900, WaLyong Cho wrote: use_smack_cached is capability of smack. That is not changed on runtime. So that should be a cache for performance. But the cache is updated as wrong value(maybe 0) upon calling first mount_one. At this time, until v210 /proc will be tried. After v211 /sys will be tried. But both of first trial of mount_one /sys is NOT mounted yet. Because even if the first trial is /sys, use_smack is called before mount by label_mkdir. So the cache will always have 0. To avoid, smack cache should be updated when only /sys is mounted and smack cache is have initial value. --- Is this still an issue after http://cgit.freedesktop.org/systemd/systemd/commit/?id=d1d8e5d49f? -if (use_smack_cached 0) +if (use_smack_cached 0 +path_is_mount_point(/sys, false) 0) use_smack_cached = access(/sys/fs/smackfs/, F_OK) = 0; Like it was said before, if this check is done at any point before it can return a valid result, *something* will be done wrong by systemd. So the only option is to fix it or delay all callers to always have a valid result. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add tool to query resolved
---
Useful? Maybe as a test binary?
Zbyszek
.gitignore | 1 +
Makefile.am | 10 ++
src/resolve-host/Makefile | 1 +
src/resolve-host/resolve-host.c | 277
4 files changed, 289 insertions(+)
create mode 12 src/resolve-host/Makefile
create mode 100644 src/resolve-host/resolve-host.c
diff --git a/.gitignore b/.gitignore
index eab1f4c322..fabc11 100644
--- a/.gitignore
+++ b/.gitignore
@@ -100,6 +100,7 @@
/systemd-remount-api-vfs
/systemd-remount-fs
/systemd-reply-password
+/systemd-resolve-host
/systemd-resolved
/systemd-rfkill
/systemd-run
diff --git a/Makefile.am b/Makefile.am
index 94cd402e71..1387e8cd53 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4697,6 +4697,16 @@ libnss_resolve_la_LIBADD = \
lib_LTLIBRARIES += \
libnss_resolve.la
+systemd_resolve_host_SOURCES = \
+ src/resolve-host/resolve-host.c
+
+systemd_resolve_host_LDADD = \
+ libsystemd-internal.la \
+ libsystemd-shared.la
+
+rootlibexec_PROGRAMS += \
+ systemd-resolve-host
+
endif
#
--
diff --git a/src/resolve-host/Makefile b/src/resolve-host/Makefile
new file mode 12
index 00..94aaae2c4d
--- /dev/null
+++ b/src/resolve-host/Makefile
@@ -0,0 +1 @@
+../../Makefile
\ No newline at end of file
diff --git a/src/resolve-host/resolve-host.c b/src/resolve-host/resolve-host.c
new file mode 100644
index 00..0ff87d46d9
--- /dev/null
+++ b/src/resolve-host/resolve-host.c
@@ -0,0 +1,277 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+ This file is part of systemd.
+
+ Copyright 2014 Zbigniew Jędrzejewski-Szmek
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include arpa/inet.h
+#include net/if.h
+#include getopt.h
+
+#include sd-bus.h
+#include bus-util.h
+#include bus-error.h
+#include bus-errors.h
+#include in-addr-util.h
+#include build.h
+
+#define DNS_CALL_TIMEOUT_USEC (45*USEC_PER_SEC)
+
+static const char* const protocol_family_table[PF_MAX] = {
+[0] = any,
+[PF_INET]= INET,
+[PF_INET6] = INET6,
+};
+
+DEFINE_PRIVATE_STRING_TABLE_LOOKUP(protocol_family, _unused_ int);
+
+static int arg_family = PF_UNSPEC;
+static unsigned arg_ifindex = 0;
+
+static int resolve_host(sd_bus *bus, const char *name, unsigned _family, int
_ifindex) {
+
+_cleanup_bus_message_unref_ sd_bus_message *req = NULL, *reply = NULL;
+_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+unsigned c = 0;
+int r;
+
+assert(name);
+
+log_debug(Resolving %s (family %s),
+ name, protocol_family_to_string(_family));
+
+r = sd_bus_message_new_method_call(
+bus,
+req,
+org.freedesktop.resolve1,
+/org/freedesktop/resolve1,
+org.freedesktop.resolve1.Manager,
+ResolveHostname);
+if (r 0) {
+log_error(sd_bus_message_new_method_call: %s, strerror(-r));
+return r;
+}
+
+r = sd_bus_message_set_auto_start(req, false);
+if (r 0) {
+log_error(sd_bus_message_set_auto_start: %s, strerror(-r));
+return r;
+}
+
+r = sd_bus_message_append(req, sy, name, AF_UNSPEC);
+if (r 0) {
+log_error(sd_bus_message_append: %s, strerror(-r));
+return r;
+}
+
+r = sd_bus_call(bus, req, DNS_CALL_TIMEOUT_USEC, error, reply);
+if (r 0) {
+log_error(%s: resolve call failed: %s, name,
bus_error_message(error, r));
+return r;
+}
+
+r = sd_bus_message_enter_container(reply, 'a', (yayi));
+if (r 0) {
+log_error(%s: failed to parse reply: %s, name,
bus_error_message(error, r));
+return r;
+}
+
+while ((r = sd_bus_message_enter_container(reply, 'r', yayi)) 0) {
+unsigned char family;
+const void *a;
+int ifindex;
+size_t sz;
+_cleanup_free_ char *pretty = NULL;
+char ifname[IF_NAMESIZE];
+
+
Re: [systemd-devel] [PATCH] Add tool to query resolved
For testing, if the nss module is installed but not configured, `getent --service=resolve ahosts google.com` might work... -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-socket-proxyd slapd
On Wed, Jul 16, 2014 at 7:29 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: This won't work, since proxyd now cannot connect to port 400. There is now a way to make that work with JoinsNamespaceOf= ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 08/10] units: make it possible to disable tmp.mount using systemctl
2014-07-16 16:59 GMT+02:00 Lennart Poettering lenn...@poettering.net: THis wouldn't work the way you might expect. RequiresMountsFor= I don't think we actually have a unit which has RequiresMountsFor=tmp.mount and if there was, I would consider that broken. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Socket activated SSHD service showing up as a failure when the client connection fails
Hello everybody, I recently discovered that when using a socket activated SSHD service on NixOS, it will show up as a failure on `sudo systemctl status` when the client fails the connection. The details are in this issue: https://github.com/NixOS/nixpkgs/issues/3279 Basically all I need to do is telnet to my VM and of course fail the protocol, then run `sudo systemctl status` on the VM, and see 1 extra failure. Is this correct behaviour for a service to be considered a failure just because the client fails the connection protocol? Thanks, Rger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 05/10] rules: skip 99-systemd.rules when not running systemd as init
在 2014年7月16日 星期三 20:45:56，Jon Severinsson 写道： The file still contains one RUN+=@rootlibexecdir@/systemd-sysctl ..., which I don't think is desirable when systemd is installed but not running as PID 1 (which we also have to support). support for the sake of support is a bad syndrom. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] smack: check smack cache after /sys mount
On 07/17/2014 04:40 AM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jul 17, 2014 at 01:29:38AM +0900, WaLyong Cho wrote: use_smack_cached is capability of smack. That is not changed on runtime. So that should be a cache for performance. But the cache is updated as wrong value(maybe 0) upon calling first mount_one. At this time, until v210 /proc will be tried. After v211 /sys will be tried. But both of first trial of mount_one /sys is NOT mounted yet. Because even if the first trial is /sys, use_smack is called before mount by label_mkdir. So the cache will always have 0. To avoid, smack cache should be updated when only /sys is mounted and smack cache is have initial value. --- Is this still an issue after http://cgit.freedesktop.org/systemd/systemd/commit/?id=d1d8e5d49f? I had used v210 with commit which you mentioned. But was not resolved. Today, I tried to check again and I found: http://cgit.freedesktop.org/systemd/systemd/commit/?id=c4bfd1691f4d3e26d6d7f34dbca941e119956e8a Sorry for my lack of inspection. Now it was cleared. Thanks for review. -if (use_smack_cached 0) +if (use_smack_cached 0 +path_is_mount_point(/sys, false) 0) use_smack_cached = access(/sys/fs/smackfs/, F_OK) = 0; Like it was said before, if this check is done at any point before it can return a valid result, *something* will be done wrong by systemd. So the only option is to fix it or delay all callers to always have a valid result. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket activated SSHD service showing up as a failure when the client connection fReply-To:
Hello, This is the log of the status codes: ``` ● sshd@3-10.0.2.15:22-10.0.2.2:51014.service - SSH Daemon (10.0.2.2:51014) Loaded: loaded (/nix/store/wr8r8jrj204q3i0v4vfav8m63ssnv8w1-unit/sshd@.service) Active: failed (Result: exit-code) since Thu 2014-07-17 02:24:01 UTC; 2min 21s ago Process: 3102 ExecStart=/nix/store/2wc50fcn54axkg2kk71jm2r5h0w5rbh6-openssh-6.6p1/sbin/sshd -i -f /nix/store/ai2a554az21b5zhd1kamcznbim4gd924-sshd_config (code=exited, status=255) Process: 3100 ExecStartPre=/nix/store/i5wnidc4707k3pgcbhyjq3qb4ajgyx5n-unit-script/bin/sshd@-pre-start (code=exited, status=0/SUCCESS) Main PID: 3102 (code=exited, status=255) Jul 17 02:23:55 matrix-node systemd[1]: Started SSH Daemon (10.0.2.2:51014). Jul 17 02:24:01 matrix-node systemd[1]: sshd@3-10.0.2.15:22-10.0.2.2:51014.service: main process exited, code=exited, status=255/n/a Jul 17 02:24:01 matrix-node systemd[1]: Unit sshd@3-10.0.2.15:22-10.0.2.2:51014.service entered failed state. ``` Perhaps it's 255? Thanks, Roger On 17/07/2014 12:51 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jul 17, 2014 at 12:40:59PM +1000, Roger Qiu wrote: Hello everybody, I recently discovered that when using a socket activated SSHD service on NixOS, it will show up as a failure on `sudo systemctl status` when the client fails the connection. The details are in this issue: https://github.com/NixOS/nixpkgs/issues/3279 Basically all I need to do is telnet to my VM and of course fail the protocol, then run `sudo systemctl status` on the VM, and see 1 extra failure. Is this correct behaviour for a service to be considered a failure just because the client fails the connection protocol? sshd chooses to exit with a failure code in this case. What we should really do is add SuccessExitStatus= setting to the sshd@.service and ignore that code. Is it some specific value? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket activated SSHD service showing up as a failure when the client connection fReply-To:
I've googled around and saw that 255 error code comes up a lot. But most resources talked about ssh not necessarily the sshd. If we ignore 255 code, is it possible we're also ignoring some other real errors, and not just the client failing the connection? Basically I would like sshd to report an error, if it is indeed an error from the host's side, not the client's side. On 17/07/2014 12:55 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jul 17, 2014 at 12:53:01PM +1000, Roger Qiu wrote: Hello, This is the log of the status codes: ``` ● sshd@3-10.0.2.15:22-10.0.2.2:51014.service - SSH Daemon (10.0.2.2:51014) Loaded: loaded (/nix/store/wr8r8jrj204q3i0v4vfav8m63ssnv8w1-unit/sshd@.service) Active: failed (Result: exit-code) since Thu 2014-07-17 02:24:01 UTC; 2min 21s ago Process: 3102 ExecStart=/nix/store/2wc50fcn54axkg2kk71jm2r5h0w5rbh6-openssh-6.6p1/sbin/sshd -i -f /nix/store/ai2a554az21b5zhd1kamcznbim4gd924-sshd_config (code=exited, status=255) Process: 3100 ExecStartPre=/nix/store/i5wnidc4707k3pgcbhyjq3qb4ajgyx5n-unit-script/bin/sshd@-pre-start (code=exited, status=0/SUCCESS) Main PID: 3102 (code=exited, status=255) Jul 17 02:23:55 matrix-node systemd[1]: Started SSH Daemon (10.0.2.2:51014). Jul 17 02:24:01 matrix-node systemd[1]: sshd@3-10.0.2.15:22-10.0.2.2:51014.service: main process exited, code=exited, status=255/n/a Jul 17 02:24:01 matrix-node systemd[1]: Unit sshd@3-10.0.2.15:22-10.0.2.2:51014.service entered failed state. ``` Perhaps it's 255? That looks like -1, but whatever. Does it work if you add SuccessExitStatus=255? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
