[systemd-devel] logind, su - sessions and initscripts compatibility

[Andrei Borzenkov]

As far as I know, systemd still officially retains compatibility with
initscripts. Unfortunately, session management now at least partially
broke it.

Any initscript that is using su - would create logind session; this
session will persist until processes started by initscript are runing.

On shutdown logind is stopped early; it also tears down all user
sessions killing all processes in these sessions. So initscripts do
not even get chance to initiate clean termination of running services.

The only solution I can think of is to make pam_systemd skip session
based on some environment variable which would be set by sysvinit
generator. Would that be acceptable? Any other idea?

Details are e.g. here:
http://bugzilla.suse.com/show_bug.cgi?id=906900#c34. I now think this
explains several other similar cases reported in the past.

Thank you!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Andrei Borzenkov]

On Thu, Dec 18, 2014 at 7:00 AM, Spencer Baugh sba...@catern.com wrote:
 When printing the status of a unit, open a connection to the session bus
 and query PackageKit for the package that the unit file belongs
 to. Print it if PackageKit knows.

Searching packages database may be quite time consuming. At least make
it optional.

 ---
  src/systemctl/systemctl.c | 32 
  1 file changed, 32 insertions(+)

 diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
 index 4c4648f..ea2772b 100644
 --- a/src/systemctl/systemctl.c
 +++ b/src/systemctl/systemctl.c
 @@ -3381,6 +3381,8 @@ typedef struct UnitStatusInfo {
  const char *source_path;
  const char *control_group;

 +const char *package_name;
 +
  char **dropin_paths;

  const char *load_error;
 @@ -3507,6 +3509,9 @@ static void print_status_info(
  printf(   Loaded: %s%s%s\n,
 on, strna(i-load_state), off);

 +if (i-package_name)
 +printf(  Package: %s\n, i-package_name);
 +
  if (!strv_isempty(i-dropin_paths)) {
  _cleanup_free_ char *dir = NULL;
  bool last = false;
 @@ -4384,6 +4389,11 @@ static int show_one(

  _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
  _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
 +
 +_cleanup_bus_close_unref_ sd_bus *user_bus = NULL;
 +_cleanup_bus_message_unref_ sd_bus_message *packagekit_reply = NULL;
 +
 +const char *file_path;
  UnitStatusInfo info = {};
  ExecStatusInfo *p;
  int r;
 @@ -4453,6 +4463,28 @@ static int show_one(
  if (r  0)
  return bus_log_parse_error(r);

 +file_path = info.source_path ? info.source_path : info.fragment_path;
 +if (file_path) {
 +/* we frequently can't get the user bus, nor call 
 PackageKit, so don't complain on error */
 +sd_bus_default_user(user_bus);
 +if (user_bus) {
 +sd_bus_call_method(
 +user_bus,
 +org.freedesktop.PackageKit,
 +/org/freedesktop/PackageKit,
 +org.freedesktop.PackageKit.Query,
 +SearchFile,
 +NULL,
 +packagekit_reply,
 +ss, file_path, 0);
 +if (packagekit_reply) {
 +r = sd_bus_message_read(packagekit_reply, 
 bs, NULL, info.package_name);
 +if (r  0)
 +return bus_log_parse_error(r);
 +}
 +}
 +}
 +
  r = 0;

  if (!show_properties) {
 --
 2.1.3

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Jóhann B. Guðmundsson]

On 12/18/2014 04:00 AM, Spencer Baugh wrote:

When printing the status of a unit, open a connection to the session bus
and query PackageKit for the package that the unit file belongs
to. Print it if PackageKit knows.


There are gazillion package manager in the wild and this will 
significantly delay the output of the status command which makes this 
something you should be carrying downstream.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to create a systemd service?

[Andrei Dziahel]

there's more — synapse actually can create that .desktop file for you, just
tick start automatically checkbox in program preferences

On Thu, Dec 18, 2014 at 7:14 AM, jenia.ivlev jenia.iv...@gmail.com wrote:

 That's really nice information. Thanks a lot Mantas.

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Regards,
Andrei Dziahel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Alexandre Detiste]

Hi,

You could maybe think of adding some Package= ou SourcePackage=
attribute in units to let users
known where this unit came from.

This would work like SourcePath= does for generated units.

Alexandre Detiste

2014-12-18 10:08 GMT+01:00 Jóhann B. Guðmundsson johan...@gmail.com:

 On 12/18/2014 04:00 AM, Spencer Baugh wrote:

 When printing the status of a unit, open a connection to the session bus
 and query PackageKit for the package that the unit file belongs
 to. Print it if PackageKit knows.


 There are gazillion package manager in the wild and this will significantly
 delay the output of the status command which makes this something you should
 be carrying downstream.

 JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Jóhann B. Guðmundsson]

On 12/18/2014 09:24 AM, Alexandre Detiste wrote:

Hi,

You could maybe think of adding some Package= ou SourcePackage=
attribute in units to let users
known where this unit came from.

This would work like SourcePath= does for generated units.


No this is not very smart to do in general from my pov and should not be 
implemented in a service manager.


The name of the relevant unit file should be representative enough for 
adminsitrators to be able to determine which component it belongs to.


JBG


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v3] Add FDB support

[Rauta, Alin]

Hi Johann,
Also, note that VlanId is optional. It makes more sense for switch ports.
Regarding my “em1” (Ethernet management) interface, probably I should have send 
an example without VLANId.
And “BridgeFDB”s  are in the .network following the logic of routes.


To be clear look at the outputs below:


1.   for a normal port:
bridge fdb show dev em1
   44:44:12:34:56:70 self permanent
   44:44:12:34:56:71 self permanent
   33:33:00:00:00:01 self permanent
   01:00:5e:00:00:01 self permanent
   33:33:ff:8f:e7:3f self permanent
   01:00:5e:00:00:fc self permanent
   33:33:00:01:00:03 self permanent

2. for a switch port:
bridge fdb show dev sw0p1
14:44:12:34:56:70 vlan 2 self permanent
14:44:12:34:56:71 vlan 10 self permanent

/Alin
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
Behalf Of Jóhann B. Guðmundsson
Sent: Thursday, December 18, 2014 5:51 AM
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] [PATCH v3] Add FDB support


On 12/17/2014 05:46 PM, Jóhann B. Guðmundsson wrote:

On 12/17/2014 03:35 PM, Alin Rauta wrote:

Hi Tom,



I've formatted the patch based on our previous discussions. This one has 
support only for adding FDB entries.

An example configuration is like below:



[Match]

Name=em1



[Network]

DHCP=v4



[BridgeFDB]

MACAddress=44:44:12:34:56:71

VLANId=9



[BridgeFDB]

MACAddress=44:44:12:34:56:70

VLANId=2

br0

Please let me know what you think.



Thanks,

Alin


If I start trying to match this with the entire type network files and their 
path ( feel free to correct me where I'm wrong here )
It would have to look like this...

Ignore my mac address entry confusion with the bridge mac addresses in the MAC 
learning table and the interface mac address here ( em1 ) which somewhat would 
have been eliminated if we had [BridgePort] and arguably [BridgePortFDB] 
sections in the network file

JBG

JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network

[Karel Zak]

On Wed, Dec 17, 2014 at 08:04:38PM +0100, Lennart Poettering wrote:
  This is important details, because if you use epoll file descriptor 
  in another epoll then you're correctly notified on the top-level epoll, 
  but you lost information about which underneath file descriptor is active 
  -- then it was impossible to verify the inotify IN_MOVED_TO utab
  event.
 
 Hmm? Not following. The top-level epoll will get an event telling you
 that which low-level epoll is triggered. Then, you read an event from
 that which tells you precisely which actual file has been triggered...

Yes, was my original idea, then followed by frustration ;-) 

It seems it the hierarchy of epolls works only if all the file
descriptors are with EPOLLIN. I had /proc/self/mountinfo with EPOLLPRI
only (because with EPOLLIN it generates events all time as I don't
read the file content).

Today I played with it a little bit more and I found that possible
solution is to use EPOLLPRI | EPOLLIN | EPOLLET for the /proc/self/mountinfo.

Ideas?

   Karel


PS. if anyone wants to play with it then below is test program, just
copy and past to test.c

 $ make test
 $ touch AAA BBB
 $ ./test AAA BBB

 and cat AAA or mount something on another terminal



#include stdio.h
#include stdlib.h
#include err.h
#include sys/epoll.h
#include sys/inotify.h
#include fcntl.h
#include sys/stat.h
#include fcntl.h

static int get_inotify(const char *filename)
{
int fd = inotify_init1(IN_NONBLOCK | IN_CLOEXEC);

if (inotify_add_watch(fd, filename, IN_CLOSE_NOWRITE)  0)
err(EXIT_FAILURE, %s: add watch failed, filename);
return fd;
}

static void clean_inotify_buf(int fd)
{
char buf[BUFSIZ];
while (read(fd, buf, sizeof(buf))  0); /* non-blocking */
}

int main(int argc, char **argv)
{
int a, b, c;
int low_efd, high_efd;
struct epoll_event ev;

/* low epoll */
low_efd = epoll_create1(EPOLL_CLOEXEC);
if (low_efd  0)
err(EXIT_FAILURE, failed to create epoll);

ev.events = EPOLLPRI | EPOLLIN;
a = ev.data.fd = get_inotify(argv[1]);
if (epoll_ctl(low_efd, EPOLL_CTL_ADD, a, ev)  0)
err(EXIT_FAILURE, failed to add %s to low-epoll, argv[1]);

ev.events = EPOLLPRI | EPOLLIN;
b = ev.data.fd = get_inotify(argv[2]);
if (epoll_ctl(low_efd, EPOLL_CTL_ADD, b, ev)  0)
err(EXIT_FAILURE, failed to add %s to low-epoll, argv[2]);

ev.events = EPOLLPRI | EPOLLIN | EPOLLET;
c = ev.data.fd = open(/proc/self/mountinfo, O_RDONLY | O_CLOEXEC);
if (epoll_ctl(low_efd, EPOLL_CTL_ADD, c, ev)  0)
err(EXIT_FAILURE, failed to add mountinfo to low-epoll);

/* high epoll */
high_efd = epoll_create1(EPOLL_CLOEXEC);
if (high_efd  0)
err(EXIT_FAILURE, failed to create high-epoll);

ev.events = EPOLLPRI | EPOLLIN;
ev.data.fd = low_efd;
if (epoll_ctl(high_efd, EPOLL_CTL_ADD, low_efd, ev)  0)
err(EXIT_FAILURE, failed to add to high-epoll);

fprintf(stderr,   top=%d\n, high_efd);
fprintf(stderr, |\n);
fprintf(stderr,   low=%d\n, low_efd);
fprintf(stderr, /   |   \\\n);
fprintf(stderr,   A=%d  B=%d   C=%d\n\n, a, b, c);

do {
struct epoll_event events[1];
int n;

fprintf(stderr, Wainting for event...\n);
n = epoll_wait(high_efd, events, 1, -1);
if (n  0)
err(EXIT_FAILURE, high-epoll wait failed);
if (!n)
continue;

fprintf(stderr, *** has high event (fd=%d)\n, 
events[0].data.fd);
do {
n = epoll_wait(low_efd, events, 1, 0);
if (n  0)
err(EXIT_FAILURE, low-epoll wait failed);
else if (n) {
int fd = events[0].data.fd;
fprintf(stderr,*** has low event 
(fd=%d)\n, fd);
if (fd == a || fd == b)
clean_inotify_buf(fd);
} else
break;  /* no event */
} while (1);
clean_inotify_buf(a);
clean_inotify_buf(b);
} while (1);


}

-- 
 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] logind, su - sessions and initscripts compatibility

