[systemd-devel] Regarding how to properly use zram on a systemd setup
Hello After reading: http://www.chromestory.com/2013/03/google-enabling-zram-for-chrome-os-by-default/ http://lwn.net/Articles/545244/ I was wondering what would be the best way to use zram on a setup running systemd. This is because I have found a lot of scripts, unit files... but I don't know what is the best approach (at least from an upstream point of view): http://mystilleef.blogspot.com.es/2011/10/enable-zram-in-fedora.html http://software.opensuse.org/package/systemd-zram-service https://aur.archlinux.org/packages/zramswap/ I found this thread: http://lists.freedesktop.org/archives/systemd-devel/2012-November/007444.html In that one Lennart suggest that maybe some action from util-linux maintainers could help but, after that message, I don't see anything newer (maybe we could report that suggestion to util-linux maintainers to other place... or maybe a better solution was found later :/) Thanks a lot for your help and suggestions ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Regarding how to properly use zram on a systemd setup
02.02.2014 17:23, Pacho Ramos wrote:
Hello
After reading:
http://www.chromestory.com/2013/03/google-enabling-zram-for-chrome-os-by-default/
http://lwn.net/Articles/545244/
I was wondering what would be the best way to use zram on a setup
running systemd. This is because I have found a lot of scripts, unit
files... but I don't know what is the best approach (at least from an
upstream point of view):
http://mystilleef.blogspot.com.es/2011/10/enable-zram-in-fedora.html
http://software.opensuse.org/package/systemd-zram-service
https://aur.archlinux.org/packages/zramswap/
I found this thread:
http://lists.freedesktop.org/archives/systemd-devel/2012-November/007444.html
In that one Lennart suggest that maybe some action from util-linux
maintainers could help but, after that message, I don't see anything
newer (maybe we could report that suggestion to util-linux maintainers
to other place... or maybe a better solution was found later :/)
Thanks a lot for your help and suggestions
Here is what I use. I don't claim this to be the best or even
officially-approved solution. But this is based on the existing Gentoo
documentation, found at
http://wiki.gentoo.org/wiki/Zram#Using_existing_tools :)
$ cat /etc/udev/rules.d/10-zram.rules
KERNEL==zram[0-9], SUBSYSTEM==block, DRIVER==, ACTION==add,
ATTR{disksize}==0, ATTR{disksize}=1536M, RUN+=/sbin/mkswap
$env{DEVNAME}
$ cat /etc/fstab
# /etc/fstab: static file system information.
snip irrelenavt lines
/dev/zram0 noneswappri=10,discard 0 0
/dev/zram1 noneswappri=10,discard 0 0
/dev/zram2 noneswappri=10,discard 0 0
/dev/zram3 noneswappri=10,discard 0 0
Note that discard is essential here (and not mentioned in the Gentoo
wiki) so that zram returns once-used compressed swap to the system.
$ cat /etc/modprobe.d/zram.conf
options zram num_devices=4
$ cat /etc/modules-load.d/zram.conf
zram
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
---
rules/60-persistent-storage.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/60-persistent-storage.rules
b/rules/60-persistent-storage.rules
index a4d009a..154ffd9 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -14,7 +14,7 @@ ACTION==add, SUBSYSTEM==module, KERNEL==block,
ATTR{parameters/events_dfl_
SUBSYSTEM!=block, GOTO=persistent_storage_end
# skip rules for inappropriate block devices
-KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*, GOTO=persistent_storage_end
+KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*,
GOTO=persistent_storage_end
# ignore partitions that span the entire disk
TEST==whole_disk, GOTO=persistent_storage_end
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
02.02.2014 19:29, Jóhann B. Guðmundsson wrote:
---
rules/60-persistent-storage.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/60-persistent-storage.rules
b/rules/60-persistent-storage.rules
index a4d009a..154ffd9 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -14,7 +14,7 @@ ACTION==add, SUBSYSTEM==module, KERNEL==block,
ATTR{parameters/events_dfl_
SUBSYSTEM!=block, GOTO=persistent_storage_end
# skip rules for inappropriate block devices
-KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*, GOTO=persistent_storage_end
+KERNEL==fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*,
GOTO=persistent_storage_end
# ignore partitions that span the entire disk
TEST==whole_disk, GOTO=persistent_storage_end
The patch is obviously harmless. However, I am not convinced that it is
needed, because in my setup (without this patch) there are no links in
/dev/disk pointing to any zram device. You can change my opinion by
providing configuration files that do result in such links being created
by systemd.
See
http://lists.freedesktop.org/archives/systemd-devel/2014-February/016614.html
for my configuration files.
offtopic
One patch that would be useful, however, is to make systemd say this
system cannot hibernate if all swap devices are zrams.
/offtopic
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
On 02/02/2014 01:39 PM, Alexander E. Patrakov wrote: The patch is obviously harmless. However, I am not convinced that it is needed, because in my setup (without this patch) there are no links in /dev/disk pointing to any zram device. You can change my opinion by providing configuration files that do result in such links being created by systemd. udev seems to have a race condition with swapon to see which can open /dev/zram0 first, causing swapon to fail. ( seems to be most noticeable on arm devices one out of every 7 times or something ) and this patches udev's persistent storage rules to avoid probing any zram devices. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
02.02.2014 20:18, Jóhann B. Guðmundsson wrote: On 02/02/2014 01:39 PM, Alexander E. Patrakov wrote: The patch is obviously harmless. However, I am not convinced that it is needed, because in my setup (without this patch) there are no links in /dev/disk pointing to any zram device. You can change my opinion by providing configuration files that do result in such links being created by systemd. udev seems to have a race condition with swapon to see which can open /dev/zram0 first, causing swapon to fail. ( seems to be most noticeable on arm devices one out of every 7 times or something ) and this patches udev's persistent storage rules to avoid probing any zram devices. Thanks, this explains why the patch is needed. But this should really be in the commit message :) -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
On 02/02/2014 02:27 PM, Alexander E. Patrakov wrote: 02.02.2014 20:18, Jóhann B. Guðmundsson wrote: On 02/02/2014 01:39 PM, Alexander E. Patrakov wrote: The patch is obviously harmless. However, I am not convinced that it is needed, because in my setup (without this patch) there are no links in /dev/disk pointing to any zram device. You can change my opinion by providing configuration files that do result in such links being created by systemd. udev seems to have a race condition with swapon to see which can open /dev/zram0 first, causing swapon to fail. ( seems to be most noticeable on arm devices one out of every 7 times or something ) and this patches udev's persistent storage rules to avoid probing any zram devices. Thanks, this explains why the patch is needed. But this should really be in the commit message :) Regarding the future of zram support in systemd should that not be added to fstab-generator and swap, with unit type ending in .zswap? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Add unit to arbitrary target.
On 01/29/14 16:51, Lennart Poettering wrote: On Wed, 29.01.14 10:53, dE (de.tec...@gmail.com) wrote: On enabling a unit, by default systemd will put it in a target which has been specified in by the unit itself. Is there any way by which I can make the unit start in any custom target? Manual linking or using systemctl? Manual linking is the only way to do this for now. There has been a TODO list item though to maybe introduce add-wants though, to implement something more high-level for this... Lennart Thanks everyone for the reply! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] make: test-ellipsize is a manual test
--- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 8bef21b..dd4e2dc 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1124,6 +1124,7 @@ manual_tests += \ test-cgroup \ test-install \ test-watchdog \ + test-ellipsize \ test-log tests += \ @@ -1136,7 +1137,6 @@ tests += \ test-unit-name \ test-unit-file \ test-utf8 \ - test-ellipsize \ test-util \ test-namespace \ test-date \ -- 1.8.5.2.297.g3e57c29 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] manager: use CMSG macros
---
src/core/manager.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index 634b141..74fb52d 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -1275,9 +1275,10 @@ static int manager_dispatch_notify_fd(sd_event_source
*source, int fd, uint32_t
};
union {
-struct cmsghdr cmsghdr;
+struct msghdr msghdr;
uint8_t buf[CMSG_SPACE(sizeof(struct ucred))];
} control = {};
+struct cmsghdr *cmsghdr;
struct msghdr msghdr = {
.msg_iov = iovec,
@@ -1285,7 +1286,7 @@ static int manager_dispatch_notify_fd(sd_event_source
*source, int fd, uint32_t
.msg_control = control,
.msg_controllen = sizeof(control),
};
-struct ucred *ucred;
+struct ucred *ucred = NULL;
Unit *u;
_cleanup_strv_free_ char **tags = NULL;
@@ -1300,15 +1301,27 @@ static int manager_dispatch_notify_fd(sd_event_source
*source, int fd, uint32_t
return -errno;
}
-if (msghdr.msg_controllen CMSG_LEN(sizeof(struct ucred)) ||
-control.cmsghdr.cmsg_level != SOL_SOCKET ||
-control.cmsghdr.cmsg_type != SCM_CREDENTIALS ||
-control.cmsghdr.cmsg_len != CMSG_LEN(sizeof(struct
ucred))) {
-log_warning(Received notify message without
credentials. Ignoring.);
+if (msghdr.msg_controllen CMSG_LEN(sizeof(struct cmsghdr))) {
+log_warning(sd_notify ancilliary message too short.);
continue;
}
-ucred = (struct ucred*) CMSG_DATA(control.cmsghdr);
+cmsghdr = CMSG_FIRSTHDR(control.msghdr);
+do {
+if (cmsghdr-cmsg_level == SOL_SOCKET
+cmsghdr-cmsg_type == SCM_CREDENTIALS
+cmsghdr-cmsg_len == CMSG_LEN(sizeof(struct
ucred)))
+ucred = (struct ucred*) CMSG_DATA(cmsghdr);
+else {
+log_warning(Unrecognized sd_notify ancilliary
message. Ignoring);
+continue;
+}
+} while ((cmsghdr = CMSG_NXTHDR(control.msghdr, cmsghdr)));
+
+if (!ucred) {
+log_warning(Received notify message without
credentials. Ignoring.);
+continue;
+}
u = hashmap_get(m-watch_pids, LONG_TO_PTR(ucred-pid));
if (!u) {
--
1.8.5.2.297.g3e57c29
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] Add SELinux support to systemd-nspawn
We would find this extremely useful. Our #1 long-term feature need is a containerization tool that supports both socket activation and selinux. libvirt-lxc has the former, but I'm seeing inconsistent documentation on the latter. I'd be glad to see systemd-nspawn get good support. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fix a typo
--- src/libsystemd/sd-bus/PORTING-DBUS1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1 b/src/libsystemd/sd-bus/PORTING-DBUS1 index 90d184b7..750033f 100644 --- a/src/libsystemd/sd-bus/PORTING-DBUS1 +++ b/src/libsystemd/sd-bus/PORTING-DBUS1 @@ -508,7 +508,7 @@ have attached. Note that when issuing the ioctl, you can select a different set of credentials to gather, than what was originally requested for being attached to incoming messages. -Credentials are always specific to the sender's domain that was +Credentials are always specific to the senders domain that was current at the time of sending, and of the process that opened the bus connection at the time of opening it. Note that this latter data is cached! -- 1.9.rc1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make: test-ellipsize is a manual test
Manual tests are those tests which cannot be run automatically. test-ellipsize simply doesn't do much, but it still makes sense to run it automatically, because the code paths get touched, asserts are checked, etc. It also makes a lot of sense to run it under valgrind. It should stay. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix a typo
On Sun, Feb 02, 2014 at 11:03:06PM +0100, Stefan Beller wrote: --- src/libsystemd/sd-bus/PORTING-DBUS1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1 b/src/libsystemd/sd-bus/PORTING-DBUS1 index 90d184b7..750033f 100644 --- a/src/libsystemd/sd-bus/PORTING-DBUS1 +++ b/src/libsystemd/sd-bus/PORTING-DBUS1 @@ -508,7 +508,7 @@ have attached. Note that when issuing the ioctl, you can select a different set of credentials to gather, than what was originally requested for being attached to incoming messages. -Credentials are always specific to the sender's domain that was +Credentials are always specific to the senders domain that was current at the time of sending, and of the process that opened the I'm not certain if the current version is gramatically correct, but the proposed version seems wrong: there's just one sender, so only singular form makes sense. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix a typo
On Sun, Feb 2, 2014 at 8:55 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I'm not certain if the current version is gramatically correct, but the proposed version seems wrong: there's just one sender, so only singular form makes sense. The current text makes more sense to me. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
