Re: [systemd-devel] How to set primary slave in active-backup mode (bonding)
On Tue, 19 May 2015 18:12:15 +0200 Tom Gundersen t...@jklm.no wrote: On Thu, Apr 9, 2015 at 4:29 PM, Mikhail Morfikov mmorfi...@gmail.com wrote: I usually have two network interfaces on my laptops (one eth and one wlan), and when I was using sysvinit I also was configuring the bond interface via the /etc/network/interfaces file so the two interfaces could work in the active-backup mode. But now, they work in balance-rr mode which is set via the .netdev file. The problem with this mode is that when you have, let's say wifi 30mbit/s and wired 100mbit/s, you can get 60mbit/s max, and that's why I wanted to use the active-backup mode which switches from wire to wifi and vice versa depending on whether the ethernet cable is plugged in. Generally speaking, I have to set some additional parameters so this could work well, and that would be: We don't yet fully support all the bonding options. bond-primary eth1 This is not currently supported, I suppose we should add the possibility of marking a slave as 'primary' to the .network file (rather than listing the slave in the .netdev file). bond-primary-reselect always This is PrimaryReselectPolicy=always in the .netdev file. bond-slaves eth1 wlan0 This is achieved by setting Bond= in the .network files applied to eth1 and wlan0. bond-fail-over-mac none This is FailOverMACPolicy=none in the .netdev file, which is also the default, so is redundant. I'm not sure if all of them are necessary, and the question is how to pass these parameters in systemd? I'm asking because in the systemd.netdev manual, in the bond section, these options weren't specified. I hope the above helps, but I suspect you really need the feature to specify the primary slave for this to work as you intended. Happy to take a patch! Cheers, Tom Thank you for the information. pgpa9lyjdGv2A.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timers and Service Conditions
Hi, I was also able to reproduce the problem using a clean Fedora 22 Beta with systemd 219. Merten On 19/05/15 16:57, Lennart Poettering wrote: On Thu, 02.04.15 12:01, Merten Sach (mer...@tabinin.eu) wrote: Hi, I have a problem with a timer that trigges a service that has a condition set. The timer defines the following properties: [Timer] OnBootSec=1h OnUnitInactiveSec=1h Unit=autobackup@%i.service The service unit set the following condition: ConditionACPower=true When I'm now on AC power the service is never active and, therefor, the inactive timestamp is never set. This causes the timer to be triggered repeatedly which causes a very high system load. I want to keep the timer relative to bootup. So, can I avoid OnCalendar= ? Hmm, so I tried to reproduce this issue here, bu I couldn't. I used the same unit files as you propose, but this works cleanly, as the code already contains checks that if the triggered unit doesn't have an initialized inactive timestamp we'll fall back to the last trigger time of the unit. And if that's not set, we'll simply not set any timer... Hence, which version of systemd did you run this into with? Any chance you can check if you can reproduce this with current git or at least 219? Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]
On Wed, 20.05.15 22:40, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey Lennart, Lennart Poettering [2015-05-20 17:49 +0200]: Nope, ConditionSecurity=audit is only a simple boolean check that holds when audit is enabled at all. It doesn't tell you anything about the precise audit feature set of the kernel. Ah, thanks for the clarification. I have now conditionalized the unit on CAP_ADMIN_READ, which is the cap that you need to read the audit multicast stuff. You container manager hence should simply drop that cap fro, the cap set it passes and all should be good. Wonderful! Now it works perfectly in nspawn. (This needs to be fixed in unprivileged LXC containers, but that's not a systemd problem; I'll talk to LXC upstream about that). With these two fixes, should we now remove the scary warning in README? AFAICS there is no need to turn auditing off on the host any more. As mentioned before: unless you turn auditing off in the kernel, you cannot even log into any Fedora system running in a container (unless you have the seccomp trick on and are on x86-64). The message hence really should stay. Note that Debian/Ubuntu are not as restrictive regarding audit as Fedora is. In Fedora due to government craziness failing audit will result in refused logins, and that's the issue here. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fixed incorrect type for MTU
The parser uses size_t for MTU however the structure is defined with unsigned int as the target type resulting in a value corruption for the next field of the structure. dmoneil2 (1): Fixed issue with corruption of speed value when setting on x64 systems. src/udev/net/link-config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fixed incorrect type for MTU
---
src/udev/net/link-config.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/udev/net/link-config.h b/src/udev/net/link-config.h
index 34facde..8bb5b79 100644
--- a/src/udev/net/link-config.h
+++ b/src/udev/net/link-config.h
@@ -66,7 +66,7 @@ struct link_config {
NamePolicy *name_policy;
char *name;
char *alias;
-unsigned int mtu;
+size_t mtu;
unsigned int speed;
Duplex duplex;
WakeOnLan wol;
--
1.8.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fixed incorrect type for MTU
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432205671-30024-2-git-send-email-david.m.oneill%40intel.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, Apr 1, 2015, at 10:02 AM, Martin Pitt wrote: IMHO subvolumes, like hard disk partitions, are something that the administrator of a host should create deliberately only. Automatically created ones just create confusion about why the heck can't I remove that directory.. It's roughly equivalent of some random package messing with your partitions and/or fstab. So if we could somehow make this conditional on running on real iron, that would be a good compromise IMHO. I also agree with this. Having a special `btrfs rm -rf` (as is implemented now by systemd/src/shared/btrfs-util.c) copied into various projects is painful. There are a *lot* of tools that do packages in chroots that would all need to be taught this. I'll look at the seccomp approach, but the amount of pain versus gain here seems quite disproportionate right now. (OTOH, I want to use seccomp for RPM things in general, of which this is just one) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
Yes. It makes sence. Thanks, Alin -Original Message- From: Tom Gundersen [mailto:t...@jklm.no] Sent: Thursday, May 21, 2015 3:20 PM To: Rauta, Alin Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Belkind, Nadav Subject: Re: networkd: dbus API for networkd reconfiguration at run-time On Tue, May 19, 2015 at 10:40 AM, Rauta, Alin alin.ra...@intel.com wrote: Hi Lennart, Thanks for the answers. One more questions. Just a curiosity of mine. Currently, a user has to write scripts if he wants to save the run-time configuration in networkd format or to use a configuration management tool like chef for example. Even with the latter, the user still needs to write scripts. What about saving the run-time configuration in networkd format with networkctl maybe ? Something like networkctl save or networkctl save config with extensions to provide per port configuration saving, output directory for saved configuration and so on ... ? Not entirely sure I understand the question, but this is what I have in mind: we support three config sources at the moment: stuff in /lib which is shipped by packages, stuff in /etc that is provided by the admin and is persistent between reboots and stuff in /run which is lost on reboot. Our future API should have a switch allowing the config we apply to either be persistent (written out to /etc) or ephemeral (written out to /run), so that any config in networkd is backed by a config file somewhere. Does that make sense? Does it answer your question, or is there some other type of config you would like to write out? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: remove always true autoconf checks
On Tue, 19.05.15 20:17, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: All this checks are always true in any modernish linux system. --- configure.ac | 11 --- 1 file changed, 11 deletions(-) diff --git a/configure.ac b/configure.ac index 3efee22..cd6375b 100644 --- a/configure.ac +++ b/configure.ac @@ -1293,17 +1293,6 @@ AC_CHECK_HEADERS_ONCE([valgrind/memcheck.h valgrind/valgrind.h]) have_myhostname=no AC_ARG_ENABLE(myhostname, AS_HELP_STRING([--disable-myhostname], [disable nss-myhostname support])) if test x$enable_myhostname != xno; then -AC_HEADER_STDC -AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h netinet/in.h stdlib.h string.h sys/socket.h sys/time.h unistd.h nss.h sys/ioctl.h sys/auxv.h]) sys/auxv.h at least is a relatively recent addition to glibc, hence simply removing this all appears too broad... Not sure however why this is in the enable_myhostname part however, it should just be moved up. Could you prep a patch that does that? - -AC_C_CONST -AC_TYPE_SIZE_T -AC_HEADER_TIME - -AC_FUNC_MALLOC -AC_FUNC_SELECT_ARGTYPES -AC_CHECK_FUNCS([gethostbyaddr gethostbyname gettimeofday inet_ntoa memset select socket strcspn strdup strerror strncasecmp strcasecmp strspn]) - have_myhostname=yes fi AM_CONDITIONAL(HAVE_MYHOSTNAME, [test $have_myhostname = yes]) -- 2.4.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel 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] swap: use swapon -o
On Wed, 20.05.15 17:54, Karel Zak (k...@redhat.com) wrote:
This patch simplify swapon usage in systemd. The command swapon(8)
since util-linux v2.26 supports -o list. The idea is exactly the
same like for mount(8). The -o specifies options in fstab-compatible
way. For systemd it means that it does not have to care about things
like discard or another swapon specific options.
I figure the README should be updated as part of the patch to require
util-linux 2.26 then.
static void swap_enter_activating(Swap *s) {
-_cleanup_free_ char *discard = NULL;
-int r, priority = -1;
+_cleanup_free_ char *opts = NULL;
+int r;
assert(s);
@@ -726,13 +726,19 @@ static void swap_enter_activating(Swap *s) {
s-control_command = s-exec_command + SWAP_EXEC_ACTIVATE;
if (s-from_fragment) {
-fstab_filter_options(s-parameters_fragment.options,
discard\0, NULL, discard, NULL);
+int priority = -1;
+
+r = fstab_find_pri(s-parameters_fragment.options,
priority);
+if (r 0)
+log_notice_errno(r, Failed to parse swap
priority \%s\, ignoring: %m, s-parameters_fragment.options);
So far we logged such non-fatal errors as LOG_WARNING. Could you
upgrade this from log_notice_errno() to log_warning_errno() please?
(I am aware the the previous code used LOG_NOTICE, but this should be
fixed I think)
-priority = s-parameters_fragment.priority;
-if (priority 0) {
-r = fstab_find_pri(s-parameters_fragment.options,
priority);
+if (r = 0 s-parameters_fragment.priority = 0) {
+if (s-parameters_fragment.options)
+r = asprintf(opts, %s,pri=%i,
s-parameters_fragment.options, s-parameters_fragment.priority);
+else
+r = asprintf(opts, pri=%i,
s-parameters_fragment.priority);
if (r 0)
-log_notice_errno(r, Failed to
-parse swap priority \%s\, ignoring: %m,
-s-parameters_fragment.options);
+goto fail;
}
I think it might be a good idea to log a warning if the priority is
specified both in s-parameters_frament.priority and in
s-parameters_fragment.options.
Otherwise looks good!
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] networkd: fix systemd-networkd-wait-online with multiple NICs
On Wed, May 20, 2015 at 8:05 PM, Michael Marineau michael.marin...@coreos.com wrote: I haven't retested HEAD yet but up through 219 it would report 'no-carrier configuring' which seems bogus since it shouldn't be configuring an interface in such a state no-carrier configuring could easily happen as we would enslave a device and add routes/addresses even before the device gains a carrier. and there is no .network config to apply to the interface either. Now this is strange. A link should never be in configuring state unless we actually have a .network file to apply to it. We have seen similar looking networkctl output for physical interfaces too but since several different states get squashed into 'configuring' I'm not sure if it is the same situation, it was just easier to demo with a .netdev and bridge. Interestingly no other mechanism for creating a bridge (ip or brctl) got it into the same state but I'm not sure why. Not sure to be honest, I'll try to keep an eye on this, but as I said I have not been able to reproduce. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
On Tue, May 19, 2015 at 10:40 AM, Rauta, Alin alin.ra...@intel.com wrote: Hi Lennart, Thanks for the answers. One more questions. Just a curiosity of mine. Currently, a user has to write scripts if he wants to save the run-time configuration in networkd format or to use a configuration management tool like chef for example. Even with the latter, the user still needs to write scripts. What about saving the run-time configuration in networkd format with networkctl maybe ? Something like networkctl save or networkctl save config with extensions to provide per port configuration saving, output directory for saved configuration and so on ... ? Not entirely sure I understand the question, but this is what I have in mind: we support three config sources at the moment: stuff in /lib which is shipped by packages, stuff in /etc that is provided by the admin and is persistent between reboots and stuff in /run which is lost on reboot. Our future API should have a switch allowing the config we apply to either be persistent (written out to /etc) or ephemeral (written out to /run), so that any config in networkd is backed by a config file somewhere. Does that make sense? Does it answer your question, or is there some other type of config you would like to write out? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fixed incorrect type for MTU
On Thu, May 21, 2015 at 12:54 PM, dmoneil2 david.m.one...@intel.com wrote: The parser uses size_t for MTU however the structure is defined with unsigned int as the target type resulting in a value corruption for the next field of the structure. dmoneil2 (1): Fixed issue with corruption of speed value when setting on x64 systems. src/udev/net/link-config.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks for the patch! I now pushed a similar fix, please verify that it works for you. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd v220
Heya, Many many bugfixes, and a good number of new features: http://www.freedesktop.org/software/systemd/systemd-220.tar.xz CHANGES WITH 220: * The gudev library has been extracted into a separate repository available at: https://git.gnome.org/browse/libgudev/ It is now managed as part of the Gnome project. Distributions are recommended to pass --disable-gudev to systemd and use gudev from the Gnome project instead. gudev is still included in systemd, for now. It will be removed soon, though. Please also see the announcement-thread on systemd-devel: http://lists.freedesktop.org/archives/systemd-devel/2015-May/032070.html * systemd now exposes a CPUUsageNSec= property for each service unit on the bus, that contains the overall consumed CPU time of a service (the sum of what each process of the service consumed). This value is only available if CPUAccounting= is turned on for a service, and is then shown in the systemctl status output. * Support for configuring alternative mappings of the old SysV runlevels to systemd targets has been removed. They are now hardcoded in a way that runlevels 2, 3, 4 all map to multi-user.target and 5 to graphical.target (which previously was already the default behaviour). * The auto-mounter logic gained support for mount point expiry, using a new TimeoutIdleSec= setting in .automount units. (Also available as x-systemd.idle-timeout= in /etc/fstab). * The EFI System Partition (ESP) as mounted to /boot by systemd-efi-boot-generator will now be unmounted automatically after 2 minutes of not being used. This should minimize the risk of ESP corruptions. * New /etc/fstab options x-systemd.requires= and x-systemd.requires-mounts-for= are now supported to express additional dependencies for mounts. This is useful for journalling file systems that support external journal devices or overlay file systems that require underlying file systems to be mounted. * systemd does not support direct live-upgrades (via systemctl daemon-reexec) from versions older than v44 anymore. As no distribution we are aware of shipped such old versions in a stable release this should not be problematic. * When systemd forks off a new per-connection service instance it will now set the $REMOTE_ADDR environment variable to the remote IP address, and $REMOTE_PORT environment variable to the remote IP port. This behaviour is similar to the corresponding environment variables defined by CGI. * systemd-networkd gained support for uplink failure detection. The BindCarrier= option allows binding interface configuration dynamically to the link sense of other interfaces. This is useful to achieve behaviour like in network switches. * systemd-networkd gained support for configuring the DHCP client identifier to use when requesting leases. * systemd-networkd now has a per-network UseNTP= option to configure whether NTP server information acquired via DHCP is passed on to services like systemd-timesyncd. * systemd-networkd gained support for vti6 tunnels. * Note that systemd-networkd manages the sysctl variable /proc/sys/net/ipv[46]/conf/*/forwarding for each interface it is configured for since v219. The variable controls IP forwarding, and is a per-interface alternative to the global /proc/sys/net/ipv[46]/ip_forward. This setting is configurable in the IPForward= option, which defaults to no. This means if networkd is used for an interface it is no longer sufficient to set the global sysctl option to turn on IP forwarding! Instead, the .network file option IPForward= needs to be turned on! Note that the implementation of this behaviour was broken in v219 and has been fixed in v220. * Many bonding and vxlan options are now configurable in systemd-networkd. * systemd-nspawn gained a new --property= setting to set unit properties for the container scope. This is useful for setting resource parameters (e.g CPUShares=500) on containers started from the command line. * systemd-nspawn gained a new --private-users= switch to make use of user namespacing available on recent Linux kernels. * systemd-nspawn may now be called as part of a shell pipeline in which case the pipes used for stdin and stdout are passed directly to the process invoked in the container, without indirection via a pseudo
Re: [systemd-devel] [PATCH] swap: use swapon -o
On Thu, 21.05.15 18:02, Karel Zak (k...@redhat.com) wrote: On Thu, May 21, 2015 at 04:45:44PM +0200, Lennart Poettering wrote: I think it might be a good idea to log a warning if the priority is specified both in s-parameters_frament.priority and in s-parameters_fragment.options. This (priority specified by both fields) is standard fstab-generator behaviour. Maybe the generator should be also updated to stop generate Priority:. Yeah, I agree. It should pass the option string as is, given that we can do so now, and not parse it in any way and generate secondary fields from it. 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] buildsys: remove always true autoconf checks
On Thu, May 21, 2015 at 11:39 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 19.05.15 20:17, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: All this checks are always true in any modernish linux system. --- configure.ac | 11 --- 1 file changed, 11 deletions(-) diff --git a/configure.ac b/configure.ac index 3efee22..cd6375b 100644 --- a/configure.ac +++ b/configure.ac @@ -1293,17 +1293,6 @@ AC_CHECK_HEADERS_ONCE([valgrind/memcheck.h valgrind/valgrind.h]) have_myhostname=no AC_ARG_ENABLE(myhostname, AS_HELP_STRING([--disable-myhostname], [disable nss-myhostname support])) if test x$enable_myhostname != xno; then -AC_HEADER_STDC -AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h netinet/in.h stdlib.h string.h sys/socket.h sys/time.h unistd.h nss.h sys/ioctl.h sys/auxv.h]) sys/auxv.h at least is a relatively recent addition to glibc, hence simply removing this all appears too broad... Right.. that's an oversight.. Not sure however why this is in the enable_myhostname part however, it should just be moved up. Could you prep a patch that does that? Sure.. stay tuned ;) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem when m-finish_timestamp is set before running manager_loop
On Wed, 20.05.15 11:16, cee1 (fykc...@gmail.com) wrote: 2015-05-20 1:27 GMT+08:00 Lennart Poettering lenn...@poettering.net: Hmm, can you provide a backtrace of the call chain when this happens, please? The call chain is: 0xb6df1acc manager_check_finished+308: 0xe1a07000 0xb6e9f744 job_finish_and_invalidate+936: 0xe3a0 0xb6df4bb0 transaction_activate+3540: 0xe59a0004 0xb6ded8e8 manager_add_job+364: 0xe2509000 0xb6de6080 main+8896: 0xe371 Should be fixed in git. Please verify! 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] audit: Fix journal failing on unsupported audit in containers [was: journal: don't complain about audit socket errors in a container.]
Quoting Lennart Poettering (lenn...@poettering.net): On Wed, 20.05.15 22:40, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey Lennart, Lennart Poettering [2015-05-20 17:49 +0200]: Nope, ConditionSecurity=audit is only a simple boolean check that holds when audit is enabled at all. It doesn't tell you anything about the precise audit feature set of the kernel. Ah, thanks for the clarification. I have now conditionalized the unit on CAP_ADMIN_READ, which is the cap that you need to read the audit multicast stuff. You container manager hence should simply drop that cap fro, the cap set it passes and all should be good. I want to clarify this point. Dropping CAP_ADMIN_READ from the bounding set means dropping it from the capabilities targeted at your own user namespace. The only check in the kernel for CAP_ADMIN_READ currently is against the initial user namespace. One day of course (maybe soon) this may change so that you only need CAP_ADMIN_READ against your own user_ns. Following the above, container managers could then again keep CAP_ADMIN_READ in the bounding set. But I'm claiming that checking for CAP_ADMIN_READ in your bounding set is the wrong check here. It simply has nothing to do with what you actually want to be able to do. One could argue that the right answer is a new kernel facility to check for caps against init_user_ns, but no that will have the same problem after audit ns becomes possible. I think the right check for systemd to perform to check whether this is allowed is to actuallly try the bind(). That will return the right answer both now and when namespaced audit is possible, without taking a probably-wrong unrelated cue from the container manager. It's not earth-shatteringly important and what you've got is workable, but I think it may set a better precedent to do it the other way. -serge (One might almost think that we should have a new kernel facility to answer questions such questions. CAP_MAC_ADMIN is similar.) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] swap: use swapon -o
On Thu, May 21, 2015 at 04:45:44PM +0200, Lennart Poettering wrote: I think it might be a good idea to log a warning if the priority is specified both in s-parameters_frament.priority and in s-parameters_fragment.options. This (priority specified by both fields) is standard fstab-generator behaviour. Maybe the generator should be also updated to stop generate Priority:. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 05/21/2015 03:19 PM, Colin Walters wrote: On Wed, Apr 1, 2015, at 10:02 AM, Martin Pitt wrote: IMHO subvolumes, like hard disk partitions, are something that the administrator of a host should create deliberately only. Automatically created ones just create confusion about why the heck can't I remove that directory.. It's roughly equivalent of some random package messing with your partitions and/or fstab. So if we could somehow make this conditional on running on real iron, that would be a good compromise IMHO. I also agree with this. Real or not makes no difference systemd should not be creating subvolumes et all or atleast there should be a system wide option to disable it altogether and that option should be disabled by default upstream. This breaks btrfs setup/administrations on host, breaks tools etc. so perhaps just best to get a second opinion with upstream btrfs community and get their opinion of having core/base component creating subvolumes on their own is the *smart* thing to do and see if their words are enough to change Lennart's mind about this. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