[Simon McVittie]

On 18/12/14 08:05, Andrei Borzenkov wrote:
 Any initscript that is using su - would [cause badness]

Don't do that then? Init scripts are fairly clearly not login sessions.
Which init scripts do that?

In Debian, our init scripts would typically use start-stop-daemon
--chuid whateveruser  --start whateverd instead of su. Does your
distribution have an equivalent?

I'm gradually forming the opinion that su should be considered
deprecated for both its roles (interactive privilege
escalation/privilege-dropping for one-off commands or interactive
shells, and automated uid swapping), because it doesn't do either of
them particularly well; in particular, it doesn't sanitize environment
variables by default (you have to remember the - which has other
side-effects), and the need for the command to be a shell command-line
rather than an argument vector makes it hard to use securely.

sudo/pkexec/etc. make good replacements for su - for interactive use,
and something like start-stop-daemon or chroot --userspec=whateveruser
/ -- command (with recent coreutils) can replace su for automated uid
swapping. Both of these make it easy to do something like

subprocess.call(['sudo', '--', executable] + argv)

without needing to involve a shell at all, and if you do need to
evaluate shell syntax,

subprocess.call(['sudo', '--', '/bin/sh', '-c',
shellcommandline])

solves that for you. (For non-Python users: replace subprocess.call with
your favourite way to execute a command specified with an executable and
an array of arguments, such as g_spawn_async().)

S

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logind, su - sessions and initscripts compatibility

[Dale R. Worley]

Simon McVittie simon.mcvit...@collabora.co.uk writes:
 On 18/12/14 08:05, Andrei Borzenkov wrote:
 Any initscript that is using su - would [cause badness]

 Don't do that then? Init scripts are fairly clearly not login sessions.
 Which init scripts do that?

More to the point, why would an initscript do that, since it's *already*
running as root?

Though I'm sufficiently out of the loop regarding the architecture that
I don't see how su can have such complexities -- As far as I know, its
purpose is to create a subprocess whose UID is different from the UID of
this process; in no way is it intended to be a separate login.  Why
would shutting down logind suddenly cause one of my subprocesses to
vanish?

Dale
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logind, su - sessions and initscripts compatibility

[Simon McVittie]

On 18/12/14 14:10, Dale R. Worley wrote:
 Simon McVittie simon.mcvit...@collabora.co.uk writes:
 On 18/12/14 08:05, Andrei Borzenkov wrote:
 Any initscript that is using su - would [cause badness]

 Don't do that then? Init scripts are fairly clearly not login sessions.
 Which init scripts do that?
 
 More to the point, why would an initscript do that, since it's *already*
 running as root?

su isn't just for becoming root; it can also cause transitions from root
to a less privileged user (su -c 'my-app-clear-cache' daemon is one
example of something that an init script might want to do).

 Though I'm sufficiently out of the loop regarding the architecture that
 I don't see how su can have such complexities -- As far as I know, its
 purpose is to create a subprocess whose UID is different from the UID of
 this process; in no way is it intended to be a separate login.

If this was ever true, it ceased to be true when su started running PAM
modules.

This is what I meant about su having multiple roles, and not being
particularly good at any of them...

S

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logind, su - sessions and initscripts compatibility

[Reindl Harald]

Am 18.12.2014 um 15:10 schrieb Dale R. Worley:

Simon McVittie simon.mcvit...@collabora.co.uk writes:

On 18/12/14 08:05, Andrei Borzenkov wrote:

Any initscript that is using su - would [cause badness]


Don't do that then? Init scripts are fairly clearly not login sessions.
Which init scripts do that?


More to the point, why would an initscript do that, since it's *already*
running as root?


because su means switch user and is not limited to root

ExecStartPre can exist more then once and be invoked as different 
users to prepare start of a complex service instead multiple units




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH][Resend][RFC] core: Fix wrong timestamps in rtc-in-local time mode.

[Chunhui He]

Hi all,

When the system is configured to read the RTC time in the local time zone,
some timestamps recorded by systemd are wrong.

This bug can be demonstrated as the following:
(RTC is in UTC+08:00)

$ last
hch  tty1  Wed Nov 19 15:39   still logged in
reboot   system boot  3.16.0-4-amd64   Wed Nov 19 23:39 - 15:40  (-7:-59)  -- 
here
...

$ systemctl show
...
FirmwareTimestampMonotonic=0
LoaderTimestampMonotonic=0
KernelTimestamp=Wed 2014-11-19 23:39:10 CST-- here
KernelTimestampMonotonic=0
InitRDTimestampMonotonic=0
UserspaceTimestamp=Wed 2014-11-19 23:39:13 CST
UserspaceTimestampMonotonic=2707714
FinishTimestamp=Wed 2014-11-19 15:39:25 CST-- here
FinishTimestampMonotonic=14463839
SecurityStartTimestamp=Wed 2014-11-19 23:39:13 CST
SecurityStartTimestampMonotonic=2710030
SecurityFinishTimestamp=Wed 2014-11-19 23:39:13 CST
SecurityFinishTimestampMonotonic=2721209
...

Note that timestamps are _inconsistent_.
(15:39 is correct, 23:39 is 15:39 +08:00)

I think this bug is introduced in commit 
c3a170f3d3358135a39ac6eafe66f18aef0bd67d
(systemd: record the timestamps as early as possible).

In that commit, in order to get more accurate timestamps,
some timestamps are recorded _before_ the very first call of
settimeofday(), which does a time warp in the kernel.

The following is my patch. It has been tested with the latest systemd in git 
repo.

Thanks!
Chunhui He

( I posted this patch last month:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025341.html )

