Re: [systemd-devel] [PATCH] rules: Fix by-path of mmc RPMB partitions and don't blkid them
Kay Sievers [2015-02-13 10:12 +0100]:
This looks awful. We should not litter generic rules with exotic niche
use cases like this. It will end up in a mess.
Fully agreed :/
First, what is the use-case for by-path for mmc devices? If there is
no strong one, which I suspect, please just remove these rules again.
At least with the current blacklist approach, this is the important
bit:
| -ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*,
SYMLINK+=disk/by-path/$env{ID_PATH}
| +ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, KERNEL!=mmcblk[0-9]*rpmb,
SYMLINK+=disk/by-path/$env{ID_PATH}
i. e. this fixes /dev/disks/by-path/mumble sometimes pointing to
/dev/mmcblk0 (correct) and sometimes pointing to /dev/mmcblk0rpmb
(awfully wrong)
| +ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, KERNEL==mmcblk[0-9]*rpmb,
SYMLINK+=disk/by-path/$env{ID_PATH}-rpmb
This was more or less for completeness. I honestly don't know what to
do with these devices, I'm happy if we drop that rule again.
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] Suspend from wireless keyboard not working
On Fri, 13.02.15 00:46, Gustavo De Nardin (spuk) (gustav...@gmail.com) wrote:
Hello.
I'm trying to make my notebook (Lenovo Thinkpad X230) suspend when pressing
the sleep extra key on a wireless keyboard (Logitech K270 using the
Logitech unifying receiver).
I've been able to map the sleep key to the 'pauseplay' action in a
'/etc/udev/hwdb.d/70-keyboard.hwdb' file, for testing, and it works (as
pause/play, of course), but when I map it to 'suspend', nothing happens.
Pressing the suspend key on the notebook's own keyboard works as expected
(out of the box, no messing from my part).
I'm running Arch Linux, systemd-218-1, no desktop environment, just
WindowMaker. /etc/logind.conf has HandleSuspendKey on default
('#HandleSuspendKey=suspend').
I also just learned from /usr/share/doc/systemd/NEWS that since v210 logind
won't suspend when the notebook has the lid closed and is on a docking
station, which is my case. But even testing with lid open and out of the
dock, it won't suspend from the wireless keyboard.
What else would be needed? Where/what should I look for?
logind only listens to keypresses of keyboards that carry the udev tag
power-switch. It will ignore all others. By default only the buttons
from ACPI devices and certain special laptop input drivers are marked
like that.
I'd like to open this up for all keyboards by default, but I don't
want to do that unless we can get patches into the kernel that allow
us to suppress wakeups for any key events but the ones we really care
about.
David Herrmann has been posting patches about this, but so far that
lead to very little:
http://markmail.org/message/3omuwwapmfnrwit5#query:+page:1+mid:5v54axmwgteur67z+state:results
As a local fix to make this work for you you can write a udev rule
that adds the power-switch tag to your keyboard.
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] rules: Fix by-path of mmc RPMB partitions and don't blkid them
On Fri, Feb 13, 2015 at 10:35 AM, Martin Pitt martin.p...@ubuntu.com wrote:
Kay Sievers [2015-02-13 10:12 +0100]:
This looks awful. We should not litter generic rules with exotic niche
use cases like this. It will end up in a mess.
Fully agreed :/
First, what is the use-case for by-path for mmc devices? If there is
no strong one, which I suspect, please just remove these rules again.
At least with the current blacklist approach, this is the important
bit:
| -ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*,
SYMLINK+=disk/by-path/$env{ID_PATH}
| +ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, KERNEL!=mmcblk[0-9]*rpmb,
SYMLINK+=disk/by-path/$env{ID_PATH}
i. e. this fixes /dev/disks/by-path/mumble sometimes pointing to
/dev/mmcblk0 (correct) and sometimes pointing to /dev/mmcblk0rpmb
(awfully wrong)
Sure, as long as we have the blacklist and not a whitelist, we can add
the rpmb devices to the current list at the top of the file.
| +ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, KERNEL==mmcblk[0-9]*rpmb,
SYMLINK+=disk/by-path/$env{ID_PATH}-rpmb
This was more or less for completeness. I honestly don't know what to
do with these devices, I'm happy if we drop that rule again.
Let's remove it. There was never a reason for by-path/ to cover all
exotic device types. disk/by-path/ is for slots, chassis, ports where
swappable disks can be connected and disconnected without the
identifier to change. I doubt that applies to mmc devices.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] config_parse_exec_mount_flags: get rid of unnecessary copy
Dnia środa, 11 lutego 2015 13:08:26 Lennart Poettering pisze: This optimization is not valid. If 'word' is set to sh, then l will be 2, and strneq(word, shared, 2) is true, but we don't actually want to allow such abbreviations! Lennart True, I can use strlen(shared ) then as a n value in strneq. Or please at least change that: -else if (streq(word, private)) + else if (streq(t, private)) regards, -- Maciej Wereski Samsung RD Institute Poland Samsung Electronics m.were...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus in d-bus project
Dnia czwartek, 12 lutego 2015 18:28:45 Steven Noonan pisze: Hi all, Hello, Is anyone maintaining a patch series against upstream d-bus for kdbus integration? I checked the kdbus-dev branch linked to by the kdbus Google Code page: https://review.tizen.org/git/?p=platform/upstream/dbus.git;a=shortlog;h=refs /heads/kdbus-dev But it hasn't been updated in over a year, and in that time kdbus has changed almost completely (i.e. now is kdbusfs...). As you stated kdbus has changed quite fast. That's the main reason why kdbus support development in libdbus was halted. Now, when kdbus is stabilizing we plan to restart the efforts with libdbus. Kdbus in glib is more mature, if you'd like to see it, you'll find it in official repo: https://git.gnome.org/browse/glib/log/?h=wip/kdbus-junk We will discuss it with dbus upstream. cheers, -- Maciej Wereski Samsung RD Institute Poland Samsung Electronics m.were...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier
Hi Tom,
Any news on this ?
Best Regards,
Alin
-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Wednesday, February 11, 2015 6:03 PM
To: Rauta, Alin
Cc: zbys...@in.waw.pl; t...@jklm.no; systemd-devel@lists.freedesktop.org;
Kinsella, Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using
BindCarrier
On Wed, 11.02.15 17:44, Rauta, Alin (alin.ra...@intel.com) wrote:
Hi Lennart,
+_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIERS, ifindex, ret); }
+
I think it would be better to have two calls here:
int sd_network_link_get_carrier_bound_to(int ifindex, int **others);
int sd_network_link_get_carrier_bound_by(int ifindex, int
**others);
In terms of functionality, sd_network_link_get_carriers is
actually sd_network_link_get_carrier_bound_to and is applicable to
bound to links just like BindCarrier= is available only for bound
to links. I wanted to save to systemd run files just minimum info.
If I add sd_network_link_get_carrier_bound_by, then each time
link_save is called for a link I should query BindCarrier=s for
all interfaces to print each link that bounds the current interface.
Then, if I rename a link I should call link_save for all available
links because the BindCarrier= can be interpreted in another way due
to wildcards.
Well, one option could be to keep a set of bound_by and bound_to links around
for each link, and then just update that each time an interface comes, goes, or
changes names. That way you always have direct access to the bound links, and
don't have to resolve the globs each time you need them, but only when they
actually change?
The reason why I figured having two calls for this would be useful is simply to
make it easy to write tools like networkctl, which wants to show this
information in both directions for each interface...
+/* get the links that are bound to this port. */ static int
+get_downlinks(const char *name,
+ sd_rtnl_message *m,
+ LinkInfo **downlinks,
+ int *down_count) {
Regarding get_uplinks and get_downlinks I can rename them to
get_links_bound_to and get_links_bound_by. Would this be fine ?
Sure!
But before you rework any of this, let's see what Tom has to say, he's the
networkd maintainer...
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] systemd-networkd mysteriously shutting down after launch
On Thu, 12.02.15 22:30, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: On Thu, 2015-02-12 at 20:15 +0100, Tom Gundersen wrote: On Thu, Feb 12, 2015 at 7:28 PM, Keller, Jacob E Now I'm having an interesting issue with the current git of systemd-networkd... It works just fine on load, and I get an ip address and everything is happy. After some amount of time, systemd-networkd goes into shutting down.. and I lose my ip address.. There is nothing obvious in the log to indicate that it was turned off. Any suggestions? I'm capturing a clean boot with the issue with SYSTEMD_LOG_LEVEL=debug enabled for more information now. This might be caused by the new exit-on-idle logic Tom added. But that should leave the IP address untouched when exiting. Tom, can you look at 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] Running system with neither dbus, or kdbus?
I have a minimal system and I don't have for example policykit or graphical things. I don't have kdbus yet. However at the moment it seems that e.g. networkd logind components require dbus system bus. Is it feasible to modify networkd/logind to operate without system dbus? E.g. similar how init / systemctl use /run/systemd/private for communication. Would such modifications be welcomed? -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running system with neither dbus, or kdbus?
Hi On Fri, Feb 13, 2015 at 12:56 PM, Dimitri John Ledkov dimitri.j.led...@intel.com wrote: I have a minimal system and I don't have for example policykit or graphical things. I don't have kdbus yet. However at the moment it seems that e.g. networkd logind components require dbus system bus. Is it feasible to modify networkd/logind to operate without system dbus? E.g. similar how init / systemctl use /run/systemd/private for communication. Would such modifications be welcomed? We need a way to communicate between processes (IPC). For systemd we chose dbus, as such it is mandatory. We don't support systems without dbus. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - man/systemd.network.xml network/80-container-host0.network network/80-container-ve.network src/libsystemd src/network
On Tue, Feb 10, 2015 at 9:35 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 09.02.15 03:20, Tom Gundersen (tome...@kemper.freedesktop.org) wrote: commit 7f77697a1744f8df2089848b9d718faf7ba6c665 Author: Tom Gundersen t...@jklm.no Date: Sun Feb 8 23:20:56 2015 +0100 networkd: add support for IPv6 tokens This allows the admin to set the host-specific part of IPv6 addresses, but still receive the prefix via SLAAC. This lacks a manpage update. In particular useful since the concept of Ipv6 tokens is relatively exotic, no? I mean, i never heard of this before... } + +int config_parse_token( That sounds overly generic ;-) networkd: generalize IPv4LL to LinkLocal This allows both IPv4 and IPv6 link-local addresses to be enabled or disabled. By default we still enable IPv6LL and disable IPv4LL. The old config option is kept for backwards compatibility, but removed from the documentation. diff --git a/man/systemd.network.xml b/man/systemd.network.xml index b8facdc..6c137e1 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -236,10 +236,12 @@ /listitem /varlistentry varlistentry - termvarnameIPv4LL=/varname/term + termvarnameLinkLocal=/varname/term Thinking about this, I am wondering if this shouldn't be called LinkLocalAddressing= or so? I mean, link-local is more like an adjective, which one could misunderstand? All suggestions implemented. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] timedated: when performing SetTime compensate for program lag
---
TODO | 2 --
src/timedate/timedated.c | 14 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/TODO b/TODO
index 68b0af6..7b93404 100644
--- a/TODO
+++ b/TODO
@@ -190,8 +190,6 @@ Features:
* we should try harder to collapse start jobs for swaps that end up being the
same:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025359.html
-* timedated should compensate on SetTime for the time spent in polkit
-
* figure out when we can use the coarse timers
* sd-resolve: drop res_query wrapping, people should call via the bus to
resolved instead
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 753c3d1..7948bfa 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -529,6 +529,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m,
void *userdata, sd_bu
Context *c = userdata;
int64_t utc;
struct timespec ts;
+usec_t start, ready;
struct tm* tm;
int r;
@@ -569,6 +570,19 @@ static int method_set_time(sd_bus *bus, sd_bus_message *m,
void *userdata, sd_bu
if (r == 0)
return 1;
+/* adjust ts for time spent in program */
+r = sd_bus_message_get_monotonic_usec(m, start);
+if (r 0) {
+/* we only get this data if we are using kdbus */
+if (r == -ENODATA)
+goto nodata;
+
+return r;
+}
+ready = now(CLOCK_MONOTONIC);
+timespec_store(ts, timespec_load(ts) + (ready - start));
+nodata:
+
/* Set system clock */
if (clock_settime(CLOCK_REALTIME, ts) 0) {
log_error_errno(errno, Failed to set local time: %m);
--
2.2.1.209.g41e5f3a
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unmount / right before reboot/shutdown/kexec
On Fri, Feb 13, 2015 at 11:15 PM, Lorenzo Pistone blaffabla...@gmail.com wrote: the cloud provider I'm testing has rather strange setup. All volumes are provided through nbd, including /, and they have to be unmounted cleanly for reboot to work successfully, because the rebooted or kexec'd kernel will retry to attach them and if there host thinks there's already a connection mounting will fail. However, unmounting needs to happen as the very last thing before rebooting, because after that / will disappear. They currently have an unholy hack: they replace systemd-reboot.service with their own version that simply disconnects / and calls 'echo b /proc/sysrq-trigger'. I believe this is far from the correct way of doing things (among the other things, an update of systemd replaces systemd-reboot.service). How can this be done more cleanly? Please don't argue whether having / as a ndb device is a good thing. It is not my call. I don't know all the details of your setup, so take this with a pinch of salt: Usually it is the task of whomever set up / in the first place to tear it down. So if your initrd sets upd the ndb device, you might want to have a logic similar to what dracut does where you would jump back into the initrd at shutdown and cleanly tear stuff down from there. HTH, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: when performing SetTime compensate for program lag
On Sat, Feb 14, 2015 at 12:34 AM, Shawn Landden sh...@churchofgit.com wrote:
---
TODO | 2 --
src/timedate/timedated.c | 14 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/TODO b/TODO
index 68b0af6..7b93404 100644
--- a/TODO
+++ b/TODO
@@ -190,8 +190,6 @@ Features:
* we should try harder to collapse start jobs for swaps that end up being
the same:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025359.html
-* timedated should compensate on SetTime for the time spent in polkit
-
* figure out when we can use the coarse timers
* sd-resolve: drop res_query wrapping, people should call via the bus to
resolved instead
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 753c3d1..7948bfa 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -529,6 +529,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message
*m, void *userdata, sd_bu
Context *c = userdata;
int64_t utc;
struct timespec ts;
+usec_t start, ready;
struct tm* tm;
int r;
@@ -569,6 +570,19 @@ static int method_set_time(sd_bus *bus, sd_bus_message
*m, void *userdata, sd_bu
if (r == 0)
return 1;
+/* adjust ts for time spent in program */
+r = sd_bus_message_get_monotonic_usec(m, start);
+if (r 0) {
Minor nit: you can avoid the goto with
if (r 0 r != -ENODATA)
return r;
else {
ready = now(CLOCK_MONOTONIC);
timespec_store(ts, timespec_load(ts) + (ready
- start));
}
?
+/* we only get this data if we are using kdbus */
+if (r == -ENODATA)
+goto nodata;
+
+return r;
+}
+ready = now(CLOCK_MONOTONIC);
+timespec_store(ts, timespec_load(ts) + (ready - start));
+nodata:
+
/* Set system clock */
if (clock_settime(CLOCK_REALTIME, ts) 0) {
log_error_errno(errno, Failed to set local time: %m);
--
2.2.1.209.g41e5f3a
___
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] persisting sriov_numvfs
On Tue, Jan 27, 2015 at 5:49 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 27.01.15 08:41, Martin Polednik (mpoled...@redhat.com) wrote: b) Expose this via udev .link files. This would be appropriate if adding/removing VFs is a one-time thing, when a device pops up. This would be networking specific, not cover anything else like GPU or storage or so. Would still be quite nice. Would probably the best option, after a), if VFs cannot be added/removed dynamically all the time without affecting the other VFs. c) Expose this via udev rules files. This would be generic, would work for networking as well as GPUs or storage. This would entail writing our rules files when you want to configure the number of VFs. Care needs to be taken to use the right way to identify devices as they come and go, so that you can apply configuration to them in a stable way. This is somewhat uglier, as we don't really think that udev rules should be used that much for configuration, especially not for configuration written out by programs, rather than manually. However, logind already does this, to assign seat identifiers to udev devices to enable multi-seat support. A combination of b) for networking and c) for the rest might be an option too. I myself would vote for b) + c) since we want to cover most of the possible use cases for SR-IOV and MR-IOV, which hopefully shares the interface; adding Dan back to CC as he is the one to speak for network. I have added b) to our TODO list for networkd/udev .link files. I discussed this with Michal Sekletar who has been looking at this. It appears that the sysfs attribute can only be set after the underlying netdev is IFF_UP. Is that expected? If so, I don't think it is appropriate for udev to deal with this. If anything it should be networkd (who is responsible for bringing the links up), but I must say I don't think this kernel API makes much sense, so hopefully we can come up with something better... c) should probably be done outside of systemd/udev. Just write a tool (or even documenting this might suffice), that creates udev rules in /etc/udev/rules.d, matches against ID_PATH and then sets the right attribute. Lennart -- Lennart Poettering, Red Hat ___ 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
[systemd-devel] [PATCH 3/3] analyze: change behaviour of combined --to/from--pattern
We would require a match against all three: patterns specified
with --to, with --from, and as positional arguments to show an
edge. This does not seem useful. Let instead the positional args
behave like they were specified in both --to and --from, which is
fairly intuitive and should be more useful.
---
man/systemd-analyze.xml | 23 ---
src/analyze/analyze.c | 20 +++-
2 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml
index 61315a0d89..1ff81d3d5a 100644
--- a/man/systemd-analyze.xml
+++ b/man/systemd-analyze.xml
@@ -227,13 +227,22 @@
listitemparaWhen used in conjunction with the
commanddot/command command (see above), this selects which
-relationships are shown in the dependency graph. They both
-require
+relationships are shown in the dependency graph. Both options
+require a
citerefentryrefentrytitleglob/refentrytitlemanvolnum7/manvolnum/citerefentry
-patterns as arguments, which are matched against left-hand and
-right-hand, respectively, nodes of a relationship. Each of
-these can be used more than once, which means a unit name must
-match one of the given values./para/listitem
+pattern as an argument, which will be matched against the
+left-hand and the right-hand, respectively, nodes of a
+relationship./para
+
+paraEach of these can be used more than once, in which case
+the unit name must match one of the values. When tests for
+both sides of the relation are present, a relation must pass
+both tests to be shown. When patterns are also specified as
+positional arguments, they must match at least one side of the
+relation. In other words, patterns specified with those two
+options will trim the list of edges matched by the positional
+arguments, if any are given, and fully determine the list of
+edges shown otherwise./para/listitem
/varlistentry
varlistentry
@@ -252,7 +261,7 @@
termoption--no-man/option/term
listitemparaDo not invoke man to verify the existence of
-man pages listen in varnameDocumentation=/varname.
+man pages listed in varnameDocumentation=/varname.
/para/listitem
/varlistentry
diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index 672a0d7976..1e2a6bbf25 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -974,24 +974,34 @@ static int graph_one_property(sd_bus *bus, const UnitInfo
*u, const char* prop,
_cleanup_strv_free_ char **units = NULL;
char **unit;
int r;
+bool match_patterns;
assert(u);
assert(prop);
assert(color);
+match_patterns = strv_fnmatch(u-id, patterns, 0);
+
+if (!strv_isempty(arg_dot_from_patterns)
+!match_patterns
+!strv_fnmatch(u-id, arg_dot_from_patterns, 0))
+return 0;
+
r = bus_get_unit_property_strv(bus, u-unit_path, prop, units);
if (r 0)
return r;
STRV_FOREACH(unit, units) {
-if (!strv_fnmatch_or_empty(u-id, arg_dot_from_patterns, 0))
-continue;
+bool match_patterns2;
+
+match_patterns2 = strv_fnmatch(*unit, patterns, 0);
-if (!strv_fnmatch_or_empty(*unit, arg_dot_to_patterns, 0))
+if (!strv_isempty(arg_dot_to_patterns)
+!match_patterns2
+!strv_fnmatch(*unit, arg_dot_to_patterns, 0))
continue;
-if (!strv_fnmatch_or_empty(u-id, patterns, 0)
-!strv_fnmatch_or_empty(*unit, patterns, 0))
+if (!strv_isempty(patterns) !match_patterns
!match_patterns2)
continue;
printf(\t\%s\-\%s\ [color=\%s\];\n, u-id, *unit,
color);
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] Add helper for fnmatch over strv
No functional change intended.
---
src/analyze/analyze.c | 46 ---
src/libsystemd-network/network-internal.c | 53 +--
src/shared/strv.c | 10 ++
src/shared/strv.h | 9 ++
src/systemctl/systemctl.c | 51 -
5 files changed, 41 insertions(+), 128 deletions(-)
diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index 46a97eb8e7..672a0d7976 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -25,7 +25,6 @@
#include getopt.h
#include locale.h
#include sys/utsname.h
-#include fnmatch.h
#include sd-bus.h
#include bus-util.h
@@ -985,46 +984,15 @@ static int graph_one_property(sd_bus *bus, const UnitInfo
*u, const char* prop,
return r;
STRV_FOREACH(unit, units) {
-char **p;
-bool match_found;
-
-if (!strv_isempty(arg_dot_from_patterns)) {
-match_found = false;
-
-STRV_FOREACH(p, arg_dot_from_patterns)
-if (fnmatch(*p, u-id, 0) == 0) {
-match_found = true;
-break;
-}
-
-if (!match_found)
-continue;
-}
-
-if (!strv_isempty(arg_dot_to_patterns)) {
-match_found = false;
-
-STRV_FOREACH(p, arg_dot_to_patterns)
-if (fnmatch(*p, *unit, 0) == 0) {
-match_found = true;
-break;
-}
-
-if (!match_found)
-continue;
-}
+if (!strv_fnmatch_or_empty(u-id, arg_dot_from_patterns, 0))
+continue;
-if (!strv_isempty(patterns)) {
-match_found = false;
+if (!strv_fnmatch_or_empty(*unit, arg_dot_to_patterns, 0))
+continue;
-STRV_FOREACH(p, patterns)
-if (fnmatch(*p, u-id, 0) == 0 || fnmatch(*p,
*unit, 0) == 0) {
-match_found = true;
-break;
-}
-if (!match_found)
-continue;
-}
+if (!strv_fnmatch_or_empty(u-id, patterns, 0)
+!strv_fnmatch_or_empty(*unit, patterns, 0))
+continue;
printf(\t\%s\-\%s\ [color=\%s\];\n, u-id, *unit,
color);
}
diff --git a/src/libsystemd-network/network-internal.c
b/src/libsystemd-network/network-internal.c
index 41f43d3389..5867aef662 100644
--- a/src/libsystemd-network/network-internal.c
+++ b/src/libsystemd-network/network-internal.c
@@ -22,7 +22,6 @@
#include netinet/ether.h
#include linux/if.h
#include arpa/inet.h
-#include fnmatch.h
#include strv.h
#include siphash24.h
@@ -97,10 +96,6 @@ bool net_match_config(const struct ether_addr *match_mac,
const char *dev_driver,
const char *dev_type,
const char *dev_name) {
-char * const *match_path;
-char * const *match_driver;
-char * const *match_type;
-char * const *match_name;
if (match_host !condition_test(match_host))
return false;
@@ -117,49 +112,17 @@ bool net_match_config(const struct ether_addr *match_mac,
if (match_mac (!dev_mac || memcmp(match_mac, dev_mac, ETH_ALEN)))
return false;
-if (!strv_isempty(match_paths)) {
-if (!dev_path)
-return false;
+if (!strv_isempty(match_paths))
+return strv_fnmatch(dev_path, match_paths, 0);
-STRV_FOREACH(match_path, match_paths)
-if (fnmatch(*match_path, dev_path, 0) == 0)
-return true;
+if (!strv_isempty(match_drivers))
+return strv_fnmatch(dev_driver, match_drivers, 0);
-return false;
-}
-
-if (!strv_isempty(match_drivers)) {
-if (!dev_driver)
-return false;
-
-STRV_FOREACH(match_driver, match_drivers)
-if (fnmatch(*match_driver, dev_driver, 0) == 0)
-return true;
-
-return false;
-}
-
-if (!strv_isempty(match_types)) {
-if (!dev_type)
-return false;
+if (!strv_isempty(match_types))
+return
Re: [systemd-devel] Running system with neither dbus, or kdbus?
On Fri, 13.02.15 11:56, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: I have a minimal system and I don't have for example policykit or graphical things. I don't have kdbus yet. However at the moment it seems that e.g. networkd logind components require dbus system bus. Is it feasible to modify networkd/logind to operate without system dbus? E.g. similar how init / systemctl use /run/systemd/private for communication. That we do that in PID 1 is because we have to allow communication with PID 1 even before dbus is around. That's the only reason. The code for it I *really* dislike and am looking forward to removing as soon as we can hard-depend on kdbus. With code like that you just write your own little (crappy!) dbus-daemon inside each daemon, that's a bad idea. Would such modifications be welcomed? No. Sorry. That PID 1 does this is a *bad* thing to remove as soon as we can, not a good thing to copy to any other daemon. 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] Running system with neither dbus, or kdbus?
On Fri, Feb 13, 2015 at 1:56 PM, Dimitri John Ledkov dimitri.j.led...@intel.com wrote: I have a minimal system and I don't have for example policykit or graphical things. I don't have kdbus yet. However at the moment it seems that e.g. networkd logind components require dbus system bus. Is it feasible to modify networkd/logind to operate without system dbus? E.g. similar how init / systemctl use /run/systemd/private for communication. Would such modifications be welcomed? I doubt it. Sure, if you had the time, you could patch all these daemons to create a mess of Unix sockets, and you could patch all consumers to use those individual sockets (yes, third-party programs call into logind as well), and you could find all the places where DBus service names are used for synchronization replace them with lockfiles... But you'd just end up reinventing DBus, *poorly*. And for what advantage? It's just a message bus. I've seen plenty of 'minimal' systems that still run a dbus-daemon just fine. *(in fact it confuses me greatly that you're concerned about DBus but happily run systemd logind such)* -- 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] avahi disconnects from bus with kdbus
Hi On Thu, Feb 12, 2015 at 11:32 PM, Daniel Buch boogiewasth...@gmail.com wrote: Hi again, I found another problem, again with avahi-daemon but in combination with Telepathy haze. feb 13 08:26:39 dbuch-laptop systemd-coredump[1211]: Process 1167 (telepathy-haze) of user 1000 dumped core. Stack trace of thread 1167: #0 0x7fe0c9557ae0 g_logv (libglib-2.0.so.0) #1 0x7fe0c9557d1f g_log (libglib-2.0.so.0) #2 0x0041261c n/a (telepathy-haze) #3 0x7fe0c955091d g_main_context_dispatch (libglib-2.0.so.0) #4 0x7fe0c9550cf8 n/a (libglib-2.0.so.0) #5 0x7fe0c9551022 g_main_loop_run (libglib-2.0.so.0) #6 0x7fe0c9214631 tp_run_connection_manager (libtelepathy-glib.so.0) #7 0x0040e73b n/a (telepathy-haze) #8 0x7fe0c8b1e800 __libc_start_main (libc.so.6) #9 0x0040e7ad n/a (telepathy-haze) This looks like a bug in telepathy, properly triggered by a dbus error. This should be fixed upstream, but.. feb 13 08:26:42 dbuch-laptop systemd[642]: Starting DBUS1: org.freedesktop.Telepathy.ConnectionManager.haze... feb 13 08:26:42 dbuch-laptop systemd[642]: Started DBUS1: org.freedesktop.Telepathy.ConnectionManager.haze. feb 13 08:26:42 dbuch-laptop systemd[1]: Starting Avahi mDNS/DNS-SD Stack... feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Found user 'avahi' (UID 84) and group 'avahi' (GID 84). feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Successfully dropped root privileges. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: avahi-daemon 0.6.31 starting up. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Successfully called chroot(). feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Successfully dropped remaining capabilities. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Loading service file /services/sftp-ssh.service. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Process 313 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid) feb 13 08:26:42 dbuch-laptop systemd[1]: Started Avahi mDNS/DNS-SD Stack. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Loading service file /services/ssh.service. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Joining mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.1.2. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: New relevant interface wlp3s0.IPv4 for mDNS. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Network interface enumeration completed. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Registering new address record for fe80::eab1:fcff:fec4:eae1 on wlp3s0.*. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Registering new address record for 192.168.1.2 on wlp3s0.IPv4. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Registering HINFO record with values 'X86_64'/'LINUX'. feb 13 08:26:42 dbuch-laptop systemd-bus-proxyd[329]: Failed to send message to bus: Operation not permitted ..this might be what triggered it. It'd be interesting to see which message was refused here. I'll see whether we can make the bus-proxy more verbose on EPERM. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suspend from wireless keyboard not working
Thanks, it worked. Just had to do some debugging to learn the correct
action for suspend is 'sleep', while 'suspend' is for hibernate. :]
Excuse the ignorance, but why is it a problem if every keyboard would get
the 'power-switch' tag (or if it wouldn't be needed)? For example, would it
be a problem if a distro adds the power-switch tag to all keyboards by
default? If the kernel is in a sleep state, how would it matter to filter
such events? Or is the idea for it to be able to filter such events
immediately after being awoken and then get back to the sleep state?
t'
On 13 February 2015 at 07:46, Lennart Poettering lenn...@poettering.net
wrote:
On Fri, 13.02.15 00:46, Gustavo De Nardin (spuk) (gustav...@gmail.com)
wrote:
Hello.
I'm trying to make my notebook (Lenovo Thinkpad X230) suspend when
pressing
the sleep extra key on a wireless keyboard (Logitech K270 using the
Logitech unifying receiver).
I've been able to map the sleep key to the 'pauseplay' action in a
'/etc/udev/hwdb.d/70-keyboard.hwdb' file, for testing, and it works (as
pause/play, of course), but when I map it to 'suspend', nothing happens.
Pressing the suspend key on the notebook's own keyboard works as
expected
(out of the box, no messing from my part).
I'm running Arch Linux, systemd-218-1, no desktop environment, just
WindowMaker. /etc/logind.conf has HandleSuspendKey on default
('#HandleSuspendKey=suspend').
I also just learned from /usr/share/doc/systemd/NEWS that since v210
logind
won't suspend when the notebook has the lid closed and is on a docking
station, which is my case. But even testing with lid open and out of the
dock, it won't suspend from the wireless keyboard.
What else would be needed? Where/what should I look for?
logind only listens to keypresses of keyboards that carry the udev tag
power-switch. It will ignore all others. By default only the buttons
from ACPI devices and certain special laptop input drivers are marked
like that.
I'd like to open this up for all keyboards by default, but I don't
want to do that unless we can get patches into the kernel that allow
us to suppress wakeups for any key events but the ones we really care
about.
David Herrmann has been posting patches about this, but so far that
lead to very little:
http://markmail.org/message/3omuwwapmfnrwit5#query:+page:1+mid:5v54axmwgteur67z+state:results
As a local fix to make this work for you you can write a udev rule
that adds the power-switch tag to your keyboard.
Lennart
--
Lennart Poettering, Red Hat
--
(nil)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suspend from wireless keyboard not working
On Sat, Feb 14, 2015 at 5:34 AM, Gustavo De Nardin (spuk) gustav...@gmail.com wrote: Excuse the ignorance, but why is it a problem if every keyboard would get the 'power-switch' tag (or if it wouldn't be needed)? For example, would it be a problem if a distro adds the power-switch tag to all keyboards by default? If the kernel is in a sleep state, how would it matter to filter such events? Or is the idea for it to be able to filter such events immediately after being awoken and then get back to the sleep state? Not wakeup from the system sleeping, but the logind process sleeping. To react to power key presses, logind has to process every keypress and filter for the right keys itself. This is why it only listens to special keyboards with a limited number of keys. If it would listen to all keyboards, the logind process would have to do work on every keypress from the user, even though if only cares about a vanishingly small fraction of them. Lennart would like the kernel to do the filtering before sending the presses to logind to avoid the overhead. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Combining systemd-firstboot and systemd-sysusers
Hi all,
I'm trying to adapt systemd-{sysusers,firstboot} for creating the system
users in an initramfs (at generation time).
(Note: I use systemd-firstboot to set the root password.)
The situation
-
So, I'm running firstboot before sysusers (judging from the unit files,
this seems to be desired order).
systemd-firstboot --root=... --root-password=PASSWORD
systemd-sysusers --root=...
The problem
---
systemd-firstboot, when ran, writes /etc/shadow only. Then
systemd-sysusers is ran, but it expects entries to be present
in both /etc/passwd and /etc/shadow.
An entry which is present only in /etc/shadow but not in /etc/passwd
produces an EEXIST error at lines 620-623 (if I had run the tools
without --root argument, a different codepath would've been taken and I
would've got an EBADMSG error at lines 902-905).
The solutions
-
I see three solutions.
- we can make systemd-firstboot write both /etc/passwd and /etc/shadow
entries
(but this is duplication of functionality; I don't like this way...)
- we can run systemd-sysusers before systemd-firstboot
(but systemd-firstboot won't write the password if the entry already
exists)
- make systemd-sysusers correctly handle entries which are only present
in /etc/shadow
(how? by preserving the shadow entry? by overwriting it, preserving
the password? how else?)
The question
Which one to implement?
Thanks for consideration,
--
Ivan Shapovalov / intelfx /
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
Re: [systemd-devel] Suspend from wireless keyboard not working
* Jan Alexander Steffens jan.steff...@gmail.com [2015-02-14 06:02 +0100]: On Sat, Feb 14, 2015 at 5:34 AM, Gustavo De Nardin (spuk) gustav...@gmail.com wrote: Excuse the ignorance, but why is it a problem if every keyboard would get the 'power-switch' tag (or if it wouldn't be needed)? For example, would it be a problem if a distro adds the power-switch tag to all keyboards by default? If the kernel is in a sleep state, how would it matter to filter such events? Or is the idea for it to be able to filter such events immediately after being awoken and then get back to the sleep state? Not wakeup from the system sleeping, but the logind process sleeping. To react to power key presses, logind has to process every keypress and filter for the right keys itself. This is why it only listens to special keyboards with a limited number of keys. If it would listen to all keyboards, the logind process would have to do work on every keypress from the user, even though if only cares about a vanishingly small fraction of them. Lennart would like the kernel to do the filtering before sending the presses to logind to avoid the overhead. Got it. Thanks. -- Gustavo De Nardin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware
On 2015-01-28 at 20:15 +0100, Lennart Poettering wrote:
On Sun, 18.01.15 04:21, Ivan Shapovalov (intelfx...@gmail.com) wrote:
Hi folks,
I'm trying to fix this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88401
The initial problem (as reported) looks following: performing a reload
(maybe implicitly) re-starts alsa-restore.service if it is enabled.
With a bit of debugging I've apparently found a root cause. Explanation
following.
Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
started.
We enter manager_reload(), units are serialized, reset, re-read,
deserialized and then cold-plugged. (Note that e. g. unit_notify() has
special protection to avoid spawning jobs when a reload is in
progress.)
So, if org.cups.cupsd.path is started, *it is almost first to be
cold-plugged*. The call chain is:
unit_coldplug()
path_coldplug()
path_enter_waiting() // recheck == true
path_check_good() // returns true
path_enter_running()
manager_add_job() // at this point we're fucked up
So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
because a reload should never enqueue any jobs (IIUC). So, the job is
enqueued... remember that almost all units are inactive by now. Thus we
end up re-starting half a system (the whole basic.target) as
dependencies.
Questions:
- is my analysis correct?
- if yes, then how to fix this? Maybe add a similar
if (UNIT(p)-manager-n_reloading = 0) check to
path_enter_running() to avoid calling manager_add_job() during
reloading?
Hmm, how does this relate to the ALSA case? I mean, the alsa units
don't use .path units, do they?
So, in general I think .path units should trigger things on reload,
but only those things that ar bound to level, not those to edge,
if you follow what I mean. More specifically, I think that cups.path
should trigger things, since its job is to make sure that cups.service
is running as long as there's a file in /var/spool/cups/.
PathExists=/PathExistsGlob=/DirectoryNotEmpty= are all of the level
kind. As long as the condition they express is true they should ensure
their service is running. PathChanged= and PathModified= OTOH are
edge triggers, and they should only trigger something when a file is
changed while we look at it, but not during coldplugging.
During a reload, I hence believe it is OK if trigger units trigger new
jobs.
Then maybe we can just remember (save somewhere) all new jobs as we
coldplug the units, and actually add them only after we've coldplugged
everything? This way, the transaction machinery will observe the
dependencies' state at the time it is already restored, and no extra
jobs will be created.
--
Ivan Shapovalov / intelfx /
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
