Re: [systemd-devel] [PATCH v2] Improving systemd-nspawn@.service (container dir/nonpersistant journal)
Hello Lennart,
Lennart Poettering [2014-11-21 0:36 +0100]:
So far we prefixed all variables parsed from command line arguments
with arg_, please follow the same scheme for this.
Ah, sure. Done.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From b743c4546148f61c855ea773e71a660c5dc9aa58 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Thu, 20 Nov 2014 14:30:52 +0100
Subject: [PATCH] nspawn: Add try-{host,guest} journal link modes
--link-journal={host,guest} fail if the host does not have persistent
journalling enabled and /var/log/journal/ does not exist. Even worse, as there
is no stdout/err any more, there is no error message to point that out.
Introduce two new modes try-host and try-guest which don't fail in this
case, and instead just silently skip the guest journal setup.
Change -j to mean try-guest instead of guest, and fix the wrong --help
output for it (it said host before).
Change systemd-nsp...@.service.in to use try-guest so that this unit works
with both persistent and non-persistent journals on the host without failing.
https://bugs.debian.org/770275
---
man/systemd-nspawn.xml | 11 ---
src/nspawn/nspawn.c | 37 +
units/systemd-nsp...@.service.in | 2 +-
3 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
index b3a2d32..75db65e 100644
--- a/man/systemd-nspawn.xml
+++ b/man/systemd-nspawn.xml
@@ -439,7 +439,9 @@
versa). Takes one of
literalno/literal,
literalhost/literal,
+literaltry-host/literal,
literalguest/literal,
+literaltry-guest/literal,
literalauto/literal. If
literalno/literal, the journal is
not linked. If literalhost/literal,
@@ -453,8 +455,11 @@
guest file system (beneath
filename/var/log/journal/replaceablemachine-id/replaceable/filename)
and the subdirectory is symlinked into the host
-at the same location. If
-literalauto/literal (the default),
+at the same location. literaltry-host/literal
+and literaltry-guest/literal do the same
+but do not fail if the host does not have
+persistant journalling enabled.
+If literalauto/literal (the default),
and the right subdirectory of
filename/var/log/journal/filename
exists, it will be bind mounted
@@ -473,7 +478,7 @@
termoption-j/option/term
listitemparaEquivalent to
-option--link-journal=guest/option./para/listitem
+option--link-journal=try-guest/option./para/listitem
/varlistentry
varlistentry
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index c2311b3..b4dcf39 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -124,6 +124,7 @@ static bool arg_private_network = false;
static bool arg_read_only = false;
static bool arg_boot = false;
static LinkJournal arg_link_journal = LINK_AUTO;
+static bool arg_link_journal_try = false;
static uint64_t arg_retain =
(1ULL CAP_CHOWN) |
(1ULL CAP_DAC_OVERRIDE) |
@@ -202,8 +203,9 @@ static void help(void) {
--capability=CAP In addition to the default, retain specified\n
capability\n
--drop-capability=CAP Drop the specified capability from the default set\n
---link-journal=MODELink up guest journal, one of no, auto, guest, host\n
- -jEquivalent to --link-journal=host\n
+--link-journal=MODELink up guest journal, one of no, auto, guest, host,\n
+ try-guest, try-host\n
+ -jEquivalent to --link-journal=try-guest\n
--read-onlyMount the root directory read-only\n
--bind=PATH[:PATH] Bind mount a file or directory from the host into\n
the container\n
@@ -428,6 +430,7 @@ static int parse_argv(int argc, char *argv[]) {
case 'j':
Re: [systemd-devel] [PATCH 2/4] util: add functions getting proc status, maps, limits, cgroup
On Thu, 2014-11-20 at 14:36 +0100, Lennart Poettering wrote:
On Wed, 19.11.14 11:01, Jakub Filak (jfi...@redhat.com) wrote:
---
src/shared/util.c| 13 +
src/shared/util.h| 4
src/test/test-util.c | 17 +
3 files changed, 34 insertions(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index 0166052..d62d90c 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -892,6 +892,19 @@ int get_process_root(pid_t pid, char **root) {
return get_process_link_contents(p, root);
}
+#define DEFINE_FN_GET_PROCESS_FULL_FILE(name) \
+int get_process_##name(pid_t pid, char **name) { \
+const char *p; \
+assert(pid = 0); \
+p = procfs_file_alloca(pid, #name); \
+return read_full_file(p, name, /*size*/NULL); \
+}
+
+DEFINE_FN_GET_PROCESS_FULL_FILE(status)
+DEFINE_FN_GET_PROCESS_FULL_FILE(maps)
+DEFINE_FN_GET_PROCESS_FULL_FILE(limits)
+DEFINE_FN_GET_PROCESS_FULL_FILE(cgroup)
+
Please use functions instead of macros wherever that works.
Maybe it is sufficient to just provide a single function for all four
cases that takes an extra argument for the file name to read?
Maybe:
int get_process_proc_file(pid_t pid, const char *filename, char **ret)
Or so? Given that the files in question are generally just read and
passed on as is without processing them any further I think it is Ok
to just provide a single bulk call that covers all four cases
instead of four individual ones.
Hope that makes sense?
It definitely make sense. I actually wanted to introduce
'get_process_proc_file()' function, but I didn't do that because
'procfs_file_alloca' is a macro and its last argument must be a string
literal, so I couldn't use the following construction:
p = procfs_file_alloca(pid, filename);
I forgot to mention this fact in the commit message.
New version will arrive soon.
Thanks for the review!
Jakub
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /usr vs /etc for default distro units enablement
Hello again! Didier Roche wrote on 18/11/14 15:40: Le 18/11/2014 15:59, Colin Guthrie a écrit : Hiya, Hey, Didier Roche wrote on 18/11/14 13:58: This would be maybe a nice way for the admin to know what's coming from a distribution default or not. However, let's say I want to ensure that ssh will always be available on my server, I would (even if it's in my server preset) then systemctl enable openssh, no matter whatever future preset updates does (like disable it in the next batch upgrade). For the avoidance of doubt, I believe that running systemctl preset should only ever happen on *first* install, never on upgrade or such like. This also avoids any problems here. (Of course if /etc is nuked, then reapplying the defaults from *.preset should be done!) See my Michael's answer (and my previous one) on the fact that maybe the preset files would be part of multiple packages (to disable certain units), and some being only part of packages not installed by default. Michael's case as well of a unit changing its target on a package upgrade (as a packaging fix, maybe) is valid as well. I think the distro-wide preset usage would be in a very core package that is likely installed very early on (perhaps even the package is required by the one that ships systemctl and thus has to be installed first). If you end up shipping random .preset files with the actual packages containing the units they affect (which isn't recommend as previously noted, but perhaps you still want to do it that way for some special cases) then this too will be fine. I can see some complications here but nothing that isn't manageable. With a shared distro/admin /etc, we have no way to take that fact into account and the next one would follow distro policy, right? Yeah, but that's assuming there *is* a next one. Once things are installed, the user should *not* be surprised by any action being taken without their consent on upgrade. FWIW, it's probably worth considering how you'd handle not changing users current preferences with regards to enabling/disabling things on upgrade. I can see this being quite hard for you roll out with your current suggestions, but you may have this covered already. Actually, this reminds me some issues we had with gconf in the past in changing distribution's default and deciphering what was users current preference or what was distro default behavior. Gnome-panel was copying its whole distro defaults in ~/.gconf. Adding/removing some default layouts and settings from the panel was then unnecessary difficult. Some changes was part of new default behaviors we wanted that the user never interacted with and was desired to be changed (because of some applets getting low maintenance, incompatible with newer technology or duplicates…) As everything was at the same place, it was difficult to know if the current value was set because of the previous default, or if the user explicitly tweaked and then selected it. I see the same issue with the shared /etc: is this unit enabled for that target because of one the preset config, or did the admin run systemctl enable unit explicitly and want to keep it? I think it's ok to change distro defaults on upgrade (will be potentially in major version upgrade of course), not user (admin here) preferences, of course. I would personally disagree with this statement that it's OK to change the distro defaults on upgrade. As an admin, whether I observe some behaviour but do not actively reinforce it (e.g. I see that installing httpd enables it by default and thus my server is working fine, so I don't need to do systemctl enable httpd manually) I now rely on the distro default. If that was to be changed on upgrade (whether package or whole distro), I'd personally be really annoyed! With the goal of being able to reset things (i.e. trashing /etc) if desired, the admin has a pretty good choice to start again with a clean slate after a distro upgrade if they so wish. Otherwise I'd very much expect my system to retain as much state as possible (whether that may have come from a preset or an active choice is, IMO, irrelevant - it's how the system was ultimately configured and what the admin now relies on) over the distro upgrade process. But we do have no way to know for sure which is which in the current system. Yeah, I accept this is a limitation of the current system. I guess I'm just making the argument that, IMO, this detail doesn't matter as I don't see the need to use this information for anything automated anyway. Also, after running systemctl enable opensshn, systemctl status openssh will still say enabled (preset) even if the admin wanted to stick it for good as it's part of the preset. Not sure what you mean by stick it for good here, but my previous suggestion was to say enabled [preset: enabled] or enabled [preset: disabled] accordingly which might be clearer (if a bit longer). Same than in previous case: I
Re: [systemd-devel] newer systemd for rhel7/centos7
Rahul Sundaram píše v Čt 20. 11. 2014 v 20:20 -0500: Hi On Thu, Nov 20, 2014 at 11:24 AM, Lukáš Nykrýn wrote: Hi, rhel7 / centos7 is shipped with heavily patched systemd 208, which does not contain new interesting features and for us it is a backporting nightmare. I have prepared an experimental repo with newer version of systemd for epel7. I don't mind doing that if the goal here is eventually rebase in RHEL/CentOS. If not, I won't be investing time on it Unfortunately this is not completely up to me. But personally I would like to see it in rhel/centos soon. Lukas Rahul ___ 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] newer systemd for rhel7/centos7
On Thu, Nov 20, 2014 at 9:10 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/20/2014 04:24 PM, Lukáš Nykrýn wrote: Hi, rhel7 / centos7 is shipped with heavily patched systemd 208, which does not contain new interesting features and for us it is a backporting nightmare. I have prepared an experimental repo with newer version of systemd for epel7. Currently it is based on 217 from Fedora rawhide and final goal should be 218. If you are interested, here is a COPR build. Feedback and bug reports are as always highly appreciated. https://copr.fedoraproject.org/coprs/lnykryn/systemd/ Lukas Wont you break your RHEL support if you run this? Is not EPEL applicable to CentOS as well? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] Improving systemd-nspawn@.service (container dir/nonpersistant journal)
On Fri, 21.11.14 09:49, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello Lennart, Lennart Poettering [2014-11-21 0:36 +0100]: So far we prefixed all variables parsed from command line arguments with arg_, please follow the same scheme for this. Ah, sure. Done. Thanks! Applied! 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] selinux-access: fix broken ternary operator
it seems to be a typo introduced by ebcf1f97de4f6b1580ae55eb56b1a3939fe6b602
-_r = selinux_access_check(_b, _m, _u-source_path
?:_u-fragment_path, (permission), _error); \
+({ Unit *_unit = (unit); selinux_generic_access_check(bus,message,
_unit-fragment_path ?: _unit-fragment_path, permission,error); })
---
src/core/selinux-access.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/selinux-access.h b/src/core/selinux-access.h
index bccf0d2..dd1e8bb 100644
--- a/src/core/selinux-access.h
+++ b/src/core/selinux-access.h
@@ -40,7 +40,7 @@ int mac_selinux_unit_access_check_strv(char **units,
sd_bus_message *message, Ma
#define mac_selinux_unit_access_check(unit, message, permission, error) \
({ \
Unit *_unit = (unit); \
-mac_selinux_generic_access_check((message),
_unit-fragment_path ?: _unit-fragment_path, (permission), (error)); \
+mac_selinux_generic_access_check((message), _unit-source_path
?: _unit-fragment_path, (permission), (error)); \
})
#else
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] networkd: disable tmpfiles and sysusers bits associated with networkd
On a system configured without networkd and sysusers there still needs to be the unnecessary systemd-network user, otherwise systemd-tmpfiles fails to start. Move information associated with networkd in tmpfiles.d and sysusers.d to separate files. Do not install it if netwrorkd is not enabled. --- Alternatively the files may be prepared to be processed with M4, which may be useful to conditionaly include lines for other optional services. Makefile.am | 10 ++ sysusers.d/systemd-networkd.conf | 8 sysusers.d/systemd.conf | 1 - tmpfiles.d/systemd-networkd.conf | 12 tmpfiles.d/systemd.conf | 3 --- 5 files changed, 30 insertions(+), 4 deletions(-) create mode 100644 sysusers.d/systemd-networkd.conf create mode 100644 tmpfiles.d/systemd-networkd.conf diff --git a/Makefile.am b/Makefile.am index 3f9f3fa..8f0f290 100644 --- a/Makefile.am +++ b/Makefile.am @@ -5164,6 +5164,16 @@ networkctl_LDADD = \ libsystemd-shared.la \ libsystemd-network.la +if ENABLE_TMPFILES +dist_tmpfiles_DATA += \ + tmpfiles.d/systemd-networkd.conf +endif + +if ENABLE_SYSUSERS +dist_sysusers_DATA += \ + sysusers.d/systemd-networkd.conf +endif + test_network_SOURCES = \ src/network/test-network.c diff --git a/sysusers.d/systemd-networkd.conf b/sysusers.d/systemd-networkd.conf new file mode 100644 index 000..208148d --- /dev/null +++ b/sysusers.d/systemd-networkd.conf @@ -0,0 +1,8 @@ +# This file is part of systemd. +# +# 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. + +u systemd-network - systemd Network Management diff --git a/sysusers.d/systemd.conf b/sysusers.d/systemd.conf index 95437b8..3da0901 100644 --- a/sysusers.d/systemd.conf +++ b/sysusers.d/systemd.conf @@ -7,6 +7,5 @@ g systemd-journal - - u systemd-bus-proxy - systemd Bus Proxy -u systemd-network - systemd Network Management u systemd-resolve - systemd Resolver u systemd-timesync - systemd Time Synchronization diff --git a/tmpfiles.d/systemd-networkd.conf b/tmpfiles.d/systemd-networkd.conf new file mode 100644 index 000..2419755 --- /dev/null +++ b/tmpfiles.d/systemd-networkd.conf @@ -0,0 +1,12 @@ +# This file is part of systemd. +# +# 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. + +# See tmpfiles.d(5) for details + +d /run/systemd/netif 0755 systemd-network systemd-network - +d /run/systemd/netif/links 0755 systemd-network systemd-network - +d /run/systemd/netif/leases 0755 systemd-network systemd-network - diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf index 9ca5ad2..57fc261 100644 --- a/tmpfiles.d/systemd.conf +++ b/tmpfiles.d/systemd.conf @@ -16,9 +16,6 @@ d /run/systemd/sessions 0755 root root - d /run/systemd/users 0755 root root - d /run/systemd/machines 0755 root root - d /run/systemd/shutdown 0755 root root - -d /run/systemd/netif 0755 systemd-network systemd-network - -d /run/systemd/netif/links 0755 systemd-network systemd-network - -d /run/systemd/netif/leases 0755 systemd-network systemd-network - d /run/log 0755 root root - -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] rpcbind: systemd socket activation
This is a re-post of Tom's patch he posted a while back. I made the following changes. * Reorganized the changes so the diff is more readable by using a goto instead of indenting 268 lines. * Removed the systemd scripts because they just didn't work and won't going to work. I did spend some time on them but debugging was not worth the time since the current ones worked. I'm more than willing to revisit this down the line. Finally I would like to thank Tom for all of his help! It was much appreciated! Tom Gundersen (1): rpcbind: add support for systemd socket activation Makefile.am | 6 + configure.ac | 10 src/rpcbind.c | 81 ++- 3 files changed, 91 insertions(+), 6 deletions(-) -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] newer systemd for rhel7/centos7
Hi On Fri, Nov 21, 2014 at 6:36 AM, Andrei Borzenkov wrote: On Thu, Nov 20, 2014 at 9:10 PM, Jóhann B. Guðmundsson wrote: Wont you break your RHEL support if you run this? Is not EPEL applicable to CentOS as well? It is a misconception that installing a package by itself would break any support contracts in the first place and one that has been corrected multiple times. In addition to that, EPEL is applicable to rebuilds of RHEL including but not limited to CentOS and Scientific Linux. It is also easy enough to spin a new instance of RHEL without activating the subscription for the purpose of testing as well. Rahul ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 1/4] use libmount to enumerate /proc/self/mountinfo
On Sat, Nov 15, 2014 at 02:09:26PM +0100, Tom Gundersen wrote: Usually we don't do this kind of fallback, but rather disable the relevant functionality if the lib is not available. In this case I guess it means making support for .mount units optional. I could imagine someone doing that in very specialised use cases, but maybe it makes more sense to make the library a hard dependency for now... OK, I was following the optional lead from libblkid and I guess thinking about non util-linux/libmount mount implementations (busybox?). But I see that util-linux is listed as a hard dependency anyway, so I'll remove the fallback code and send updated patches. - Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 4/4] add remote-fs dependencies if needed after change
On Sun, Nov 09, 2014 at 08:32:05AM +0300, Andrei Borzenkov wrote:
В Thu, 6 Nov 2014 21:11:03 -0800
Chris Leech cle...@redhat.com пишет:
This is an attempt to add it the remote-fs dependencies to a mount unit
if the options change, like when the utab options are picked up after
mountinfo has already been processed. It just adds the remote-fs
dependencies, leaving the local-fs ones in place.
With this change I always get mount units with proper remote-fs
dependencies when mounted with the _netdev option.
It it not working for -o remount,_netdev. But that looks like a
libmount issue in that the ROOT field is not being set in utab on a
remount, so if the initial mount did not require a utab entry then
remount options never get merge in properly in mnt_table_parse_mtab
---
src/core/mount.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/core/mount.c b/src/core/mount.c
index 7d77021..092a720 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1436,6 +1436,19 @@ static int mount_add_one(
}
}
+if (m-running_as == SYSTEMD_SYSTEM) {
+const char* target;
+
+target = mount_needs_network(options, fstype) ?
SPECIAL_REMOTE_FS_TARGET : NULL;
+/* _netdev option may have shown up late, or on a
+ * remount. Add remote-fs dependencies, even though
+ * local-fs ones may already be there */
+if (target) {
+unit_add_dependency_by_name(u,
UNIT_BEFORE, target, NULL, true);
+load_extras = true;
+}
+}
Should not it also add After on network.target to ensure it is
unmounted before network is down on shutdown? May be simply calling
mount_add_default_dependencies() would be appropriate here.
Setting load_extras to true causes mount_add_extras to be called further
down in this function, which calls mount_add_default_dependencies.
So in testing I did see the After get added as well. But if there's a
better way to clean up the mount unit adding code I'm all for it.
- Chris
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] too many rfkill services
В Fri, 21 Nov 2014 01:26:36 +0100 Lennart Poettering lenn...@poettering.net пишет: On Thu, 20.11.14 19:56, Lukasz Stelmach (stl...@poczta.fm) wrote: I talked to the kernel guys at my office and they told me that it is quite usual (at least for USB devices, and my wlan and bt are USB) that devices are stopped and unregistered in the kernel before a system is suspended end reported as completely new ones with increased numbers after machine resumes. So, I have now added some code that adds BindsTo= for the device unit to the service. It does not seem to work. bor@opensuse:~ systemctl status systemd-rfkill@rfkill0.service systemd-rfkill@rfkill0.service - Load/Save RF Kill Switch Status of rfkill0 Loaded: loaded (/usr/lib/systemd/system/systemd-rfkill@.service; static) Drop-In: /etc/systemd/system/systemd-rfkill@.service.d └─bind.conf Active: active (exited) since Пт 2014-11-21 06:52:40 MSK; 15h ago Docs: man:systemd-rfkill@.service(8) Process: 636 ExecStart=/usr/lib/systemd/systemd-rfkill load %I (code=exited, status=0/SUCCESS) Main PID: 636 (code=exited, status=0/SUCCESS) CGroup: /system.slice/system-systemd\x2drfkill.slice/systemd-rfkill@rfkill0.service bor@opensuse:~ systemctl --no-pager show -p BindsTo systemd-rfkill@rfkill0.service BindsTo=sys-subsystem-rfkill-devices-rfkill0.device bor@opensuse:~ systemctl status sys-subsystem-rfkill-devices-rfkill0.device sys-subsystem-rfkill-devices-rfkill0.device Loaded: loaded Active: inactive (dead) bor@opensuse:~ systemctl status sys-subsystem-rfkill-devices-rfkill1.device sys-subsystem-rfkill-devices-rfkill1.device Loaded: loaded Active: inactive (dead) bor@opensuse:~ systemctl status sys-subsystem-rfkill-devices-rfkill2.device sys-subsystem-rfkill-devices-rfkill2.device Loaded: loaded Active: inactive (dead) bor@opensuse:~ systemctl --full | grep rfkill sys-devices-pci:00-:00:1a.0-usb3-3\x2d2-3\x2d2.1-3\x2d2.1:1.0-bluetooth-hci0-rfkill2.device loaded active plugged /sys/devices/pci:00/:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/bluetooth/hci0/rfkill2 sys-devices-pci:00-:00:1c.1-:0c:00.0-ieee80211-phy0-rfkill1.device loaded active plugged /sys/devices/pci:00/:00:1c.1/:0c:00.0/ieee80211/phy0/rfkill1 systemd-rfkill@rfkill0.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill0 systemd-rfkill@rfkill1.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill1 systemd-rfkill@rfkill2.service loaded active exitedLoad/Save RF Kill Switch Status of rfkill2 system-systemd\x2drfkill.slice loaded active activesystem-systemd\x2drfkill.slice bor@opensuse:~ LC_ALL=C ll /sys/class/rfkill/ total 0 lrwxrwxrwx 1 root root 0 Nov 21 22:08 rfkill1 - ../../devices/pci:00/:00:1c.1/:0c:00.0/ieee80211/phy0/rfkill1 lrwxrwxrwx 1 root root 0 Nov 21 22:08 rfkill2 - ../../devices/pci:00/:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/bluetooth/hci0/rfkill2 This won't fix much though, as the service is likely to fail in ExecStop= because it cannot find the device anymore. Should not it be garbage collected at some point (assuming it is properly stopped that is)? For cases like this the tool is entirely useless I figure, since it can only save the rfkill state at shutdown now, but not on unplug. This means each time the device appears as hotplug we restore the state that was set during boot, but not the state from right before we went to suspend. I figure the only proper fix for this is to make some daemon take responsibility, listen to events and store things to disk each time the setting changes... Not too enthusiastic about adding that though... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] coredump: collect all /proc data useful for bug reporting
On Wed, 19.11.14 11:01, Jakub Filak (jfi...@redhat.com) wrote:
+/* Joins /proc/[pid]/fd/ and /proc/[pid]/fdinfo/ into the following lines:
+ *
+ * 0:/dev/pts/23
+ * pos:0
+ * flags: 012
+ * 1:/dev/pts/23
+ * pos:0
+ * flags: 012
+ * 2:/dev/pts/23
Hmm, I'd prefer a format here that is more easily reversible. For
example, adding an extra newline between the fdinfo items would be a
good start.
+ *
+ */
+static int compose_open_fds(pid_t pid, char **open_fds) {
+const char *fd_name = NULL, *fdinfo_name = NULL;
const? why?
+char *outcome = NULL;
+size_t len = 0, allocated = 0;
+char line[LINE_MAX];
+unsigned fd = 0;
+int r = 0;
+
+assert(pid = 0);
+
+fd_name = alloca(strlen(/proc//fd/) + DECIMAL_STR_MAX(pid_t) +
DECIMAL_STR_MAX(unsigned) + 1);
^^^
unsigned? an fd is an int!
+fdinfo_name = alloca(strlen(/proc//fdinfo/) +
DECIMAL_STR_MAX(pid_t) + DECIMAL_STR_MAX(unsigned) + 1);
same here.
The sizes you allocate here are fixed. I'd really prefer if you'd
allocate these as normal arrays instead of alloca(). alloca() is a
useful tool, but we should use it only when normal arrays aren't good
denough, but not otherwise.
Also note that alloca() cannot be mixed with function calls in the
same line. strlen() is a function call (though one that today's gcc
actually is smart enough to optimize away at compile time if you
invoke it on a literal string).
Hence, please use this instead:
char fd_name[sizeof(/proc/)-1 + DECIMAL_STR_MAX(pid_t) + sizeof(/fd/)-1 +
DECIMAL_STR_MAX(int) + 1];
+
+while (fd = 9) {
Oh no, this is not OK!
We shouldn't iterate though all thinkable fds, that's bad code. Please
iterate through /proc/$PID/fd/ and just operate on fds that are
actually there.
+_cleanup_free_ char *name = NULL;
+_cleanup_fclose_ FILE *fdinfo = NULL;
+
+sprintf((char *)fd_name, /proc/PID_FMT/fd/%u, pid, fd);
Hmm, first you declare the string as const, then you cast this away?
This is usually a good indication that something is really wrong...
+r = readlink_malloc(fd_name, name);
+if (r 0) {
+if (r == -ENOENT) {
+*open_fds = outcome;
+r = 0;
+}
+else
+free(outcome);
+
+break;
+}
+
+if (!GREEDY_REALLOC(outcome, allocated, len + strlen(name) +
DECIMAL_STR_MAX(unsigned) + 3))
+return -ENOMEM;
+
+len += sprintf(outcome + len, %u:%s\n, fd, name);
+++fd;
+
+sprintf((char *)fdinfo_name, /proc/PID_FMT/fdinfo/%u,
pid, fd);
+fdinfo = fopen(fdinfo_name, r);
+if (fdinfo == NULL)
+continue;
+
+while(fgets(line, sizeof(line), fdinfo) != NULL) {
+if (!GREEDY_REALLOC(outcome, allocated, len +
strlen(line) + 2))
+return -ENOMEM;
+
+len += sprintf(outcome + len, %s, line);
+if (strchr(line, '\n') == NULL) {
+outcome[len++] = '\n';
+outcome[len] = '\0';
+}
+}
I think using libc's open_memstream() and then simply writing to it
would be a *ton* prettier than this.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl list-dependencies: consider BindsTo as well?
Hello. Right now systemctl's command list-dependencies is considering parameters Wants and Requires only. But given that command's purpose I was wondering whether it wouldn't make sense to have it consider BindsTo as well. Regards, Peter Mattern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux-access: fix broken ternary operator
On Fri, 21.11.14 17:02, Lukas Nykryn (lnyk...@redhat.com) wrote:
it seems to be a typo introduced by ebcf1f97de4f6b1580ae55eb56b1a3939fe6b602
-_r = selinux_access_check(_b, _m, _u-source_path
?:_u-fragment_path, (permission), _error); \
+({ Unit *_unit = (unit); selinux_generic_access_check(bus,message,
_unit-fragment_path ?: _unit-fragment_path, permission,error); })
Looks good! Applied!
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: disable tmpfiles and sysusers bits associated with networkd
On Fri, 21.11.14 17:07, Łukasz Stelmach (l.stelm...@samsung.com) wrote: On a system configured without networkd and sysusers there still needs to be the unnecessary systemd-network user, otherwise systemd-tmpfiles fails to start. Move information associated with networkd in tmpfiles.d and sysusers.d to separate files. Do not install it if netwrorkd is not enabled. In principle looks OK, but I'd prefer if we would write this out with m4 (see etc.conf.m4) and keep it in the current files, rather than split this up in numerous files. Especially in the case of /run/systemd/netif this actually matters: if we split that out into its own tmpfiles snippet, then packagers would most likely put that in its own RPM/DEB if they split out those daemons. But this is not advisable in this case, as sd-network (which will eventually be a public API of libsystems) needs the directory to be around to install an inotify watch. If the directory doesn't exist, and the API is used it will fail entirely, which is suboptimal, given that networkd might be installed later on, and things should then just start to work. 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] nspawn: ignore EEXIST when mounting tmpfs
commit 79d80fc1466512d0ca211f4bfcd9de5f2f816a5a introduced a regression that
prevents mounting a tmpfs if the mount point already exits in the container's
root file system. This commit fixes the problem by ignoring EEXIST.
---
src/nspawn/nspawn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index b4dcf39..10a520c 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -828,7 +828,7 @@ static int mount_tmpfs(const char *dest) {
return log_oom();
r = mkdir_label(where, 0755);
-if (r 0) {
+if (r 0 errno != EEXIST) {
log_error(creating mount point for tmpfs %s failed:
%s, where, strerror(-r));
return r;
--
2.1.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