---
 src/core/main.c| 11 ++-
 src/shared/time-util.c | 14 ++
 src/shared/time-util.h |  1 +
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/src/core/main.c b/src/core/main.c
index 77980e3..d658867 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1312,8 +1312,17 @@ int main(int argc, char *argv[]) {
 r = clock_set_timezone(min);
 if (r  0)
 log_error_errno(r, Failed to apply 
local time delta, ignoring: %m);
-else
+else {
 log_info(RTC configured in localtime, 
applying delta of %i minutes to system time., min);
+
+/* Fix timestamps generated before the 
very first call. */
+dual_timestamp_warp(kernel_timestamp, 
min);
+
dual_timestamp_warp(userspace_timestamp, min);
+if(in_initrd())
+
dual_timestamp_warp(initrd_timestamp, min);
+
dual_timestamp_warp(security_start_timestamp, min);
+
dual_timestamp_warp(security_finish_timestamp, min);
+}
 } else if (!in_initrd()) {
 /*
  * Do a dummy very first call to seal the 
kernel's time warp magic.
diff --git a/src/shared/time-util.c b/src/shared/time-util.c
index d3404af..f323835 100644
--- a/src/shared/time-util.c
+++ b/src/shared/time-util.c
@@ -88,6 +88,20 @@ dual_timestamp* dual_timestamp_from_monotonic(dual_timestamp 
*ts, usec_t u) {
 return ts;
 }
 
+dual_timestamp* dual_timestamp_warp(dual_timestamp *ts, int min) {
+usec_t d;
+if (min = 0) {
+d = min * USEC_PER_MINUTE;
+ts-realtime =
+ts-realtime  d ?
+ts-realtime - d : 0;
+} else {
+d = (-min) * USEC_PER_MINUTE;
+ts-realtime = ts-realtime + d;
+}
+return ts;
+}
+
 usec_t timespec_load(const struct timespec *ts) {
 assert(ts);
 
diff --git a/src/shared/time-util.h b/src/shared/time-util.h
index b55a660..8c09963 100644
--- a/src/shared/time-util.h
+++ b/src/shared/time-util.h
@@ -74,6 +74,7 @@ usec_t now(clockid_t clock);
 dual_timestamp* dual_timestamp_get(dual_timestamp *ts);
 dual_timestamp* dual_timestamp_from_realtime(dual_timestamp *ts, usec_t u);
 dual_timestamp* dual_timestamp_from_monotonic(dual_timestamp *ts, usec_t u);
+dual_timestamp* dual_timestamp_warp(dual_timestamp *ts, int min);
 
 static inline bool dual_timestamp_is_set(dual_timestamp *ts) {
 return ((ts-realtime  0  ts-realtime != USEC_INFINITY) ||
-- 
2.1.3


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logind, su - sessions and initscripts compatibility

[Michael Biebl]

2014-12-18 13:19 GMT+01:00 Simon McVittie simon.mcvit...@collabora.co.uk:
 On 18/12/14 08:05, Andrei Borzenkov wrote:
 Any initscript that is using su - would [cause badness]

 Don't do that then? Init scripts are fairly clearly not login sessions.
 Which init scripts do that?

 In Debian, our init scripts would typically use start-stop-daemon
 --chuid whateveruser  --start whateverd instead of su. Does your
 distribution have an equivalent?

 I'm gradually forming the opinion that su should be considered
 deprecated for both its roles (interactive privilege
 escalation/privilege-dropping for one-off commands or interactive
 shells, and automated uid swapping), because it doesn't do either of
 them particularly well; in particular, it doesn't sanitize environment
 variables by default (you have to remember the - which has other
 side-effects), and the need for the command to be a shell command-line
 rather than an argument vector makes it hard to use securely.

I remember that util-linux added a runuser utility [1] which is
supposed to be more suitable to run processes under certain gid/uids
from within scripts.


[1] http://linux.die.net/man/1/runuser

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v3] Add FDB support

[Tom Gundersen]

Hi Alin,

Looks good. I changed the title a bit (addedd networkd:) and dropped
the signed off by, as we don't use that, and pushed it.

Thanks for your work!

Cheers,

Tom

On Wed, Dec 17, 2014 at 4:35 PM, Alin Rauta alin.ra...@intel.com wrote:
 Signed-off-by: Alin Rauta alin.ra...@intel.com
 ---
  Makefile.am  |   1 +
  man/systemd.network.xml  |  22 +++
  src/libsystemd/sd-rtnl/rtnl-message.c|  56 ++-
  src/libsystemd/sd-rtnl/rtnl-types.c  |  15 +-
  src/network/networkd-fdb.c   | 252 
 +++
  src/network/networkd-link.c  |  19 +++
  src/network/networkd-network-gperf.gperf |   2 +
  src/network/networkd-network.c   |  13 +-
  src/network/networkd.h   |  29 
  src/systemd/sd-rtnl.h|   4 +
  10 files changed, 402 insertions(+), 11 deletions(-)
  create mode 100644 src/network/networkd-fdb.c

 diff --git a/Makefile.am b/Makefile.am
 index ab07d3b..6896c4b 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -5281,6 +5281,7 @@ libsystemd_networkd_core_la_SOURCES = \
 src/network/networkd-address.c \
 src/network/networkd-route.c \
 src/network/networkd-manager.c \
 +   src/network/networkd-fdb.c \
 src/network/networkd-address-pool.c

  nodist_libsystemd_networkd_core_la_SOURCES = \
 diff --git a/man/systemd.network.xml b/man/systemd.network.xml
 index 79c7a23..360c57c 100644
 --- a/man/systemd.network.xml
 +++ b/man/systemd.network.xml
 @@ -549,6 +549,28 @@
  /refsect1

  refsect1
 +title[BridgeFDB] Section Options/title
 +paraThe literal[BridgeFDB]/literal section 
 manages the forwarding database table of a port and accepts the following 
 keys. Specify
 +several literal[BridgeFDB]/literal sections to 
 configure several static MAC table entries./para
 +
 +variablelist class='network-directives'
 +varlistentry
 +
 termvarnameMACAddress=/varname/term
 +listitem
 +paraAs in the 
 literal[Network]/literal section. This key is mandatory./para
 +/listitem
 +/varlistentry
 +varlistentry
 +
 termvarnameVLANId=/varname/term
 +listitem
 +paraThe VLAN Id for the 
 new static MAC table entry.
 +If omitted, no VLAN Id info 
 is appended to the new static MAC table entry./para
 +/listitem
 +/varlistentry
 +/variablelist
 +/refsect1
 +
 +refsect1
  titleExample/title
  example
  title/etc/systemd/network/50-static.network/title
 diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c 
 b/src/libsystemd/sd-rtnl/rtnl-message.c
 index 165e84d..9099440 100644
 --- a/src/libsystemd/sd-rtnl/rtnl-message.c
 +++ b/src/libsystemd/sd-rtnl/rtnl-message.c
 @@ -220,6 +220,58 @@ int sd_rtnl_message_new_route(sd_rtnl *rtnl, 
 sd_rtnl_message **ret,
  return 0;
  }

 +int sd_rtnl_message_neigh_set_flags(sd_rtnl_message *m, uint8_t flags) {
 +struct ndmsg *ndm;
 +
 +assert_return(m, -EINVAL);
 +assert_return(m-hdr, -EINVAL);
 +assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), 
 -EINVAL);
 +
 +ndm = NLMSG_DATA(m-hdr);
 +ndm-ndm_flags |= flags;
 +
 +return 0;
 +}
 +
 +int sd_rtnl_message_neigh_set_state(sd_rtnl_message *m, uint16_t state) {
 +struct ndmsg *ndm;
 +
 +assert_return(m, -EINVAL);
 +assert_return(m-hdr, -EINVAL);
 +assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), 
 -EINVAL);
 +
 +ndm = NLMSG_DATA(m-hdr);
 +ndm-ndm_state |= state;
 +
 +return 0;
 +}
 +
 +int sd_rtnl_message_neigh_get_flags(sd_rtnl_message *m, uint8_t *flags) {
 +struct ndmsg *ndm;
 +
 +assert_return(m, -EINVAL);
 +assert_return(m-hdr, -EINVAL);
 +assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), 
 -EINVAL);
 +
 +ndm = NLMSG_DATA(m-hdr);
 +*flags = ndm-ndm_flags;
 +
 +return 0;
 +}
 +
 +int sd_rtnl_message_neigh_get_state(sd_rtnl_message *m, uint16_t *state) {
 +struct ndmsg *ndm;
 +
 +assert_return(m, -EINVAL);
 +assert_return(m-hdr, -EINVAL);
 +assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), 
 -EINVAL);
 +
 +ndm = NLMSG_DATA(m-hdr);
 +*state = ndm-ndm_state;
 +
 +return 0;
 +}
 +
  int 

Re: [systemd-devel] [PATCH v3] Add FDB support

[Rauta, Alin]

Thanks Tom.

Much appreciated,
Alin

-Original Message-
From: Tom Gundersen [mailto:t...@jklm.no] 
Sent: Thursday, December 18, 2014 2:46 PM
To: Rauta, Alin
Cc: systemd Mailing List; Lennart Poettering; Kinsella, Ray
Subject: Re: [PATCH v3] Add FDB support

Hi Alin,

Looks good. I changed the title a bit (addedd networkd:) and dropped the 
signed off by, as we don't use that, and pushed it.

Thanks for your work!

Cheers,

Tom

On Wed, Dec 17, 2014 at 4:35 PM, Alin Rauta alin.ra...@intel.com wrote:
 Signed-off-by: Alin Rauta alin.ra...@intel.com
 ---
  Makefile.am  |   1 +
  man/systemd.network.xml  |  22 +++
  src/libsystemd/sd-rtnl/rtnl-message.c|  56 ++-
  src/libsystemd/sd-rtnl/rtnl-types.c  |  15 +-
  src/network/networkd-fdb.c   | 252 
 +++
  src/network/networkd-link.c  |  19 +++
  src/network/networkd-network-gperf.gperf |   2 +
  src/network/networkd-network.c   |  13 +-
  src/network/networkd.h   |  29 
  src/systemd/sd-rtnl.h|   4 +
  10 files changed, 402 insertions(+), 11 deletions(-)  create mode 
 100644 src/network/networkd-fdb.c

 diff --git a/Makefile.am b/Makefile.am index ab07d3b..6896c4b 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -5281,6 +5281,7 @@ libsystemd_networkd_core_la_SOURCES = \
 src/network/networkd-address.c \
 src/network/networkd-route.c \
 src/network/networkd-manager.c \
 +   src/network/networkd-fdb.c \
 src/network/networkd-address-pool.c

  nodist_libsystemd_networkd_core_la_SOURCES = \ diff --git 
 a/man/systemd.network.xml b/man/systemd.network.xml index 
 79c7a23..360c57c 100644
 --- a/man/systemd.network.xml
 +++ b/man/systemd.network.xml
 @@ -549,6 +549,28 @@
  /refsect1

  refsect1
 +title[BridgeFDB] Section Options/title
 +paraThe literal[BridgeFDB]/literal section 
 manages the forwarding database table of a port and accepts the following 
 keys. Specify
 +several literal[BridgeFDB]/literal 
 + sections to configure several static MAC table entries./para
 +
 +variablelist class='network-directives'
 +varlistentry
 +
 termvarnameMACAddress=/varname/term
 +listitem
 +paraAs in the 
 literal[Network]/literal section. This key is mandatory./para
 +/listitem
 +/varlistentry
 +varlistentry
 +
 termvarnameVLANId=/varname/term
 +listitem
 +paraThe VLAN Id for the 
 new static MAC table entry.
 +If omitted, no VLAN Id info 
 is appended to the new static MAC table entry./para
 +/listitem
 +/varlistentry
 +/variablelist
 +/refsect1
 +
 +refsect1
  titleExample/title
  example
  
 title/etc/systemd/network/50-static.network/title
 diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c 
 b/src/libsystemd/sd-rtnl/rtnl-message.c
 index 165e84d..9099440 100644
 --- a/src/libsystemd/sd-rtnl/rtnl-message.c
 +++ b/src/libsystemd/sd-rtnl/rtnl-message.c
 @@ -220,6 +220,58 @@ int sd_rtnl_message_new_route(sd_rtnl *rtnl, 
 sd_rtnl_message **ret,
  return 0;
  }

 +int sd_rtnl_message_neigh_set_flags(sd_rtnl_message *m, uint8_t flags) {
 +struct ndmsg *ndm;
 +
 +assert_return(m, -EINVAL);
 +assert_return(m-hdr, -EINVAL);
 +assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), 
 + -EINVAL);
 +
 +ndm = NLMSG_DATA(m-hdr);
 +ndm-ndm_flags |= flags;
 +
 +return 0;
 +}
 +
 +int sd_rtnl_message_neigh_set_state(sd_rtnl_message *m, uint16_t state) {
 +struct ndmsg *ndm;
 +
 +assert_return(m, -EINVAL);
 +assert_return(m-hdr, -EINVAL);
 +assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), 
 + -EINVAL);
 +
 +ndm = NLMSG_DATA(m-hdr);
 +ndm-ndm_state |= state;
 +
 +return 0;
 +}
 +
 +int sd_rtnl_message_neigh_get_flags(sd_rtnl_message *m, uint8_t *flags) {
 +struct ndmsg *ndm;
 +
 +assert_return(m, -EINVAL);
 +assert_return(m-hdr, -EINVAL);
 +assert_return(rtnl_message_type_is_neigh(m-hdr-nlmsg_type), 
 + -EINVAL);
 +
 +ndm = NLMSG_DATA(m-hdr);
 +*flags = ndm-ndm_flags;
 +
 +return 0;
 +}
 +
 +int sd_rtnl_message_neigh_get_state(sd_rtnl_message *m, uint16_t *state) {
 +struct ndmsg *ndm;
 +
 +

[systemd-devel] HEADSUP: hwdb management split from udevadm

[Tom Gundersen]

Hi guys,

As a follow-up from splitting sd-hwdb out from libudev, I have just
pushed a patch splitting out the management of the hwdb from udevadm
into its own tool (systemd-hwdb).

The functionality is unchanged, and the fact that the hwdb is very
much Linux- and udev-centric, rather than a generic key-value store,
also remains.

The change was motivated by wanting to slim down udev to simplify
future changes to it, and also make life easier for people writing
udev replacements :)

Comments and testing welcome.

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH udev 0/1] export device sizes

[Carlos Garnacho]

Hey,

I'm sending a patch for udev to export ID_INPUT_[WIDTH|HEIGHT]_MM
properties for tablets and touchscreens. Even if it's scarcely useful info,
IMO it fills a small gap with an eye on Wayland/X11-less sessions.

As some background, I've been hacking on making GNOME input device
configuration on Wayland 1:1 with X. The real gist of the task has been 
traditionally carried out by a separate daemon, which is moving for the
most part to the wm/compositor itself.

However, there's some things we feel should be kept out of the compositor.
Most namely, the policies (or crazy heuristics) applied to determine how
touchscreens and tablets are mapped to the available monitors. The current
work goes towards a split where the compositor systematically maps to outputs
as defined by settings, and gnome-settings-daemon determines which output
seems best. This also caters for devices with no integrated output,
which are thus switchable.

For the most part, the information we can fetch from udev is enough to
implement this in a windowing-independent fashion, the only thing that's
missing is this, and input/output size matching turns out to be the most
reliable of the checks we perform, hence my request to consider this.

Cheers,
  Carlos

 Makefile.am  |  14 +++
 rules/60-input_abs_size.rules|   8 ++
 src/udev/input_abs_size/input_abs_size.c | 177 +++
 3 files changed, 199 insertions(+)

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH udev] udev: Add program/rule to export touchscreen/tablet size as udev properties

[Carlos Garnacho]

This rule is only run on tablet/touchscreen devices, and extracts their size
in millimeters, as it can be found out through their struct input_absinfo.

Conceivably, that information can be changed through EVIOCSABS anywhere
else, but we're only interested in values prior to any calibration, this
rule is thus only run on add, and no tracking of changes is performed.
This should only remain a problem if calibration were automatically applied
by an earlier udev rule (read: don't).
---
 Makefile.am  |  14 +++
 rules/60-input_abs_size.rules|   8 ++
 src/udev/input_abs_size/input_abs_size.c | 177 +++
 3 files changed, 199 insertions(+)
 create mode 100644 rules/60-input_abs_size.rules
 create mode 100644 src/udev/input_abs_size/input_abs_size.c

diff --git a/Makefile.am b/Makefile.am
index ab07d3b..a23705a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3741,6 +3741,20 @@ dist_udevrules_DATA += \
rules/61-accelerometer.rules
 
 # 
--
+input_abs_size_SOURCES = \
+   src/udev/input_abs_size/input_abs_size.c
+
+input_abs_size_LDADD = \
+   libudev-internal.la -lm \
+   libsystemd-shared.la
+
+udevlibexec_PROGRAMS += \
+   input_abs_size_
+
+dist_udevrules_DATA += \
+   rules/60-input_abs_size.rules
+
+# 
--
 if ENABLE_GUDEV
 if ENABLE_GTK_DOC
 SUBDIRS += \
diff --git a/rules/60-input_abs_size.rules b/rules/60-input_abs_size.rules
new file mode 100644
index 000..5f613ac
--- /dev/null
+++ b/rules/60-input_abs_size.rules
@@ -0,0 +1,8 @@
+# do not edit this file, it will be overwritten on update
+
+ACTION!=add, GOTO=input_abs_size_end
+
+ENV{ID_INPUT_TOUCHSCREEN}==1, IMPORT{program}=input_abs_size %p
+ENV{ID_INPUT_TABLET}==1, IMPORT{program}=input_abs_size %p
+
+LABEL=input_abs_size_end
diff --git a/src/udev/input_abs_size/input_abs_size.c 
b/src/udev/input_abs_size/input_abs_size.c
new file mode 100644
index 000..34a6bf3
--- /dev/null
+++ b/src/udev/input_abs_size/input_abs_size.c
@@ -0,0 +1,177 @@
+/*
+ * input_abs_size - extracts abs X/Y size in millimeters from input devices
+ *
+ * Copyright (C) 2014 Red Hat
+ * Author:
+ *   Carlos Garnacho  carl...@gnome.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with keymap; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include stdio.h
+#include string.h
+#include math.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include stdlib.h
+#include unistd.h
+#include getopt.h
+#include limits.h
+#include linux/limits.h
+#include linux/input.h
+
+#include libudev.h
+#include libudev-private.h
+
+/* Resolution is defined to be in units/mm for ABS_X/Y */
+#define ABS_SIZE_MM(absinfo) ((absinfo.maximum - absinfo.minimum) / 
absinfo.resolution)
+
+static void extract_info(struct udev *udev,
+ struct udev_device *dev,
+ const char *devpath)
+{
+struct input_absinfo xabsinfo = { 0 }, yabsinfo = { 0 };
+_cleanup_close_ int fd = -1;
+char text[1024];
+
+if ((fd = open(devpath, O_RDONLY))  0)
+return;
+
+if (ioctl(fd, EVIOCGABS(ABS_X), xabsinfo)  0 ||
+ioctl(fd, EVIOCGABS(ABS_Y), yabsinfo)  0)
+return;
+
+if (xabsinfo.resolution = 0 || yabsinfo.resolution = 0)
+return;
+
+snprintf (text, sizeof(text),
+  ID_INPUT_WIDTH_MM=%d\n
+  ID_INPUT_HEIGHT_MM=%d,
+  ABS_SIZE_MM (xabsinfo),
+  ABS_SIZE_MM (yabsinfo));
+puts (text);
+}
+
+static void help(void)
+{
+printf(Usage: input_abs_size [options] device path\n
+ --debug debug to stderr\n
+ --help  print this help text\n\n);
+}
+
+int main(int argc, char** argv)
+{
+struct udev *udev;
+struct udev_device *dev;
+
+static const struct option options[] = {
+{ debug, no_argument, NULL, 'd' },
+{ help, no_argument, NULL, 'h' },
+{}
+};
+
+char devpath[PATH_MAX];
+char *devnode;
+struct udev_enumerate *enumerate;
+struct udev_list_entry *list_entry;
+
+udev = 

Re: [systemd-devel] [PATCH udev] udev: Add program/rule to export touchscreen/tablet size as udev properties

[Tom Gundersen]

Hi Carlos,

I think David was working on some similar problems recently, so maybe
he has some comments on the overall approach?

Comment on the implementation: If you are going to add this tool to
the systemd codebase, it would be better to do it as a bulit-in
(calling out to binaries should only be done for third-party tools).

Cheers,

Tom

On Thu, Dec 18, 2014 at 3:58 PM, Carlos Garnacho carl...@gnome.org wrote:
 This rule is only run on tablet/touchscreen devices, and extracts their size
 in millimeters, as it can be found out through their struct input_absinfo.

 Conceivably, that information can be changed through EVIOCSABS anywhere
 else, but we're only interested in values prior to any calibration, this
 rule is thus only run on add, and no tracking of changes is performed.
 This should only remain a problem if calibration were automatically applied
 by an earlier udev rule (read: don't).
 ---
  Makefile.am  |  14 +++
  rules/60-input_abs_size.rules|   8 ++
  src/udev/input_abs_size/input_abs_size.c | 177 
 +++
  3 files changed, 199 insertions(+)
  create mode 100644 rules/60-input_abs_size.rules
  create mode 100644 src/udev/input_abs_size/input_abs_size.c

 diff --git a/Makefile.am b/Makefile.am
 index ab07d3b..a23705a 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -3741,6 +3741,20 @@ dist_udevrules_DATA += \
 rules/61-accelerometer.rules

  # 
 --
 +input_abs_size_SOURCES = \
 +   src/udev/input_abs_size/input_abs_size.c
 +
 +input_abs_size_LDADD = \
 +   libudev-internal.la -lm \
 +   libsystemd-shared.la
 +
 +udevlibexec_PROGRAMS += \
 +   input_abs_size_
 +
 +dist_udevrules_DATA += \
 +   rules/60-input_abs_size.rules
 +
 +# 
 --
  if ENABLE_GUDEV
  if ENABLE_GTK_DOC
  SUBDIRS += \
 diff --git a/rules/60-input_abs_size.rules b/rules/60-input_abs_size.rules
 new file mode 100644
 index 000..5f613ac
 --- /dev/null
 +++ b/rules/60-input_abs_size.rules
 @@ -0,0 +1,8 @@
 +# do not edit this file, it will be overwritten on update
 +
 +ACTION!=add, GOTO=input_abs_size_end
 +
 +ENV{ID_INPUT_TOUCHSCREEN}==1, IMPORT{program}=input_abs_size %p
 +ENV{ID_INPUT_TABLET}==1, IMPORT{program}=input_abs_size %p
 +
 +LABEL=input_abs_size_end
 diff --git a/src/udev/input_abs_size/input_abs_size.c 
 b/src/udev/input_abs_size/input_abs_size.c
 new file mode 100644
 index 000..34a6bf3
 --- /dev/null
 +++ b/src/udev/input_abs_size/input_abs_size.c
 @@ -0,0 +1,177 @@
 +/*
 + * input_abs_size - extracts abs X/Y size in millimeters from input devices
 + *
 + * Copyright (C) 2014 Red Hat
 + * Author:
 + *   Carlos Garnacho  carl...@gnome.org
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 + * General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with keymap; if not, write to the Free Software Foundation,
 + * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 + */
 +
 +#include stdio.h
 +#include string.h
 +#include math.h
 +#include sys/types.h
 +#include sys/stat.h
 +#include fcntl.h
 +#include stdlib.h
 +#include unistd.h
 +#include getopt.h
 +#include limits.h
 +#include linux/limits.h
 +#include linux/input.h
 +
 +#include libudev.h
 +#include libudev-private.h
 +
 +/* Resolution is defined to be in units/mm for ABS_X/Y */
 +#define ABS_SIZE_MM(absinfo) ((absinfo.maximum - absinfo.minimum) / 
 absinfo.resolution)
 +
 +static void extract_info(struct udev *udev,
 + struct udev_device *dev,
 + const char *devpath)
 +{
 +struct input_absinfo xabsinfo = { 0 }, yabsinfo = { 0 };
 +_cleanup_close_ int fd = -1;
 +char text[1024];
 +
 +if ((fd = open(devpath, O_RDONLY))  0)
 +return;
 +
 +if (ioctl(fd, EVIOCGABS(ABS_X), xabsinfo)  0 ||
 +ioctl(fd, EVIOCGABS(ABS_Y), yabsinfo)  0)
 +return;
 +
 +if (xabsinfo.resolution = 0 || yabsinfo.resolution = 0)
 +return;
 +
 +snprintf (text, sizeof(text),
 +  ID_INPUT_WIDTH_MM=%d\n
 +  ID_INPUT_HEIGHT_MM=%d,
 +  ABS_SIZE_MM (xabsinfo),
 +  ABS_SIZE_MM (yabsinfo));
 +puts (text);
 +}
 +
 +static void help(void)
 +{
 +printf(Usage: input_abs_size [options] device path\n
 + 

Re: [systemd-devel] logind, su - sessions and initscripts compatibility

[Frederic Crozat]

Le jeudi 18 décembre 2014 à 12:19 +, Simon McVittie a écrit :
 On 18/12/14 08:05, Andrei Borzenkov wrote:
  Any initscript that is using su - would [cause badness]
 
 Don't do that then? Init scripts are fairly clearly not login sessions.
 Which init scripts do that?

Unfortunately, we don't always have a choice, when initscripts are not
shipped as part of packages in the distribution but shipped by an ISV or
a random external software :(

-- 
Frederic Crozat
Project Manager Enterprise Desktop
SUSE

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH udev] udev: Add program/rule to export touchscreen/tablet size as udev properties

[David Herrmann]

Hi

On Thu, Dec 18, 2014 at 3:58 PM, Carlos Garnacho carl...@gnome.org wrote:
 This rule is only run on tablet/touchscreen devices, and extracts their size
 in millimeters, as it can be found out through their struct input_absinfo.

 Conceivably, that information can be changed through EVIOCSABS anywhere
 else, but we're only interested in values prior to any calibration, this
 rule is thus only run on add, and no tracking of changes is performed.
 This should only remain a problem if calibration were automatically applied
 by an earlier udev rule (read: don't).
 ---
  Makefile.am  |  14 +++
  rules/60-input_abs_size.rules|   8 ++
  src/udev/input_abs_size/input_abs_size.c | 177 
 +++
  3 files changed, 199 insertions(+)
  create mode 100644 rules/60-input_abs_size.rules
  create mode 100644 src/udev/input_abs_size/input_abs_size.c

 diff --git a/Makefile.am b/Makefile.am
 index ab07d3b..a23705a 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -3741,6 +3741,20 @@ dist_udevrules_DATA += \
 rules/61-accelerometer.rules

  # 
 --
 +input_abs_size_SOURCES = \
 +   src/udev/input_abs_size/input_abs_size.c
 +
 +input_abs_size_LDADD = \
 +   libudev-internal.la -lm \
 +   libsystemd-shared.la
 +
 +udevlibexec_PROGRAMS += \
 +   input_abs_size_
 +
 +dist_udevrules_DATA += \
 +   rules/60-input_abs_size.rules
 +
 +# 
 --
  if ENABLE_GUDEV
  if ENABLE_GTK_DOC
  SUBDIRS += \
 diff --git a/rules/60-input_abs_size.rules b/rules/60-input_abs_size.rules
 new file mode 100644
 index 000..5f613ac
 --- /dev/null
 +++ b/rules/60-input_abs_size.rules
 @@ -0,0 +1,8 @@
 +# do not edit this file, it will be overwritten on update
 +
 +ACTION!=add, GOTO=input_abs_size_end
 +
 +ENV{ID_INPUT_TOUCHSCREEN}==1, IMPORT{program}=input_abs_size %p
 +ENV{ID_INPUT_TABLET}==1, IMPORT{program}=input_abs_size %p
 +
 +LABEL=input_abs_size_end
 diff --git a/src/udev/input_abs_size/input_abs_size.c 
 b/src/udev/input_abs_size/input_abs_size.c
 new file mode 100644
 index 000..34a6bf3
 --- /dev/null
 +++ b/src/udev/input_abs_size/input_abs_size.c
 @@ -0,0 +1,177 @@
 +/*
 + * input_abs_size - extracts abs X/Y size in millimeters from input devices
 + *
 + * Copyright (C) 2014 Red Hat
 + * Author:
 + *   Carlos Garnacho  carl...@gnome.org
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 + * General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with keymap; if not, write to the Free Software Foundation,
 + * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 + */
 +
 +#include stdio.h
 +#include string.h
 +#include math.h
 +#include sys/types.h
 +#include sys/stat.h
 +#include fcntl.h
 +#include stdlib.h
 +#include unistd.h
 +#include getopt.h
 +#include limits.h
 +#include linux/limits.h
 +#include linux/input.h
 +
 +#include libudev.h
 +#include libudev-private.h
 +
 +/* Resolution is defined to be in units/mm for ABS_X/Y */
 +#define ABS_SIZE_MM(absinfo) ((absinfo.maximum - absinfo.minimum) / 
 absinfo.resolution)
 +
 +static void extract_info(struct udev *udev,
 + struct udev_device *dev,
 + const char *devpath)
 +{
 +struct input_absinfo xabsinfo = { 0 }, yabsinfo = { 0 };
 +_cleanup_close_ int fd = -1;
 +char text[1024];
 +
 +if ((fd = open(devpath, O_RDONLY))  0)
 +return;
 +
 +if (ioctl(fd, EVIOCGABS(ABS_X), xabsinfo)  0 ||
 +ioctl(fd, EVIOCGABS(ABS_Y), yabsinfo)  0)
 +return;
 +
 +if (xabsinfo.resolution = 0 || yabsinfo.resolution = 0)
 +return;
 +
 +snprintf (text, sizeof(text),
 +  ID_INPUT_WIDTH_MM=%d\n
 +  ID_INPUT_HEIGHT_MM=%d,
 +  ABS_SIZE_MM (xabsinfo),
 +  ABS_SIZE_MM (yabsinfo));
 +puts (text);
 +}
 +
 +static void help(void)
 +{
 +printf(Usage: input_abs_size [options] device path\n
 + --debug debug to stderr\n
 + --help  print this help text\n\n);
 +}
 +
 +int main(int argc, char** argv)
 +{
 +struct udev *udev;
 +struct udev_device *dev;
 +
 +static const struct option options[] = {
 +{ debug, no_argument, NULL, 'd' },
 +{ help, 

Re: [systemd-devel] [PATCH udev] udev: Add program/rule to export touchscreen/tablet size as udev properties

[David Herrmann]

Hi

On Thu, Dec 18, 2014 at 4:15 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Thu, Dec 18, 2014 at 3:58 PM, Carlos Garnacho carl...@gnome.org wrote:
 This rule is only run on tablet/touchscreen devices, and extracts their size
 in millimeters, as it can be found out through their struct input_absinfo.

 Conceivably, that information can be changed through EVIOCSABS anywhere
 else, but we're only interested in values prior to any calibration, this
 rule is thus only run on add, and no tracking of changes is performed.
 This should only remain a problem if calibration were automatically applied
 by an earlier udev rule (read: don't).
 ---
  Makefile.am  |  14 +++
  rules/60-input_abs_size.rules|   8 ++
  src/udev/input_abs_size/input_abs_size.c | 177 
 +++
  3 files changed, 199 insertions(+)
  create mode 100644 rules/60-input_abs_size.rules
  create mode 100644 src/udev/input_abs_size/input_abs_size.c

 diff --git a/Makefile.am b/Makefile.am
 index ab07d3b..a23705a 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -3741,6 +3741,20 @@ dist_udevrules_DATA += \
 rules/61-accelerometer.rules

  # 
 --
 +input_abs_size_SOURCES = \
 +   src/udev/input_abs_size/input_abs_size.c
 +
 +input_abs_size_LDADD = \
 +   libudev-internal.la -lm \
 +   libsystemd-shared.la
 +
 +udevlibexec_PROGRAMS += \
 +   input_abs_size_
 +
 +dist_udevrules_DATA += \
 +   rules/60-input_abs_size.rules
 +
 +# 
 --
  if ENABLE_GUDEV
  if ENABLE_GTK_DOC
  SUBDIRS += \
 diff --git a/rules/60-input_abs_size.rules b/rules/60-input_abs_size.rules
 new file mode 100644
 index 000..5f613ac
 --- /dev/null
 +++ b/rules/60-input_abs_size.rules
 @@ -0,0 +1,8 @@
 +# do not edit this file, it will be overwritten on update
 +
 +ACTION!=add, GOTO=input_abs_size_end
 +
 +ENV{ID_INPUT_TOUCHSCREEN}==1, IMPORT{program}=input_abs_size %p
 +ENV{ID_INPUT_TABLET}==1, IMPORT{program}=input_abs_size %p
 +
 +LABEL=input_abs_size_end
 diff --git a/src/udev/input_abs_size/input_abs_size.c 
 b/src/udev/input_abs_size/input_abs_size.c
 new file mode 100644
 index 000..34a6bf3
 --- /dev/null
 +++ b/src/udev/input_abs_size/input_abs_size.c
 @@ -0,0 +1,177 @@
 +/*
 + * input_abs_size - extracts abs X/Y size in millimeters from input devices
 + *
 + * Copyright (C) 2014 Red Hat
 + * Author:
 + *   Carlos Garnacho  carl...@gnome.org
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 + * General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with keymap; if not, write to the Free Software Foundation,
 + * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
 + */
 +
 +#include stdio.h
 +#include string.h
 +#include math.h
 +#include sys/types.h
 +#include sys/stat.h
 +#include fcntl.h
 +#include stdlib.h
 +#include unistd.h
 +#include getopt.h
 +#include limits.h
 +#include linux/limits.h
 +#include linux/input.h
 +
 +#include libudev.h
 +#include libudev-private.h
 +
 +/* Resolution is defined to be in units/mm for ABS_X/Y */
 +#define ABS_SIZE_MM(absinfo) ((absinfo.maximum - absinfo.minimum) / 
 absinfo.resolution)
 +
 +static void extract_info(struct udev *udev,
 + struct udev_device *dev,
 + const char *devpath)
 +{
 +struct input_absinfo xabsinfo = { 0 }, yabsinfo = { 0 };
 +_cleanup_close_ int fd = -1;
 +char text[1024];
 +
 +if ((fd = open(devpath, O_RDONLY))  0)
 +return;
 +
 +if (ioctl(fd, EVIOCGABS(ABS_X), xabsinfo)  0 ||
 +ioctl(fd, EVIOCGABS(ABS_Y), yabsinfo)  0)
 +return;
 +
 +if (xabsinfo.resolution = 0 || yabsinfo.resolution = 0)
 +return;
 +
 +snprintf (text, sizeof(text),
 +  ID_INPUT_WIDTH_MM=%d\n
 +  ID_INPUT_HEIGHT_MM=%d,
 +  ABS_SIZE_MM (xabsinfo),
 +  ABS_SIZE_MM (yabsinfo));
 +puts (text);
 +}
 +
 +static void help(void)
 +{
 +printf(Usage: input_abs_size [options] device path\n
 + --debug debug to stderr\n
 + --help  print this help text\n\n);
 +}
 +
 +int main(int argc, char** argv)
 +{
 +struct udev *udev;
 +struct udev_device *dev;
 +
 +static const struct option options[] = {

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Spencer Baugh]

Quoting Jóhann B. Guðmundsson (2014-12-18 04:08:32)
 
 On 12/18/2014 04:00 AM, Spencer Baugh wrote:
  When printing the status of a unit, open a connection to the session bus
  and query PackageKit for the package that the unit file belongs
  to. Print it if PackageKit knows.
 
 There are gazillion package manager in the wild 

PackageKit is a generic interface to the local package manager, used
by all the major distros and desktop environments. It's installed by
default on any normal desktop/laptop. So this is different from
hardcoding a call out to yum or apt.

 and this will 
 significantly delay the output of the status command which makes this 
 something you should be carrying downstream.

It adds 800ms to the output on my system. Still, adding a command line
flag to enable/disable this behavior would be good. If other
slower-than-usual operations are added, we might want to
enable/disable them with the same flag.  Suggestions on a flag name
that's appropriate for that behavior?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Reindl Harald]

Am 18.12.2014 um 17:19 schrieb Spencer Baugh:

Quoting Jóhann B. Guðmundsson (2014-12-18 04:08:32)


On 12/18/2014 04:00 AM, Spencer Baugh wrote:

When printing the status of a unit, open a connection to the session bus
and query PackageKit for the package that the unit file belongs
to. Print it if PackageKit knows.


There are gazillion package manager in the wild


PackageKit is a generic interface to the local package manager, used
by all the major distros and desktop environments. It's installed by
default on any normal desktop/laptop. So this is different from
hardcoding a call out to yum or apt


please when do so *silently* fall back to ignore it on systems where 
PackageKit is removed by intention, that's what frequently is done on 
machines of users deploy servers and their own workstations and operate 
exclusively with YUM or DNF


in short: don't make it another log-flood candidate



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Cameron Norman]

On Thu, Dec 18, 2014 at 8:35 AM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 18.12.2014 um 17:19 schrieb Spencer Baugh:

 Quoting Jóhann B. Guðmundsson (2014-12-18 04:08:32)


 On 12/18/2014 04:00 AM, Spencer Baugh wrote:

 When printing the status of a unit, open a connection to the session bus
 and query PackageKit for the package that the unit file belongs
 to. Print it if PackageKit knows.


 There are gazillion package manager in the wild


 PackageKit is a generic interface to the local package manager, used
 by all the major distros and desktop environments. It's installed by
 default on any normal desktop/laptop. So this is different from
 hardcoding a call out to yum or apt


 please when do so *silently* fall back to ignore it on systems where
 PackageKit is removed by intention, that's what frequently is done on
 machines of users deploy servers and their own workstations and operate
 exclusively with YUM or DNF

 in short: don't make it another log-flood candidate

The patch takes that into account:

   /* we frequently can't get the user bus, nor call PackageKit,
so don't complain on error */

--
Cameron Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 18, 2014 at 11:19:22AM -0500, Spencer Baugh wrote:
 Quoting Jóhann B. Guðmundsson (2014-12-18 04:08:32)
  
  On 12/18/2014 04:00 AM, Spencer Baugh wrote:
   When printing the status of a unit, open a connection to the session bus
   and query PackageKit for the package that the unit file belongs
   to. Print it if PackageKit knows.
  
  There are gazillion package manager in the wild 
 
 PackageKit is a generic interface to the local package manager, used
 by all the major distros and desktop environments. It's installed by
 default on any normal desktop/laptop. So this is different from
 hardcoding a call out to yum or apt.
Yes, packagekit is generic and widespread enough.

  and this will 
  significantly delay the output of the status command which makes this 
  something you should be carrying downstream.
 
 It adds 800ms to the output on my system. Still, adding a command line
 flag to enable/disable this behavior would be good. If other
 slower-than-usual operations are added, we might want to
 enable/disable them with the same flag.  Suggestions on a flag name
 that's appropriate for that behavior?
I think you should make it opt-in, with a command-line switch (--show-package 
?).
In some cases it can be very useful, but most of the time it would
be just a slow down. If the switch is used, and packagekit does not
work, then this should cause a warning or an error though.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Jóhann B. Guðmundsson]

On 12/18/2014 05:48 PM, Zbigniew Jędrzejewski-Szmek wrote:

I think you should make it opt-in, with a command-line switch (--show-package 
?).
In some cases it can be very useful, but most of the time it would
be just a slow down. If the switch is used, and packagekit does not
work, then this should cause a warning or an error though.


a) The name of the service is supposed to be descriptive enough
b) Encase it's not we already provide the ability to point to the 
upstream documentation
c) This will slow down all containerized and virtualzation and 
monitoring system that might be using the status ouput for one thing or 
another


Bottom line what is the practical purpose of this since the 
administrator is the one that a runs the status output on the service so 
he's capable of a) determine the package by the name of the unit, gather 
it from either the man page or the documentation link or by querying the 
exact origin of the unit file using the package management installed on 
his system?


What's the justification for the latency and the resource overhead to 
provide this?


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 18, 2014 at 06:33:50PM +, Jóhann B. Guðmundsson wrote:
 
 On 12/18/2014 05:48 PM, Zbigniew Jędrzejewski-Szmek wrote:
 I think you should make it opt-in, with a command-line switch 
 (--show-package ?).
 In some cases it can be very useful, but most of the time it would
 be just a slow down. If the switch is used, and packagekit does not
 work, then this should cause a warning or an error though.
 
 a) The name of the service is supposed to be descriptive enough
 b) Encase it's not we already provide the ability to point to the
 upstream documentation
 c) This will slow down all containerized and virtualzation and
 monitoring system that might be using the status ouput for one thing
 or another
 
 Bottom line what is the practical purpose of this since the
 administrator is the one that a runs the status output on the
 service so he's capable of a) determine the package by the name of
 the unit, gather it from either the man page or the documentation
 link or by querying the exact origin of the unit file using the
 package management installed on his system?
 
 What's the justification for the latency and the resource overhead
 to provide this?
You missed the part where I said you should make it opt-in.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Jóhann B. Guðmundsson]

On 12/18/2014 06:36 PM, Zbigniew Jędrzejewski-Szmek wrote:

You missed the part where I said you should make it opt-in.


Should we not first determine the practicality of implementing this and 
if the system service manager should actually be looking up this info to 
begin with?


We could not add the ability to define the upstream homepage in the 
status output but we can now clutter the status output with a name of a 
package?


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Jóhann B. Guðmundsson]

On 12/18/2014 06:44 PM, Jóhann B. Guðmundsson wrote:


On 12/18/2014 06:36 PM, Zbigniew Jędrzejewski-Szmek wrote:

You missed the part where I said you should make it opt-in.


Should we not first determine the practicality of implementing this 
and if the system service manager should actually be looking up this 
info to begin with?


We could not add the ability to define the upstream homepage in the 
status output but we can now clutter the status output with a name of 
a package?


This could be implemented without the overhead and conflict as an 
extension to the output listed with systemctl list-unit-files if opt-in


UNIT FILE STATEComponent
proc-sys-fs-binfmt_misc.automount   static systemd-218-1.fc22.x86_64




JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 18, 2014 at 06:44:25PM +, Jóhann B. Guðmundsson wrote:
 
 On 12/18/2014 06:36 PM, Zbigniew Jędrzejewski-Szmek wrote:
 You missed the part where I said you should make it opt-in.
 
 Should we not first determine the practicality of implementing this
 and if the system service manager should actually be looking up this
 info to begin with?
I assum the patch is functional. I didn't check it, and don't know
too much about packagekit, but I don't think it would have been
posted otherwise.
 
 We could not add the ability to define the upstream homepage in the
 status output but we can now clutter the status output with a name
 of a package?
This is just a dynamic call-out. An embedded URL can easily get outdated,
and also might not suit all downstreams.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 18, 2014 at 07:09:34PM +, Jóhann B. Guðmundsson wrote:
 
 On 12/18/2014 06:44 PM, Jóhann B. Guðmundsson wrote:
 
 On 12/18/2014 06:36 PM, Zbigniew Jędrzejewski-Szmek wrote:
 You missed the part where I said you should make it opt-in.
 
 Should we not first determine the practicality of implementing
 this and if the system service manager should actually be looking
 up this info to begin with?
 
 We could not add the ability to define the upstream homepage in
 the status output but we can now clutter the status output with a
 name of a package?
 
 This could be implemented without the overhead and conflict as an
 extension to the output listed with systemctl list-unit-files if
 opt-in
That's a valid point. list-unit-files seems to be a better home
for this.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] HEADSUP: hwdb management split from udevadm

[Umut Tezduyar Lindskog]

Fantastic Tom! You were nice enough to group all the hwdb files in a section.

Can I send a patch to wrap them with a ./configure option? The option
should even include to make udevadm-hwdb.c, libudev-hwdb.c and
udev-builtin-hwdb.c configurable.

Umut

On Thu, Dec 18, 2014 at 3:57 PM, Tom Gundersen t...@jklm.no wrote:
 Hi guys,

 As a follow-up from splitting sd-hwdb out from libudev, I have just
 pushed a patch splitting out the management of the hwdb from udevadm
 into its own tool (systemd-hwdb).

 The functionality is unchanged, and the fact that the hwdb is very
 much Linux- and udev-centric, rather than a generic key-value store,
 also remains.

 The change was motivated by wanting to slim down udev to simplify
 future changes to it, and also make life easier for people writing
 udev replacements :)

 Comments and testing welcome.

 Cheers,

 Tom
 ___
 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] [dm-devel] multipath breaks with recent udev/systemd

[Kay Sievers]

On Wed, Dec 17, 2014 at 1:04 PM, Hannes Reinecke h...@suse.de wrote:
 On 12/16/2014 11:18 PM, Benjamin Marzinski wrote:
 On Tue, Dec 16, 2014 at 04:10:44PM -0600, Benjamin Marzinski wrote:
 On Mon, Dec 15, 2014 at 10:31:44AM +0100, Hannes Reinecke wrote:
 [ .. ]
 So during bootup it's anyone's guess who's first, multipath or udev.
 And depending on the timing either multipath will fail to setup
 the device-mapper device or udev will simply ignore the device.
 Neither of those is a good, but the first is an absolute killer for
 modern systems which _rely_ on udev to configure devices.

 So how it this supposed to work?
 Why does udev ignore the entire event if it can't get the lock?
 Shouldn't it rather be retried?
 What is the supposed recovery here?

 Hannes, are you against the idea that Alexander mentioned in his first
 email, of just locking a file in /var/lock?  Multipathd doesn't create
 devices in parallel. Multipath doesn't create files in parallel.  We are
 explicitly trying to avoid multipath and multipathd creating files at
 the same time. So, we should only need a single file to lock, and
 /run/lock should always be there.

 O.k. So if we want to keep our current nonblocking behavior, we'll need
 more lockfiles, either one per path or one per wwid.  This still seems
 like a reasonable idea, if there is a good reason for systemd doing what
 it's doing.

 The problem is as follows:

 When multipathd is running we simply _cannot_ guarantee that no udev
 events are currently running.

All running block device events will take a shared lock of the device
node. This can be used?

 This currently hits us especially bad
 during system startup when device probing is still running during
 multipathd startup.
 Multipathd will then enumerate all block devices to setup the
 initial topology.
 But in doing so it might trip over device which are still processed
 by udev (or, worse still, _not yet_ processed by udev).
 (Yes, I know, libudev_enumerate should protect against this.
  But it doesn't. )

There is a udev_enumerate_match_is_initialized(), which can help?

 So it's anyone guess what'll happen now; either multipath trips over
 the lock from udev when calling 'lock_multipath' (and consequently
 failing to setup the multipath device), or udev
 tripping over the lock from multipath and ignoring the event,
 leaving us with a non-functioning device.

 We can fixup the startup sequence (which we need to do anyway, given
 the libudev enumerate bug) to just re-trigger all block device
 events, but this still doesn't fix the actual issue.
 Point is, there might be _several_ events for the same device being
 queued (think of a flaky path with several PATH_FAILED /
 PATH_REINSTATED events in a row), and so multipathd might be
 processing one event for the device while udev is processing the
 next event for the same device.

 For this to work we need some synchronization with udev; _if_ there
 would be a libudev callout for 'is there an event for this device
 running' we can easily fail the 'lock_multipath' operation, knowing
 that we'll be getting another event shortly for the same device.

 Alternatively we can call flock(LOCK_EX) on that device, but that
 will only work if udev would _not_ abort event handling for that
 device, but rather issues a retry.

Exclusive locks signify device ownership and udev will suppress all
events to not disturb the owner's operations. There can't be any udev
dependencies or expectations of udev doing something during the time
an exclusive lock is held.

 After all, there _is_ a device timeout in udev. It should be
 relatively easy to retry the event and let it run into a timeout if
 the lock won't be released.

We should avoid any complex rules here, and if possible just reduce
the scheme to a simple ownership model.

Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Spencer Baugh]

Quoting Kay Sievers (2014-12-18 15:04:22)
 On Thu, Dec 18, 2014 at 8:19 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Thu, Dec 18, 2014 at 07:09:34PM +, Jóhann B. Guðmundsson wrote:
 
  On 12/18/2014 06:44 PM, Jóhann B. Guðmundsson wrote:
  
  On 12/18/2014 06:36 PM, Zbigniew Jędrzejewski-Szmek wrote:
  You missed the part where I said you should make it opt-in.
  
  Should we not first determine the practicality of implementing
  this and if the system service manager should actually be looking
  up this info to begin with?
  
  We could not add the ability to define the upstream homepage in
  the status output but we can now clutter the status output with a
  name of a package?
 
  This could be implemented without the overhead and conflict as an
  extension to the output listed with systemctl list-unit-files if
  opt-in
  That's a valid point. list-unit-files seems to be a better home
  for this.
 
 The systemd command line tools are not supposed to call into
 higher-level daemons to query data. This sounds like the wrong way
 around. It sound like someone should teach packagekit about systemd
 units.
 
 Also, systmed does not want to get involved into any concept of
 packages. It is what distributions are made of, but this is not
 systemd's task to manage of describe.

systemctl does already directly invoke man to read man pages, despite
that just being one way among many to maintain documentation.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemctl: print unit package in status

[Lennart Poettering]

On Thu, 18.12.14 18:48, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 On Thu, Dec 18, 2014 at 11:19:22AM -0500, Spencer Baugh wrote:
  Quoting Jóhann B. Guðmundsson (2014-12-18 04:08:32)
   
   On 12/18/2014 04:00 AM, Spencer Baugh wrote:
When printing the status of a unit, open a connection to the session bus
and query PackageKit for the package that the unit file belongs
to. Print it if PackageKit knows.
   
   There are gazillion package manager in the wild 
  
  PackageKit is a generic interface to the local package manager, used
  by all the major distros and desktop environments. It's installed by
  default on any normal desktop/laptop. So this is different from
  hardcoding a call out to yum or apt.
 Yes, packagekit is generic and widespread enough.
 
   and this will 
   significantly delay the output of the status command which makes this 
   something you should be carrying downstream.
  
  It adds 800ms to the output on my system. Still, adding a command line
  flag to enable/disable this behavior would be good. If other
  slower-than-usual operations are added, we might want to
  enable/disable them with the same flag.  Suggestions on a flag name
  that's appropriate for that behavior?
 I think you should make it opt-in, with a command-line switch (--show-package 
 ?).
 In some cases it can be very useful, but most of the time it would
 be just a slow down. If the switch is used, and packagekit does not
 work, then this should cause a warning or an error though.

Well, humm. Not convinced this is a good idea. I mean, showing it by
default is not a good idea, given how slow this is. But hiding it
behind some switch makes it mostly useless, as it's not any more
discoverable then invoking rpm -qf on the fragment path would be.

Also, in general I am not really convinced that this kind of hookup
with external daemons that are not part of systemd itself is really a
good idea. It's the wrong way around I think. I mean, we so far had
such a weird dependency on the dbus daemon, and we are just about to
get rid of it, but doing the pkgkit hookup adds a new one back in
where our base OS starts using components way up the stack...

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] systemctl: print unit package in status

[Reindl Harald]

Am 18.12.2014 um 21:26 schrieb Spencer Baugh:

Quoting Kay Sievers (2014-12-18 15:04:22)

On Thu, Dec 18, 2014 at 8:19 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:

On Thu, Dec 18, 2014 at 07:09:34PM +, Jóhann B. Guðmundsson wrote:


On 12/18/2014 06:44 PM, Jóhann B. Guðmundsson wrote:


On 12/18/2014 06:36 PM, Zbigniew Jędrzejewski-Szmek wrote:

You missed the part where I said you should make it opt-in.


Should we not first determine the practicality of implementing
this and if the system service manager should actually be looking
up this info to begin with?

We could not add the ability to define the upstream homepage in
the status output but we can now clutter the status output with a
name of a package?


This could be implemented without the overhead and conflict as an
extension to the output listed with systemctl list-unit-files if
opt-in

That's a valid point. list-unit-files seems to be a better home
for this.


The systemd command line tools are not supposed to call into
higher-level daemons to query data. This sounds like the wrong way
around. It sound like someone should teach packagekit about systemd
units.

Also, systmed does not want to get involved into any concept of
packages. It is what distributions are made of, but this is not
systemd's task to manage of describe.


systemctl does already directly invoke man to read man pages, despite
that just being one way among many to maintain documentation


there is a difference between calling a local mandb and issue Packagekit 
which may refresh it's caches and so produce network load and 
unpredictable delays up to timeouts


systemd should be as tiny as possible with as less as possible 
dependencies and not became a OS at it's own on top of a OS




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] HEADSUP: hwdb management split from udevadm

[Tom Gundersen]

On Thu, Dec 18, 2014 at 9:11 PM, Umut Tezduyar Lindskog
u...@tezduyar.com wrote:
 Can I send a patch to wrap them with a ./configure option? The option
 should even include to make udevadm-hwdb.c, libudev-hwdb.c and
 udev-builtin-hwdb.c configurable.

Making systemd-hwdb optional (and hence also the .hwdb files) sounds reasonable.

I don't think we should make the library optional though (it is tiny
and deals well with the db not being around, and having to make it
optional in its various consumers sounds like unnecessary work).

Not sure about the builtin, it does not pull in any extra dependencies
(unlike e.g. blkid), and is pretty small, so not sure I see the
benefit of having it optional?

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Journal tests broken by commit 6573ef05a3cbe1 (journal: keep per-JournalFile location info during iteration)

[Filipe Brandenburger]

Hi,

Commit 6573ef05a3cbe1 (journal: keep per-JournalFile location info
during iteration) breaks tests test-journal-stream and
test-journal-interleaving.

It seems that the logic of overriding f-current_offset in
journal_file_save_location has other unintended side effects, checking
out that commit and commenting out that line seems to have
test-journal-stream working back again, but not
test-journal-interleaving. The same no longer has effect in trunk
head anymore since I believe the follow up patches rely on that saved
information which is no longer there.

Not sure if the problem is in the code or in the tests, but looking at
the tests the logic looks right to me, so I'm leaning towards the
code...

Cheers,
Filipe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [dm-devel] multipath breaks with recent udev/systemd

[Benjamin Marzinski]

On Wed, Dec 17, 2014 at 01:04:54PM +0100, Hannes Reinecke wrote:
 On 12/16/2014 11:18 PM, Benjamin Marzinski wrote:
  On Tue, Dec 16, 2014 at 04:10:44PM -0600, Benjamin Marzinski wrote:
  On Mon, Dec 15, 2014 at 10:31:44AM +0100, Hannes Reinecke wrote:
 [ .. ]
  So during bootup it's anyone's guess who's first, multipath or udev.
  And depending on the timing either multipath will fail to setup
  the device-mapper device or udev will simply ignore the device.
  Neither of those is a good, but the first is an absolute killer for
  modern systems which _rely_ on udev to configure devices.
 
  So how it this supposed to work?
  Why does udev ignore the entire event if it can't get the lock?
  Shouldn't it rather be retried?
  What is the supposed recovery here?
 
  Hannes, are you against the idea that Alexander mentioned in his first
  email, of just locking a file in /var/lock?  Multipathd doesn't create
  devices in parallel. Multipath doesn't create files in parallel.  We are
  explicitly trying to avoid multipath and multipathd creating files at
  the same time. So, we should only need a single file to lock, and
  /run/lock should always be there.
  
  O.k. So if we want to keep our current nonblocking behavior, we'll need
  more lockfiles, either one per path or one per wwid.  This still seems
  like a reasonable idea, if there is a good reason for systemd doing what
  it's doing.
  
 The problem is as follows:
 
 When multipathd is running we simply _cannot_ guarantee that no udev
 events are currently running. This currently hits us especially bad
 during system startup when device probing is still running during
 multipathd startup.
 Multipathd will then enumerate all block devices to setup the
 initial topology.
 But in doing so it might trip over device which are still processed
 by udev (or, worse still, _not yet_ processed by udev).
 (Yes, I know, libudev_enumerate should protect against this.
  But it doesn't. )

But we start waiting for events before the initial multipath device
configuration, and don't process them until after that configuration
is compelete, so if there is ever a case where the initial configuration
is accessing the device to early, aren't we guaranteed to get an event
afterwards, assuming that udev doesn't drop it?

 
 So it's anyone guess what'll happen now; either multipath trips over
 the lock from udev when calling 'lock_multipath' (and consequently
 failing to setup the multipath device), or udev
 tripping over the lock from multipath and ignoring the event,
 leaving us with a non-functioning device.

But my point above is that if we use a lockfile instead of locking the
path device itself, there won't be any lock contention, and udev won't
drop the events.

 We can fixup the startup sequence (which we need to do anyway, given
 the libudev enumerate bug) to just re-trigger all block device
 events, but this still doesn't fix the actual issue.
 Point is, there might be _several_ events for the same device being
 queued (think of a flaky path with several PATH_FAILED /
 PATH_REINSTATED events in a row), and so multipathd might be
 processing one event for the device while udev is processing the
 next event for the same device.
 
 For this to work we need some synchronization with udev; _if_ there
 would be a libudev callout for 'is there an event for this device
 running' we can easily fail the 'lock_multipath' operation, knowing
 that we'll be getting another event shortly for the same device.

But if we can avoid the lock contention, then eventually all these
events will make it to multipathd, and we will be up to date. right?
Or am I missing something here?

-Ben

 Alternatively we can call flock(LOCK_EX) on that device, but that
 will only work if udev would _not_ abort event handling for that
 device, but rather issues a retry.
 After all, there _is_ a device timeout in udev. It should be
 relatively easy to retry the event and let it run into a timeout if
 the lock won't be released.
 
 Cheers,
 
 Hannes
 -- 
 Dr. Hannes Reinecke  zSeries  Storage
 h...@suse.de +49 911 74053 688
 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
 GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
 HRB 21284 (AG Nürnberg)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal tests broken by commit 6573ef05a3cbe1 (journal: keep per-JournalFile location info during iteration)

[Filipe Brandenburger]

I took a closer look at test-journal-stream. It's setting up 3
journal files and writing entries to the three of them with some
interleaving, then expecting to read them in order.

After commit 6573ef05a3cbe1, what happens is that a single call to
sd_journal_next() ends up calling next_beyond_location() on the three
files which advances the f-current_offset from the three of them, so
the first access looks right, you'll be comparing the first entry of
each of the three files, but the second access is bad because you're
comparing the second entry of each of the three files, instead of the
second entry of the one that was picked before with the first entry of
the other two files.

Not sure what's the correct solution, maybe journal_file_save_location
needs to happen only in real_journal_next() outside the
ORDERED_HASHMAP_FOREACH loop? I'll try that and report if I find
something that seems to solve this problem...

Cheers,
Filipe


On Thu, Dec 18, 2014 at 2:34 PM, Filipe Brandenburger
filbran...@google.com wrote:
 Hi,

 Commit 6573ef05a3cbe1 (journal: keep per-JournalFile location info
 during iteration) breaks tests test-journal-stream and
 test-journal-interleaving.

 It seems that the logic of overriding f-current_offset in
 journal_file_save_location has other unintended side effects, checking
 out that commit and commenting out that line seems to have
 test-journal-stream working back again, but not
 test-journal-interleaving. The same no longer has effect in trunk
 head anymore since I believe the follow up patches rely on that saved
 information which is no longer there.

 Not sure if the problem is in the code or in the tests, but looking at
 the tests the logic looks right to me, so I'm leaning towards the
 code...

 Cheers,
 Filipe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal tests broken by commit 6573ef05a3cbe1 (journal: keep per-JournalFile location info during iteration)

[Filipe Brandenburger]

On Thu, Dec 18, 2014 at 4:39 PM, Filipe Brandenburger
filbran...@google.com wrote:
 Not sure what's the correct solution, maybe journal_file_save_location
 needs to happen only in real_journal_next() outside the
 ORDERED_HASHMAP_FOREACH loop? I'll try that and report if I find
 something that seems to solve this problem...

I tried this on top of commit 6573ef05a3cbe1 and it solves the problem.

After applying this patch:

diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c
index 71b056c..a727e12 100644
--- a/src/journal/sd-journal.c
+++ b/src/journal/sd-journal.c
@@ -859,8 +859,6 @@
 found = true;

 if (found) {
-journal_file_save_location(f, direction, c, cp);
-
 if (ret)
 *ret = c;
 if (offset)
@@ -917,6 +915,8 @@
 if (!new_file)
 return 0;

+journal_file_save_location(new_file, direction, o, new_offset);
+
 r = journal_file_move_to_object(new_file, OBJECT_ENTRY,
new_offset, o);
 if (r  0)
 return r;


Then test-journal-stream and test-journal-interleaving are working
again and I have a clean make check run.

But this does not work on trunk head, even after adapting it, the
tests start to fail in a different location, probably because of the
changes that come after it, so I think we'll need this and further
changes to it. I'll keep looking.

Cheers,
Filipe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal tests broken by commit 6573ef05a3cbe1 (journal: keep per-JournalFile location info during iteration)

[Filipe Brandenburger]

On Thu, Dec 18, 2014 at 4:58 PM, Filipe Brandenburger
filbran...@google.com wrote:
 But this does not work on trunk head, even after adapting it, the
 tests start to fail in a different location, probably because of the
 changes that come after it, so I think we'll need this and further
 changes to it. I'll keep looking.

Ok, so I found that reverting these three patches:

- Revert 58439db journal: drop unnecessary parameters of
next_beyond_location()
- Revert d8ae66d journal: compare candidate entries using
JournalFiles' locations
- Revert e499c99 journal: remove redundant variable new_offset

And applying the following patch:

diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c
index 8d63094..cabe080 100644
--- a/src/journal/sd-journal.c
+++ b/src/journal/sd-journal.c
@@ -860,8 +860,6 @@
 found = true;

 if (found) {
-journal_file_save_location(f, direction, c, cp);
-
 if (ret)
 *ret = c;
 if (offset)
@@ -918,6 +916,8 @@
 if (!new_file)
 return 0;

+journal_file_save_location(new_file, direction, o, new_offset);
+
 r = journal_file_move_to_object(new_file, OBJECT_ENTRY,
new_offset, o);
 if (r  0)
 return r;


This seems to fix test-journal-stream, but
test-journal-interleaving is still broken (assertion 'r == 1' failed
at src/journal/test-journal-interleaving.c:101, function
test_check_numbers_down.)

At this point, I'm leaning towards believeing that the logic of the
patchset doesn't really work with more than one journal file and I'd
be inclined to suggest reverting all of it.

Cheers,
Filipe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] mount failed because the mount point dir doesn't exist

[Baoquan He]

Hi,

Now I encountered a prlblem. When I add an entry in /etc/fstab to mount
a disk on a dir like below, mount can be done successfully though /aa/bb
doesn't exist.
_ _ _ _ _
/dev/disk/by-uuid/xxx-xxx  /aa/bb   xfs  defaults  0 2


However when I make a initramfs for kdump kernel, I add an entry to
$mntimg/etc/fstab like below, mount will fail if /sysroot/var/crash
doesn't exist. 
_ _ _ _ _
/dev/disk/by-uuid/xxx-xxx/sysroot/var/crash xfs 
rw,relatime,...,x-initrd.mount 0 2

Does anyone know why this happen and how to fix it, or any
suggestion/idea?

Thanks
Baoquan

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

[Andrei Borzenkov]

В Mon, 15 Dec 2014 14:20:45 -0600
Dan Williams d...@redhat.com пишет:

 On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
  В Mon, 15 Dec 2014 11:34:17 -0600
  Dan Williams d...@redhat.com пишет:
  
   
   On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 NetworkManager sets logind inhibitor lock to monitor for suspend
 events. So it implicitly requires logind to be present when NM
 starts.
   
   NM doesn't actually require that, it just wants to know about the
   signals that logind sends and have a chance to respond to them.  If
   logind isn't running, NM shouldn't really care.  But perhaps expectation
   is not matching reality in the code.
   
Any idea what it needs the inhibitor for?
   
   To be aware of suspend/resume events of course.  NM may want to
   disconnect the network cleanly before suspending, and on resume may need
   to clean up network connections and restart certain operations.
   
 logind is ordered after nss-user-lookup.target. If we have remote
   user
 database, it means that logind depends on network to be up and
   running.
 
 If network is provided by NetworkManager we have a loop.
 
 Due to the fact that NetworkManager service itself does not declare
 dependency on logind, it can be pretty hard to recognize.
 
 Any idea how it can be solved nicely? I can only think of delaying
 inhibitor logic in NM until logind is started. Not sure what side
 effects it may have.

Yeah, I figure if they want to be able to run in early parts of boot
they should watch logind's bus name and create their inhibitor only
after it appears.
   
   Does logind get D-Bus autolaunched?
  
  Yes.
  
  NM is just creating a bus proxy for
   the logind DBus service, and then attempting to call a D-Bus method on
   logind to take an inhibitor.  It doesn't actually care that much about
   the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
   prohibit logind from launching.
   
   Perhaps NM is requesting logind to start through D-Bus autolaunch, but
   since the network isn't up yet logind then fails itself?
   
  
  systemd tries to launch logind service which now waits for services it
  is ordered After and eventually times out.
 
 NM patch filed for review by NM dev team:
 
 https://bugzilla.gnome.org/show_bug.cgi?id=741572
 

Yes it was reported to fix the problems during system startup. Thank
you!

I wonder if there is any way to delay suspend in race free way.

 Also, I don't think logind should fail if there is no network;

Logind was not even started - systemd waited for required services to
start it and timed out.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [dm-devel] multipath breaks with recent udev/systemd

[Hannes Reinecke]

On 12/18/2014 11:04 PM, Benjamin Marzinski wrote:
 On Wed, Dec 17, 2014 at 01:04:54PM +0100, Hannes Reinecke wrote:
 On 12/16/2014 11:18 PM, Benjamin Marzinski wrote:
 On Tue, Dec 16, 2014 at 04:10:44PM -0600, Benjamin Marzinski wrote:
 On Mon, Dec 15, 2014 at 10:31:44AM +0100, Hannes Reinecke wrote:
 [ .. ]
 So during bootup it's anyone's guess who's first, multipath or udev.
 And depending on the timing either multipath will fail to setup
 the device-mapper device or udev will simply ignore the device.
 Neither of those is a good, but the first is an absolute killer for
 modern systems which _rely_ on udev to configure devices.

 So how it this supposed to work?
 Why does udev ignore the entire event if it can't get the lock?
 Shouldn't it rather be retried?
 What is the supposed recovery here?

 Hannes, are you against the idea that Alexander mentioned in his first
 email, of just locking a file in /var/lock?  Multipathd doesn't create
 devices in parallel. Multipath doesn't create files in parallel.  We are
 explicitly trying to avoid multipath and multipathd creating files at
 the same time. So, we should only need a single file to lock, and
 /run/lock should always be there.

 O.k. So if we want to keep our current nonblocking behavior, we'll need
 more lockfiles, either one per path or one per wwid.  This still seems
 like a reasonable idea, if there is a good reason for systemd doing what
 it's doing.

 The problem is as follows:

 When multipathd is running we simply _cannot_ guarantee that no udev
 events are currently running. This currently hits us especially bad
 during system startup when device probing is still running during
 multipathd startup.
 Multipathd will then enumerate all block devices to setup the
 initial topology.
 But in doing so it might trip over device which are still processed
 by udev (or, worse still, _not yet_ processed by udev).
 (Yes, I know, libudev_enumerate should protect against this.
  But it doesn't. )
 
 But we start waiting for events before the initial multipath device
 configuration, and don't process them until after that configuration
 is compelete, so if there is ever a case where the initial configuration
 is accessing the device to early, aren't we guaranteed to get an event
 afterwards, assuming that udev doesn't drop it?
 
That was the initial idea. Only it doesn't do it currently :-)


 So it's anyone guess what'll happen now; either multipath trips over
 the lock from udev when calling 'lock_multipath' (and consequently
 failing to setup the multipath device), or udev
 tripping over the lock from multipath and ignoring the event,
 leaving us with a non-functioning device.
 
 But my point above is that if we use a lockfile instead of locking the
 path device itself, there won't be any lock contention, and udev won't
 drop the events.
 
The underlying issue here is:

Why does multipath lock the devices _at all_?
If it were to protect against device disappearing while doing the
ioctl that's already proven not to work.
And for protecting against mounts a simple open(O_EXCL) would be
sufficient. So whom are we fooling here?

Cheers,

Hannes
-- 
Dr. Hannes ReineckezSeries  Storage
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] HEADSUP: hwdb management split from udevadm

[Umut Tezduyar Lindskog]

On Thu, Dec 18, 2014 at 9:57 PM, Tom Gundersen t...@jklm.no wrote:
 On Thu, Dec 18, 2014 at 9:11 PM, Umut Tezduyar Lindskog
 u...@tezduyar.com wrote:
 Can I send a patch to wrap them with a ./configure option? The option
 should even include to make udevadm-hwdb.c, libudev-hwdb.c and
 udev-builtin-hwdb.c configurable.

 Making systemd-hwdb optional (and hence also the .hwdb files) sounds 
 reasonable.

Great! I will prepare something.


 I don't think we should make the library optional though (it is tiny
 and deals well with the db not being around, and having to make it
 optional in its various consumers sounds like unnecessary work).

 Not sure about the builtin, it does not pull in any extra dependencies
 (unlike e.g. blkid), and is pretty small, so not sure I see the
 benefit of having it optional?

It has been bothering me that udev is holding an fd to hwdb.bin but
once we stop installing hwdb.bin, things should be fine. I am OK with
your suggestion.

Umut


 Cheers,

 Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel