Re: [systemd-devel] [PATCH] libsystemd-login.so: fix undefined reference to 'cg_create'

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 13:28, Yang Chengwei (chengwei.y...@intel.com) wrote:

 On Tue, Sep 10, 2013 at 06:02:55PM +0200, Lennart Poettering wrote:
  On Mon, 26.08.13 13:48, Chengwei Yang (chengwei.y...@intel.com) wrote:
  
  Hmm, can you elaborate on this one? libsystemd-login should be mostly
 
 This error occurs while building dbus with systemd support like below
 
 $ make
 make  all-recursive
 make[1]: Entering directory `/home/chengwei/Upstream/dbus.git'
 Making all in dbus
 make[2]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus'
 make  all-am
 make[3]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus'
   CCLD   dbus-test
   /usr/lib/libsystemd-login.so: undefined reference to `cg_create'
   collect2: ld returned 1 exit status
   make[3]: *** [dbus-test] Error 1
   make[3]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus'
   make[2]: *** [all] Error 2
   make[2]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus'
   make[1]: *** [all-recursive] Error 1
   make[1]: Leaving directory `/home/chengwei/Upstream/dbus.git'
   make: *** [all] Error 2
 
 and cg_create referenced by libsystemd-login.so like below
 
 $ grep cg_create src/login/ -r
 Binary file src/login/systemd_logind-logind-session.o matches
 Binary file src/login/systemd_logind-logind-user.o matches

But these files are not linked into libsystemd-login, but only into
logind (the daemon)...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering
On Tue, 10.09.13 13:33, Colin Walters (walt...@verbum.org) wrote:

 
 On Tue, 2013-09-10 at 18:47 +0200, Lennart Poettering wrote:
 
  I'd actually prefer having an explicit blacklist for this, so that we
  don't have to trust the initrd too much that...
 
 But nowadays it's systemd running in the initrd, what's not to trust?

Well, might be a different version, might be one without systemd, ...

  However, I'd really like to see this blacklist be unified
  somewhere. Maybe a new function in util.c or so called
  is_os_resource_path()
 
 What would the blacklist contain?  Just / and /usr?  Or would it also
 have /var?

/, /usr, /etc probably.

/var is something where we allow that it is mounted at late boot and
that it is unmounted at late shutdown (at least in theory).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/7] filesystem targets: disable default dependencies

2013-09-11 Thread Harald Hoyer
On 09/10/2013 06:41 PM, Lennart Poettering wrote:
 On Fri, 23.08.13 15:09, Tom Gundersen (t...@jklm.no) wrote:
 
 This means we can use default dependencies on mount units without having to 
 get them automatically
 ordered before the filesystem targets.
 
 Looks good. But before we merge this, Harald, can you comment? Any issue
 with this?

No issues. Looks good!

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


Re: [systemd-devel] PrivateNetwork=true conflicts with Type=notify

2013-09-11 Thread Lennart Poettering
On Tue, 10.09.13 19:04, Pierre Schmitz (pie...@archlinux.de) wrote:

heya,

 when trying to disable network access to the PHP-FPM service I noticed
 that the service was no longer able to call back to systemd using
 Type=notify. Systemd then kills the service when reaching the timeout.
 It seems this could be a limitation by design in which case we might
 want to warn the user when attepmting such setup.

Uh, ah. Interesting. So we could actually do something about this, but
it would break things elsewhere...

So, the notification socket could either be an abstract namespace
AF_UNIX socket, or an AF_UNIX socket in the file system. If it is in the
file system, then it becomes unavailable as soon as the daemon
chroot()s. If it is in the abstract namespace it becomes unavailable as
soon as CLONE_NEWNET/PrivateNetworking=yes is used.

Due to the chroot() situation we changed a couple of times forth and
back between fs/abstract in the past (most recently
29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da).

I am not sure what is the better choice here... We could of course have
two sockets, one in the fs and one in the abstract namespace, and then
pass the right one to the process depending on the setting of
PrivateNetworking=... But that would not work as soon as the daemon then
also decides to chroot()/RootDirectory= is used...

Tricky problem... I am a bit out of ideas. Anyone?

 On a side node: The private network systemd sets up for such services
 enables IPv6 even if this is disabled on the host using
 net.ipv6.conf.all.disable_ipv6=1. I cannot think of a scenario where
 this leads to trouble though.

Oh, that's interesting. This sounds like a kernel bug, as
net.ipv6.conf.all.disable_ipv6  doesn't really exist separate in the
child namespace... And if it does then it should inherit the aprents
default. EItherwise something to fix. Can you report to kernel bz, plz?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/7] filesystem targets: disable default dependencies

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 13:42, Harald Hoyer (harald.ho...@gmail.com) wrote:

 
 On 09/10/2013 06:41 PM, Lennart Poettering wrote:
  On Fri, 23.08.13 15:09, Tom Gundersen (t...@jklm.no) wrote:
  
  This means we can use default dependencies on mount units without having 
  to get them automatically
  ordered before the filesystem targets.
  
  Looks good. But before we merge this, Harald, can you comment? Any issue
  with this?
 
 No issues. Looks good!

Tom, please commit! (but modulo the network-online patch, plz)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] PrivateNetwork=true conflicts with Type=notify

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 13:49, Lennart Poettering (lenn...@poettering.net) wrote:

 On Tue, 10.09.13 19:04, Pierre Schmitz (pie...@archlinux.de) wrote:
 
 heya,
 
  when trying to disable network access to the PHP-FPM service I noticed
  that the service was no longer able to call back to systemd using
  Type=notify. Systemd then kills the service when reaching the timeout.
  It seems this could be a limitation by design in which case we might
  want to warn the user when attepmting such setup.
 
 Uh, ah. Interesting. So we could actually do something about this, but
 it would break things elsewhere...
 
 So, the notification socket could either be an abstract namespace
 AF_UNIX socket, or an AF_UNIX socket in the file system. If it is in the
 file system, then it becomes unavailable as soon as the daemon
 chroot()s. If it is in the abstract namespace it becomes unavailable as
 soon as CLONE_NEWNET/PrivateNetworking=yes is used.
 
 Due to the chroot() situation we changed a couple of times forth and
 back between fs/abstract in the past (most recently
 29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da).
 
 I am not sure what is the better choice here... We could of course have
 two sockets, one in the fs and one in the abstract namespace, and then
 pass the right one to the process depending on the setting of
 PrivateNetworking=... But that would not work as soon as the daemon then
 also decides to chroot()/RootDirectory= is used...
 
 Tricky problem... I am a bit out of ideas. Anyone?

(for now I have documented this behaviour in the man pages.)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] libsystemd-login.so: fix undefined reference to 'cg_create'

2013-09-11 Thread Kay Sievers
On Wed, Sep 11, 2013 at 1:27 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 11.09.13 13:28, Yang Chengwei (chengwei.y...@intel.com) wrote:

 On Tue, Sep 10, 2013 at 06:02:55PM +0200, Lennart Poettering wrote:
  On Mon, 26.08.13 13:48, Chengwei Yang (chengwei.y...@intel.com) wrote:
 
  Hmm, can you elaborate on this one? libsystemd-login should be mostly

 This error occurs while building dbus with systemd support like below

 $ make
 make  all-recursive
 make[1]: Entering directory `/home/chengwei/Upstream/dbus.git'
 Making all in dbus
 make[2]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus'
 make  all-am
 make[3]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus'
   CCLD   dbus-test
   /usr/lib/libsystemd-login.so: undefined reference to `cg_create'
   collect2: ld returned 1 exit status
   make[3]: *** [dbus-test] Error 1
   make[3]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus'
   make[2]: *** [all] Error 2
   make[2]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus'
   make[1]: *** [all-recursive] Error 1
   make[1]: Leaving directory `/home/chengwei/Upstream/dbus.git'
   make: *** [all] Error 2

 and cg_create referenced by libsystemd-login.so like below

 $ grep cg_create src/login/ -r
 Binary file src/login/systemd_logind-logind-session.o matches
 Binary file src/login/systemd_logind-logind-user.o matches

 But these files are not linked into libsystemd-login, but only into
 logind (the daemon)...

Does this print something when executed in the build tree?
  $ nm -D .libs/libsystemd-login.so | grep cg

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


[systemd-devel] How to implement a demon process by socket activation

2013-09-11 Thread Tony Seo
Hi
I have been aiming to make a demon process by socket activation in systemd.
you know that,  it was provided for socket activation in systemd homepage
like below .
http://0pointer.de/blog/projects/socket-activation.html

I refered that guide for making a daemon process started using socket
activation.

I just followed the explanation in that site and tried to make a pair of
server/client program on TCP/IP.( I just only added a sd_listen_fds()
library fuction in server process using sd-daemon library)

But it didn't work when I started server process.

those processes  include  almost same code with following the guide.

Is that all to make a daemon process by socket activation in homepage?



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


Re: [systemd-devel] [PATCH 1/2] Optimize startswith() to macro

2013-09-11 Thread Lennart Poettering
On Fri, 23.08.13 14:09, WANG Chao (chaow...@redhat.com) wrote:

   - Why not use startswith() instead of first_word()?
  first_word is not equivalent: there must be a word boundary after the
  word:
 
 Yeah, you're right. I occasionally got carried away at midnight :(
 
 And I think a inline static version could be a little faster? Right?

Not necessarilly. On today's CPUs often smaller code results in faster
execution than avoiding function calls...

If we shift this around further we probably should do it properly and
play around with benchmarks...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Some thoughts about loop_read/loop_write in util.c

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 21:50, cee1 (fykc...@gmail.com) wrote:

 Hi all,
 
 loop_read/loop_write:
 http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c#n2179
 
 In a scenario of pipes, loop_read on read side, if the write side is
 closed, loop_read will return 0 if do_poll is false(let's assume no
 data available to read). When do_poll is true, it will return:
 1) 0, if write side is closed while loop_read is just doing a read
 2) or -EIO when poll returns pollfd.revent with POLLHUP flag set
 
 The behavior is not very consistent.
 IMHO, it's preferred loop_read follows read behavior as much as
 possible -- returns 0 to indicate end of a file here, e.g. We can try
 to read 0 bytes when pollfd.revents != POLLIN.

EOF and temporarily not being able to read more data is something very
different. 

It might make sense to return EAGAIN if POLLHUP is set though.

(But note that POLLHUP has more complex semantics when combined with
shutdown() and half-open connections...)

 The same with loop_write.

EOF doesn't exist for loop_write(), so this is even weirder

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to implement a demon process by socket activation

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 21:33, Tony Seo (tonys...@gmail.com) wrote:

 Hi
 I have been aiming to make a demon process by socket activation in systemd.
 you know that,  it was provided for socket activation in systemd homepage
 like below .
 http://0pointer.de/blog/projects/socket-activation.html
 
 I refered that guide for making a daemon process started using socket
 activation.
 
 I just followed the explanation in that site and tried to make a pair of
 server/client program on TCP/IP.( I just only added a sd_listen_fds()
 library fuction in server process using sd-daemon library)
 
 But it didn't work when I started server process.
 
 those processes  include  almost same code with following the guide.
 
 Is that all to make a daemon process by socket activation in homepage?

Yes, usually it is. Note however that some daemons close all open fds
during initialization. You need to exclude the socket actviation fds
from that.

It might be useful to play around with the new systemd-activate tool in
order to debug this. See man 8 systemd-activate.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering
On Tue, 10.09.13 19:54, Tom Gundersen (t...@jklm.no) wrote:

  But it annoys me that we're propagating this hardcoding in the new code
  too.  How about we make systemd inspect /proc/self/mountinfo *very*
  early on at boot when it starts, and ensure skip unmounting these, under
  the assumption they'll be taken care of either in the initrd, or by the
  final kill spree?
 
  I'd actually prefer having an explicit blacklist for this, so that we
  don't have to trust the initrd too much that...
 
 Not sure if I get in what sense you mean we need to trust the initrd.
 What I thought we'd do was to simply notice what filesystems were
 already mounted when systemd first started in the real root (so
 whatever caused them to be mounted in the initrd is not important).

What gives me the headache there is that initrds are so varied right
now. It just gives me headaches leaving it to the numerous initrds
implementations to decide what the file systems with OS resources
are. I'd much rather define clearly that /etc, / and /usr are OS
resources in the systemd context, rather then leave that definition to
the inirds/dsitro packagers... This is too close to the core of the OS
to leave this undefined and varying between the distributions I'd say...

 If you meant we'd need to trust the initrd to umount them correctly at
 shutdown, I guess we could keep doing the umount loop in the real root
 also for the premounted filesystems (and at least remount them ro),
 but not complain too much if we can't umount them, as the failure is
 sort of expected.
 
 I'm not too keen on a blacklist. It would work for the simple case of
 course, but I have seen lots of fancy/complicated stuff being mounted
 in the initrd for people doing live media/install discs, which I
 really don't think we can/should cover by using an explicit list.

Well, everything that this list would declare is that /, /etc, /usr (and
maybe very few others) are the bits that systemd requires to be
mounted when the host's systemd is first invoked. Where it is mounted
from, and in which order would be up to the distros, but I'd really
would like to make it clear that these three dirs *must* be valid when
the host systemd initializes.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Colin Walters
On Wed, 2013-09-11 at 16:31 +0200, Lennart Poettering wrote:

 Well, everything that this list would declare is that /, /etc, /usr (and
 maybe very few others) are the bits that systemd requires to be
 mounted when the host's systemd is first invoked. Where it is mounted
 from, and in which order would be up to the distros, but I'd really
 would like to make it clear that these three dirs *must* be valid when
 the host systemd initializes.

That makes total sense!  But my concern is more about *unmounting*.  So
let's say that an initramfs uses some special filesystem for /etc that
causes it be a mountpoint; for example, it's backed by a special NVRAM
device.

I think systemd should just assume that the initramfs will take care of
unmounting it, and not attempt to unmount it gracefully by default,
i.e. save it until the final kill spree.  And more generally for all
filesystems that were mounted by the initramfs.


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


[systemd-devel] [PATCH 2/3] util, utf8: new wellipsize and wellipsize_mem that take into account multi-byte characters

2013-09-11 Thread Shawn Landden
This version counts all multibyte characters as 1 width, not taking into
account double width cjk characters and zerowidth characters
---
 src/shared/util.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index b791433..c6375e5 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -3310,14 +3310,14 @@ char *ascii_ellipsize_mem(const char *s, size_t 
old_length, size_t new_length, u
 continue;
 
 memcpy(r, s, x);
-r[x] = '.';
-r[x+1] = '.';
-r[x+2] = '.';
+r[x] = 0xe2;
+r[x+1] = 0x80;
+r[x+2] = 0xa6;
 
 for (j=(x+3);(unsigned char)s[j]  0x80;j++)
 continue;
 
-memcpy(r + x + 3,
+memcpy(r + x + 1,
s + old_length - (new_length - j),
new_length - j);
 
-- 
1.8.4.rc3

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


Re: [systemd-devel] [PATCH] util, utf8: recognize wide characters in wellipsize_mem()

2013-09-11 Thread Shawn Landden
 Original Message 
 From: Zbigniew Jędrzejewski-Szmek 
 To: shawnland...@gmail.com
CC: systemd-devel@lists.freedesktop.org, Shawn Landden 
 Sent: Tue, Sep 10, 2013, 08:59
 Subject: Re: [systemd-devel] [PATCH] util, utf8: recognize wide characters in 
wellipsize_mem()
Hi Shawn,
thank you for attacking this, and sorry for the long delay in answering.
I think that the approach of copying working code from elsewhere for this
is right, but I think it should go into its own file, so that two coding
styles are not mixed.The functions come from the same original source however 
(same two files in glib) so I think they should go together, perhaps the older
take functions should be transfered back to their original style? 

Also, can those new functions replace normal ellipsize and ellipsize_mem,
so that we have support everywhere?renamed old to ascii_* 

e = new0(char, new_length*4  old_length ? new_length*4 : old_length);

→ we have a min macro

fixed 
There are some compilation warnings:

../src/shared/utf8.c: In function 'unichar_iswide':
../src/shared/utf8.c:435:9: warning: passing argument 1 of 'bsearch' makes 
pointer from integer without a cast [enabled by default]
interval_compare))
^
In file included from ../src/shared/utf8.c:51:0:
/usr/include/stdlib.h:754:14: note: expected 'const void *' but argument is of 
type 'long int'
extern void *bsearch (const void *__key, const void *__base,

fixed 
../src/shared/util.c: In function 'wellipsize_mem':
../src/shared/util.c:3353:9: warning: array subscript has type 'char' 
[-Wchar-subscripts]
for (i = (char *)s;k  x;i = utf8_next_char(i)) {
^
../src/shared/util.c:3380:17: warning: array subscript has type 'char' 
[-Wchar-subscripts]
i = utf8_next_char(i);
^not sure how to fix this,I am iterating over a pointer to char, but i am not 
evaluating it (it is a warning about signed vs unsigned char.) 

and valgrind finds some leaks:

% valgrind --leak-check=full build/.libs/test-wellipsize 
==19953== 
==19953== HEAP SUMMARY:
==19953== in use at exit: 1,379 bytes in 6 blocks
==19953==   total heap usage: 6 allocs, 0 frees, 1,379 bytes allocated
==19953== 
==19953== 81 bytes in 1 blocks are definitely lost in loss record 1 of 6
==19953==at 0x4A08121: calloc (in 
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19953==by 0x400F57: ellipsize_mem (util.c:3300)
==19953==by 0x401082: wellipsize_mem (util.c:3336)
==19953==by 0x40122A: wellipsize (util.c:3388)
==19953==by 0x400CFF: test_one (test-wellipsize.c:28)
==19953==by 0x400D4C: main (test-wellipsize.c:37)
...

I think it was just my lazy test, which I fixed, but I am on ARM, so let me 
know if this persists on amd64
On Wed, Aug 28, 2013 at 03:58:29PM -0700, Shawn wrote:
here is the test runner I am using, doesn't really make sense to add this
to the tree as it has to be visually inspected
I think it is still useful, since we don't have anything better for now. Anyway,
we have a bunch of tests which can only be run manually. Your test is certainly
good enough for valgrind testing and visual inspection, so it should go in.

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


[systemd-devel] [PATCH 1/3] util: ellipsize_mem: do not print partial utf-8 characters

2013-09-11 Thread Shawn Landden
---
 Makefile.am|   7 +++
 TODO   |   4 --
 src/shared/utf8.c  | 120 +
 src/shared/utf8.h  | 100 +
 src/shared/util.c  |  83 +--
 src/shared/util.h  |   3 ++
 src/test/test-wellipsize.c |  42 
 7 files changed, 351 insertions(+), 8 deletions(-)
 create mode 100644 src/test/test-wellipsize.c

diff --git a/Makefile.am b/Makefile.am
index cdbfdea..8813299 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1124,6 +1124,7 @@ tests += \
test-unit-file \
test-util \
test-date \
+   test-wellipsize \
test-sleep \
test-replace-var \
test-sched-prio \
@@ -1302,6 +1303,12 @@ test_date_SOURCES = \
 test_date_LDADD = \
libsystemd-core.la
 
+test_wellipsize_SOURCES = \
+src/test/test-wellipsize.c
+
+test_wellipsize_LDADD = \
+libsystemd-core.la
+
 test_sleep_SOURCES = \
src/test/test-sleep.c
 
diff --git a/TODO b/TODO
index fe305ec..a77ebe5 100644
--- a/TODO
+++ b/TODO
@@ -19,10 +19,6 @@ Bugfixes:
 
 * properly handle .mount unit state tracking when two mount points are stacked 
one on top of another on the exact same mount point.
 
-* ellipsize_mem must take into account multi-byte unicode characters, and
-  - make the resulting line the requested number of *characters*, not *bytes*,
-  - avoid truncuating multi-byte sequences in the middle.
-
 * When we detect invalid UTF-8, we cant't use it in an error message:
   log...(Path is not UTF-8 clean, ignoring assignment: %s, rvalue);
 
diff --git a/src/shared/utf8.c b/src/shared/utf8.c
index 655cc77..a9308b5 100644
--- a/src/shared/utf8.c
+++ b/src/shared/utf8.c
@@ -22,6 +22,11 @@
 /* This file is based on the GLIB utf8 validation functions. The
  * original license text follows. */
 
+/* gunicode.h - Unicode manipulation functions
+ *
+ *  Copyright (C) 1999, 2000 Tom Tromey
+ *  Copyright 2000, 2005 Red Hat, Inc.
+ */
 /* gutf8.c - Operations on UTF-8 strings.
  *
  * Copyright (C) 1999 Tom Tromey
@@ -317,3 +322,118 @@ char *utf16_to_utf8(const void *s, size_t length) {
 
 return r;
 }
+
+/**
+ * g_utf8_prev_char:
+ * @p: a pointer to a position within a UTF-8 encoded string
+ *
+ * Finds the previous UTF-8 character in the string before @p.
+ *
+ * @p does not have to be at the beginning of a UTF-8 character. No check
+ * is made to see if the character found is actually valid other than
+ * it starts with an appropriate byte. If @p might be the first
+ * character of the string, you must use g_utf8_find_prev_char() instead.
+ *
+ * Return value: a pointer to the found character.
+ **/
+char *
+utf8_prev_char (const char *p)
+{
+  while (1)
+{
+  p--;
+  if ((*p  0xc0) != 0x80)
+   return (char *)p;
+}
+}
+
+/**
+ * g_utf8_get_char:
+ * @p: a pointer to Unicode character encoded as UTF-8
+ *
+ * Converts a sequence of bytes encoded as UTF-8 to a Unicode character.
+ * If @p does not point to a valid UTF-8 encoded character, results are
+ * undefined. If you are not sure that the bytes are complete
+ * valid Unicode characters, you should use g_utf8_get_char_validated()
+ * instead.
+ *
+ * Return value: the resulting character
+ **/
+unichar
+utf8_get_char (const char *p)
+{
+  int i, mask = 0, len;
+  unichar result;
+  unsigned char c = (unsigned char) *p;
+
+  UTF8_COMPUTE (c, mask, len);
+  if (len == -1)
+return (unichar)-1;
+  UTF8_GET (result, p, i, mask, len);
+
+  return result;
+}
+
+struct Interval
+{
+  unichar start, end;
+};
+
+static int
+interval_compare (const void *key, const void *elt)
+{
+  unichar c = (unichar) (long) (key);
+  struct Interval *interval = (struct Interval *)elt;
+
+  if (c  interval-start)
+return -1;
+  if (c  interval-end)
+return +1;
+
+  return 0;
+}
+
+/*
+ * NOTE:
+ *
+ * The tables for g_unichar_iswide() and g_unichar_iswide_cjk() are
+ * generated from the Unicode Character Database's file
+ * extracted/DerivedEastAsianWidth.txt using the gen-iswide-table.py
+ * in this way:
+ *
+ *   ./gen-iswide-table.py  path/to/ucd/extracted/DerivedEastAsianWidth.txt | 
fmt
+ *
+ * Last update for Unicode 6.0.
+ */
+
+/**
+ * g_unichar_iswide:
+ * @c: a Unicode character
+ *
+ * Determines if a character is typically rendered in a double-width
+ * cell.
+ *
+ * Return value: %TRUE if the character is wide
+ **/
+bool
+unichar_iswide (unichar c)
+{
+  /* See NOTE earlier for how to update this table. */
+  static const struct Interval wide[] = {
+{0x1100, 0x115F}, {0x2329, 0x232A}, {0x2E80, 0x2E99}, {0x2E9B, 0x2EF3},
+{0x2F00, 0x2FD5}, {0x2FF0, 0x2FFB}, {0x3000, 0x303E}, {0x3041, 0x3096},
+{0x3099, 0x30FF}, {0x3105, 0x312D}, {0x3131, 0x318E}, {0x3190, 0x31BA},
+{0x31C0, 0x31E3}, {0x31F0, 0x321E}, {0x3220, 0x3247}, {0x3250, 0x32FE},
+{0x3300, 0x4DBF}, {0x4E00, 0xA48C}, {0xA490, 0xA4C6}, {0xA960, 0xA97C},
+

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 10:46, Colin Walters (walt...@verbum.org) wrote:

 
  Well, everything that this list would declare is that /, /etc, /usr (and
  maybe very few others) are the bits that systemd requires to be
  mounted when the host's systemd is first invoked. Where it is mounted
  from, and in which order would be up to the distros, but I'd really
  would like to make it clear that these three dirs *must* be valid when
  the host systemd initializes.
 
 That makes total sense!  

BTW, I started putting this together:

http://www.freedesktop.org/wiki/Software/systemd/FileHierarchy/

Which is supposed to document the actual requirements systemd
makes. i.e. that subset of the FHS that systemd actually cares
about. Suggestions welcome.

 But my concern is more about *unmounting*.  So
 let's say that an initramfs uses some special filesystem for /etc that
 causes it be a mountpoint; for example, it's backed by a special NVRAM
 device.

Well, but /etc would be one of those which would be listed in that OS
resource dir list... 

 I think systemd should just assume that the initramfs will take care of
 unmounting it, and not attempt to unmount it gracefully by default,
 i.e. save it until the final kill spree.  And more generally for all
 filesystems that were mounted by the initramfs.

Note that killing spree is done before we jump back into the
initramfs...

So there's three steps:

1. normal unmounting using mount units
2. killing spree unmounting of left-overs in a tight loop based on 
/proc/self/mountinfo
3. initrd unmounting of remaining OS resource dirs

Where 3 is optional, and done only on initrds which implement this.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline

2013-09-11 Thread Lennart Poettering
On Mon, 19.08.13 00:15, Tom Gundersen (t...@jklm.no) wrote:

 The main usecase for this is to make it possible to use cryptsetup in
 the initrd without it having to include a host-specific /etc/crypttab.

Hmm, I contrast to Harald I think adding luks.options= would actually be
OK.

I don't think we really strictly need something here that can cover
everything. I think it is OK if we have a minimal, easy,
reduced-functionality way to configure luks disks via the kernel cmdline
and a full-blown one with /etc/crypttab. It's a bit weird but I think
not totally incomprehensible to users. Hence adding luks.options= and
rd.luks.options= sounds like a very simple minimal addition here.

If people really want per-device options, then one day we could on top
of this just extend the preexisting luks.uuid= syntax to also take a key
file and an option string via some ; based syntax (i.e. taking up
Harald's idea, but voerloading it into luks.uuid=).

Or in other words, have this syntax now:

   luks.uuid=UUID
   luks.key=KEY
   luks.options=OPTIONS

(and the allow discards thing would be subsumed under luks.options)

And then one day maybe optionally allow this syntax too:

   luks.uuid=UUID;KEY;OPTIONS

Does that make sense?

So yeah, Tom, I think you patch looks good and should go in (but please
update kernel-command-line(7) too), unless Harald violently opposes? ;-)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] brightness in tmpfiles.d

2013-09-11 Thread Lennart Poettering
On Mon, 12.08.13 22:40, Christian Hesse (l...@eworm.de) wrote:

 Hello everybody,
 
 I have a file /etc/tmpfiles.d/brightness.conf containing this line:
 
 w /sys/class/backlight/acpi_video0/brightness - - - - 10
 
 This used to set the brightness on boot, but broke lately. The path is
 correct, so I assume this is a race condition. Any chance to get this work
 again?

Just a quick follow-up on this. systemd git now includes a tiny tool to
save/restore the backlight late at shutdown/early at boot, similar to
how we handle random seed already. This should make all manual dealing
with tmpfiles/udev rules unnecessary, and just make this all work.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Colin Walters
On Wed, 2013-09-11 at 16:55 +0200, Lennart Poettering wrote:

 Well, but /etc would be one of those which would be listed in that OS
 resource dir list... 

Sure, it makes total sense for systemd to hard require it (and the
others) to be mounted; again I'm just more interested in the unmounting.

 So there's three steps:
 
 1. normal unmounting using mount units

Trying to do this with current ostree is causing problems, and similarly
with special LiveCD setups, and as danpb said a while ago, container
cases where the external system mounts resources for the container.

 2. killing spree unmounting of left-overs in a tight loop based on 
 /proc/self/mountinfo

This part works fine for me.

 3. initrd unmounting of remaining OS resource dirs

And I don't need this myself; having to keep the initramfs around just
to invoke umount() would be kind of lame when systemd can just do it
itself easily enough after all processes other than pid 1 are gone.

So step 3 is only needed AIUI for network/daemon-controlled root
filesystem (per
http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/ )



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


Re: [systemd-devel] [PATCH] cryptsetup: Retry indefinitely if tries=0 option has been set.

2013-09-11 Thread Lennart Poettering
On Sun, 18.08.13 18:24, Thomas Bächler (tho...@archlinux.org) wrote:

 When running from initrd, entering a wrong passphrase usually means that
 you cannot boot. Therefore, we allow trying indefinitely.
 ---
 
 This is useful together with Tom's latest patch. On my system, I use
  rd.luks.options=allow-discards,tries=0
 so unless booting succeeds, I will be prompted for a passphrase
 indefinitely.

Thanks! Applied!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [REMINDER] Next Week systemd Hackfest in New Orleans! (colocated with LinuxCon/LPC)

2013-09-11 Thread Lennart Poettering
Heya!

Next week we'll have another two day systemd hackfest, this time in New
Orleans, co-located with LinuxCon/Linux Plumbers Conference.

https://plus.google.com/u/0/events/ce60f0rq4lldbti9qgg0u4j8rbc

You are invited!

It starts on monday morning 9am, at the Grand Hyatt, Room Imperial
11. To enter you probably need a LinuxCon registration, please contact
Harald Hoyer who might be able to help you if you don't have one.

(Would be cool to indicate on the Google+ event if you are coming, so
that we have an idea how many people to expect!)

Also note that there's going to be a BootInit miniconf at LPC with lots
of systemd related topics. On top of that, I'll do a presentation about
Resource Management with systemd at LinuxCon.

See you in New Orleans!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Impact when not loading ipv6 and autofs kernel module ...

2013-09-11 Thread Lennart Poettering
On Wed, 14.08.13 16:43, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote:

 For what is systemd using the loopback so that it has to set it up so
 early? Is there any impact when I'm setting up the loopback later. We
 are probably in a situation where we need ipv4 for general purposes
 and ipv6 for only special ones. So we'd like to set up ipv6 later for
 performance reasons, which concerns especially the module loading.

Humm, I doubt that initializing IPv6 early will really slow things down
for you.

The reason we initialize the loopback device this early is simply that
most userspace code simply expects it to be there, and working, and it's
absolutely trivial and fast to do, so we just do it by default, so that
it just works and is nothing the user can manually configure and where
we then have to parse configuraiton files and have another distinct
component running late in boot dealing with this and so on...

It's really something we want to be quick, and always done and
non-configurable and since its a triviality to do we just do it in PID 1...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] [RFC] Make reboot to support additional command

2013-09-11 Thread Lennart Poettering
On Tue, 13.08.13 03:01, WaLyong Cho (fyd0...@gmail.com) wrote:

 From: WaLyong Cho walyong@samsung.com
 
 reboot syscall can be performed with additional argument. In some of
 system, this functionality can be useful to ask next boot mode to
 bootloader.

Hmm, interesting stuff. 

 @@ -5200,9 +5204,19 @@ static int halt_parse_argv(int argc, char *argv[]) {
  }
  }
  

Note that halt is not called during normal shutdown, but is only a
compat fallback for the old sysv halt command. If you want this to
work we probably need to come up with a way to pass the string from
systemctl to the final systemd-shutdown process.

(A bit of background: systemctl normally will just tell PID 1 to
shutdown cleanly, via D-Bus. As last step of that PID 1 will execute the
special systemd-shutdown binary -- which will then also run as PID 1 --
which will do some final shutdown steps and then invoke the reboot()
syscall -- see src/core/shutdown.c for details)

So, before we continue with this, could you point me to some
docs/commits/code which explain a bit how the new reboot() syscall
semantics work? i.e. what the possible params are and such?

One way to implement this could be to add add a new parameter to
systemctl which is written to /run/systemd/reboot-param or so if
specified. systemd-shutdown would then look for that file and pass it to
the reboot() syscall.

 -if (optind  argc) {
 -log_error(Too many arguments.);
 -return -EINVAL;
 +if (arg_action == ACTION_REBOOT) {
 +/* reboot allow just one argument for his command string */
 +if (optind+1 == argc)
 +arg_reboot = strdup(argv[argc-1]);
 +else if (optind+1  argc) {
 +log_error(Too many arguments.);
 +return -EINVAL;
 +}
 +} else {
 +if (optind  argc) {
 +log_error(Too many arguments.);
 +return -EINVAL;
 +}
  }
  
  return 1;
 @@ -5949,7 +5963,11 @@ static _noreturn_ void halt_now(enum action a) {
  
  case ACTION_REBOOT:
  log_info(Rebooting.);
 -reboot(RB_AUTOBOOT);
 +if (arg_reboot)
 +syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, 
 LINUX_REBOOT_MAGIC2,
 +LINUX_REBOOT_CMD_RESTART2, arg_reboot);
 +else
 +reboot(RB_AUTOBOOT);
  break;
  
  default:


Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 12:00, Colin Walters (walt...@verbum.org) wrote:

 
 On Wed, 2013-09-11 at 16:55 +0200, Lennart Poettering wrote:
 
  Well, but /etc would be one of those which would be listed in that OS
  resource dir list... 
 
 Sure, it makes total sense for systemd to hard require it (and the
 others) to be mounted; again I'm just more interested in the unmounting.
 
  So there's three steps:
  
  1. normal unmounting using mount units
 
 Trying to do this with current ostree is causing problems, and similarly
 with special LiveCD setups, and as danpb said a while ago, container
 cases where the external system mounts resources for the container.

Can you elaborate on this? Why wouldn't it suffice to drop in a .mount
unit for the mount in question which excludes the mount point from being
unmounted with this?

  2. killing spree unmounting of left-overs in a tight loop based on 
  /proc/self/mountinfo
 
 This part works fine for me.
 
  3. initrd unmounting of remaining OS resource dirs
 
 And I don't need this myself; having to keep the initramfs around just
 to invoke umount() would be kind of lame when systemd can just do it
 itself easily enough after all processes other than pid 1 are gone.
 
 So step 3 is only needed AIUI for network/daemon-controlled root
 filesystem (per
 http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/ )

Not just that. Also for complex local storage where some block device
needs to be dissambled before we power down...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH v2] sd-login: add a public accessor for the VT number

2013-09-11 Thread Giovanni Campagna
From: Giovanni Campagna gcamp...@redhat.com

The VT number was already part of the DBus API, but was not
exposed in the C API.
---
 man/sd_session_is_active.xml   | 13 +
 src/login/libsystemd-login.sym |  5 +
 src/login/sd-login.c   | 18 ++
 src/systemd/sd-login.h |  3 +++
 4 files changed, 39 insertions(+)

diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml
index e89117d..9362fbc 100644
--- a/man/sd_session_is_active.xml
+++ b/man/sd_session_is_active.xml
@@ -52,6 +52,7 @@
 refnamesd_session_get_class/refname
 refnamesd_session_get_display/refname
 refnamesd_session_get_tty/refname
+refnamesd_session_get_vt/refname
 refpurposeDetermine state of a specific session/refpurpose
 /refnamediv
 
@@ -111,6 +112,12 @@
 paramdefconst char* 
parametersession/parameter/paramdef
 paramdefchar** 
parametertty/parameter/paramdef
 /funcprototype
+
+funcprototype
+funcdefint 
functionsd_session_get_vt/function/funcdef
+paramdefconst char* 
parametersession/parameter/paramdef
+paramdefunsigned* 
parametervt/parameter/paramdef
+/funcprototype
 /funcsynopsis
 /refsynopsisdiv
 
@@ -202,6 +209,12 @@
 
citerefentryrefentrytitlefree/refentrytitlemanvolnum3/manvolnum/citerefentry
 call after use./para
 
+parafunctionsd_session_get_vt()/function
+may be used to determine the VT number of the
+session identified by the specified session
+identifier. This function will return an error if
+the seat does not support VTs./para
+
 paraIf the varnamesession/varname parameter of
 any of these functions is passed as
 constantNULL/constant the operation is executed
diff --git a/src/login/libsystemd-login.sym b/src/login/libsystemd-login.sym
index 0720704..7512ef5 100644
--- a/src/login/libsystemd-login.sym
+++ b/src/login/libsystemd-login.sym
@@ -80,3 +80,8 @@ LIBSYSTEMD_LOGIN_205 {
 global:
 sd_pid_get_slice;
 } LIBSYSTEMD_LOGIN_203;
+
+LIBSYSTEMD_LOGIN_206 {
+global:
+sd_session_get_vt;
+} LIBSYSTEMD_LOGIN_205;
\ No newline at end of file
diff --git a/src/login/sd-login.c b/src/login/sd-login.c
index 0658792..6a6e04e 100644
--- a/src/login/sd-login.c
+++ b/src/login/sd-login.c
@@ -347,6 +347,24 @@ _public_ int sd_session_get_tty(const char *session, char 
**tty) {
 return session_get_string(session, TTY, tty);
 }
 
+_public_ int sd_session_get_vt(const char *session, unsigned *vtnr) {
+_cleanup_free_ char *vtnr_string;
+char *end;
+int r;
+unsigned long v;
+
+r = session_get_string(session, VTNr, vtnr_string);
+if (r  0)
+return r;
+
+v = strtoul(vtnr_string, end, 10);
+if (end == vtnr_string || *end)
+return -EINVAL;
+
+*vtnr = v;
+return 0;
+}
+
 _public_ int sd_session_get_service(const char *session, char **service) {
 return session_get_string(session, SERVICE, service);
 }
diff --git a/src/systemd/sd-login.h b/src/systemd/sd-login.h
index e37aeda..c5837f0 100644
--- a/src/systemd/sd-login.h
+++ b/src/systemd/sd-login.h
@@ -124,6 +124,9 @@ int sd_session_get_display(const char *session, char 
**display);
 /* Determine the TTY of this session. */
 int sd_session_get_tty(const char *session, char **display);
 
+/* Determine the VT number of this session. */
+int sd_session_get_vt(const char *session, unsigned *vtnr);
+
 /* Return active session and user of seat */
 int sd_seat_get_active(const char *seat, char **session, uid_t *uid);
 
-- 
1.8.3.1

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


Re: [systemd-devel] [PATCH v2] sd-login: add a public accessor for the VT number

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 18:48, Giovanni Campagna (scampa.giova...@gmail.com) wrote:

 From: Giovanni Campagna gcamp...@redhat.com
 
 The VT number was already part of the DBus API, but was not
 exposed in the C API.

Thanks! Applied with minor changes (replaced strtoul with our own
safe_atou() which is a ton easier to use).

 ---
  man/sd_session_is_active.xml   | 13 +
  src/login/libsystemd-login.sym |  5 +
  src/login/sd-login.c   | 18 ++
  src/systemd/sd-login.h |  3 +++
  4 files changed, 39 insertions(+)
 
 diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml
 index e89117d..9362fbc 100644
 --- a/man/sd_session_is_active.xml
 +++ b/man/sd_session_is_active.xml
 @@ -52,6 +52,7 @@
  refnamesd_session_get_class/refname
  refnamesd_session_get_display/refname
  refnamesd_session_get_tty/refname
 +refnamesd_session_get_vt/refname
  refpurposeDetermine state of a specific 
 session/refpurpose
  /refnamediv
  
 @@ -111,6 +112,12 @@
  paramdefconst char* 
 parametersession/parameter/paramdef
  paramdefchar** 
 parametertty/parameter/paramdef
  /funcprototype
 +
 +funcprototype
 +funcdefint 
 functionsd_session_get_vt/function/funcdef
 +paramdefconst char* 
 parametersession/parameter/paramdef
 +paramdefunsigned* 
 parametervt/parameter/paramdef
 +/funcprototype
  /funcsynopsis
  /refsynopsisdiv
  
 @@ -202,6 +209,12 @@
  
 citerefentryrefentrytitlefree/refentrytitlemanvolnum3/manvolnum/citerefentry
  call after use./para
  
 +parafunctionsd_session_get_vt()/function
 +may be used to determine the VT number of the
 +session identified by the specified session
 +identifier. This function will return an error if
 +the seat does not support VTs./para
 +
  paraIf the varnamesession/varname parameter of
  any of these functions is passed as
  constantNULL/constant the operation is executed
 diff --git a/src/login/libsystemd-login.sym b/src/login/libsystemd-login.sym
 index 0720704..7512ef5 100644
 --- a/src/login/libsystemd-login.sym
 +++ b/src/login/libsystemd-login.sym
 @@ -80,3 +80,8 @@ LIBSYSTEMD_LOGIN_205 {
  global:
  sd_pid_get_slice;
  } LIBSYSTEMD_LOGIN_203;
 +
 +LIBSYSTEMD_LOGIN_206 {
 +global:
 +sd_session_get_vt;
 +} LIBSYSTEMD_LOGIN_205;
 \ No newline at end of file
 diff --git a/src/login/sd-login.c b/src/login/sd-login.c
 index 0658792..6a6e04e 100644
 --- a/src/login/sd-login.c
 +++ b/src/login/sd-login.c
 @@ -347,6 +347,24 @@ _public_ int sd_session_get_tty(const char *session, 
 char **tty) {
  return session_get_string(session, TTY, tty);
  }
  
 +_public_ int sd_session_get_vt(const char *session, unsigned *vtnr) {
 +_cleanup_free_ char *vtnr_string;
 +char *end;
 +int r;
 +unsigned long v;
 +
 +r = session_get_string(session, VTNr, vtnr_string);
 +if (r  0)
 +return r;
 +
 +v = strtoul(vtnr_string, end, 10);
 +if (end == vtnr_string || *end)
 +return -EINVAL;
 +
 +*vtnr = v;
 +return 0;
 +}
 +
  _public_ int sd_session_get_service(const char *session, char **service) {
  return session_get_string(session, SERVICE, service);
  }
 diff --git a/src/systemd/sd-login.h b/src/systemd/sd-login.h
 index e37aeda..c5837f0 100644
 --- a/src/systemd/sd-login.h
 +++ b/src/systemd/sd-login.h
 @@ -124,6 +124,9 @@ int sd_session_get_display(const char *session, char 
 **display);
  /* Determine the TTY of this session. */
  int sd_session_get_tty(const char *session, char **display);
  
 +/* Determine the VT number of this session. */
 +int sd_session_get_vt(const char *session, unsigned *vtnr);
 +
  /* Return active session and user of seat */
  int sd_seat_get_active(const char *seat, char **session, uid_t *uid);
  


Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] stop+start of nspawn scope aborts: 's-state == SCOPE_DEAD'

2013-09-11 Thread Lennart Poettering
On Mon, 12.08.13 19:41, Marti Raudsepp (ma...@juffo.org) wrote:

 Hi list,
 
 I hit a bug today in the scope unit support. Reproducible like this:
 
 systemd-nspawn -bD /srv/subarch
 systemctl stop machine-subarch.scope
 systemctl start machine-subarch.scope
 
 I wasn't sure whether start would do anything or not so I gave it a
 shot, but it turned out to crash the host systemd with:
 
 Assertion 's-state == SCOPE_DEAD' failed at src/core/scope.c:246,
 function scope_start(). Aborting
 
 Tested with systemd 206 as well as current git master
 (206.103.g631c922) on Arch Linux.
 
 /srv/subarch is a plain Arch Linux installation created according to:
 https://wiki.archlinux.org/index.php/Arch_systemd_container

OK, I fixed the crash, but this is incomplete as we really should
disallow multipl start requests on the same scope. I have added a TODO
list item for the latter now.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] User journal corrupted or uncleanly shut down, renaming and replacing

2013-09-11 Thread Lennart Poettering
On Mon, 12.08.13 14:58, Pedro Francisco (pedrogfranci...@gmail.com) wrote:

 Hi,
 Systemd complains frequently about corrupted journal. Do note: I don't
 have the default mount options.
 
 $ dmesg |grep corrupte
 [   51.766346] systemd-journald[181]: File
 /var/log/journal/06fde5edd4974fa9a343215f093f5aae/user-42.journal
 corrupted or uncleanly shut down, renaming and replacing.
 
 $ sudo rpm -qa systemd
 systemd-204-9.fc19.i686
 
 $ cat /proc/mounts
 (...)
 /dev/sda6 / ext4 rw,seclabel,noatime,nobarrier 0 0
 (...)
 
 In addition, I have an issue related to systemd-journald stopping
 logging after a while if there are lots of output, as I mentioned on
 http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/12373 titled
 Journald stops logging when lots of output .
 
 Do you think:
 a) mount options can affect systemd logging and
 b) these two issues (the one on this email about corrupted journal and
 the one on the linked thread about journald crashing when there are
 lots of output) may be related?
 
 Thanks in Advance,

My guess is that for some reason the file systems are not properly
unmounted during shutdown. Can you maybe try to get shutdown logs as
described here?

http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Are you using LVM or something else weird? Are you using Dracut? Does
the issue go away if you drop nobarrier from your mount options?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.

2013-09-11 Thread Lennart Poettering
On Mon, 12.08.13 01:44, Tony Seo (tonys...@gmail.com) wrote:

 I sincerely ask you a relationship between device unit and boot time if I
 remove unnecessary device unit.
 
 And also, can I ask you detail process of  making device unit by systemd?
 (I alread read the manual page related with device unit)

the kernel creates a directory in /sys for each device popping up. udev
then maintains some additional metadata for all those devices. One part
of that metadata is a tag that might be on select devices called
systemd. If a a device is tagged like that it will also show up as
.device unit systemd. By default block devices, ttys and a few others
are tagged like that. Some services need to wait for some block devices
before they can be run (for example, fsck instances need to wait for
their respective block devices to show up before they can be started),
and this is implemented via dependencies to these device units.

Device units hence are not really something active in themselves, they
just reflect as units state of another component of the OS (which is
udev/kernel).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Generic unit file to run command on shutdown impossible?

2013-09-11 Thread Lennart Poettering
On Sat, 10.08.13 15:59, David Mazieres expires 2013-11-08 PST 
(mazieres-rq54ugpgb894kkmq2swhjjb...@temporary-address.scs.stanford.edu) wrote:

 I'm trying to do something that I hope is relatively simple, namely to
 run a simple kexec -l ... command on system shutdown before the /boot
 file system is unmounted.  I'm trying this on two different machines,
 both of which are running current versions of arch linux with systemd
 204.  The machines are configured very similarly, except that one has
 a serial console and some NFS mounts, while the other does not.
 Unfortunately, I cannot find a single script that works on both
 machines.
 
 On the machine with a serial console, the following unit file seems to
 work (in /etc/systemd/system/kexec-load@.service, enabled with
 systemctl enable kexec-load@linux).  This is a slightly modified
 version of a suggestion on the arch linux wiki:

It's usually a better idea to have this as unit that starts at bootup,
and stops at shutdown, rather than one that starts at shutdown. This is
because of the orderign semantics of start and stop jobs. The general
rule here is that if one job is started and one is stopped and there is
either After= or Before= defined between their two units, then the Stop=
is always run first, and the start second, regardless whether After or
Before was used.

After/Before= hence only declare the ordering between two start jobs,
and the ordering between two stop jobs (where the rule is that it is the
inverse of the start order), but not between a start and a stop job.

This might be confusing, but not too difficult to grok I guess..

Effectively this means that you should define a RemainAfterExit=yes
service with ExecStart=/bin/true and ExecStop= set to what you want to
run at shutdown. The requirement to set an ExecStart= is something we
will lift soon, but for now it is required.

I hope this makes some sense?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv4] tmpfiles, man: Add xattr support to tmpfiles

2013-09-11 Thread Lennart Poettering
On Thu, 08.08.13 13:54, Maciej Wereski (m.were...@partner.samsung.com) wrote:

 +value = strreplace(tmp, \\\, \);
 +if (!value)
 +return log_oom();

This looks like a job for cunescape() or so?

 +n = strlen(value);
 +if (i-type == CREATE_SYMLINK) {
 +if (lsetxattr(path, name, value, n+1, 0)  0) {
 +log_error(Setting extended attribute %s=%s 
 on symlink %s failed: %m, name, value, path);
 +return -errno;
 +}
 +}
 +else if (setxattr(path, name, value, n+1, 0)  0) {
 +log_error(Setting extended attribute %s=%s on %s 
 failed: %m, name, value, path);
 +return -errno;
 +}
 +}
 +return 0;
 +#else
 +(void)i;
 +(void)path;
 +log_error(Setting extended attributes requested, but tmpfiles was 
 compiled without XATTR support!);
 +return -ENOTSUP;

If I follow the control flow correctly then this message would be
generated for *all* entries if XATTR support is not compiled in,
regardless whether xattrs shall actually be set... This part should come
after the early-return check whether the xattr list is actually empty...

 +xattr = new0(char, strlen(i-argument)+1);
 +if (!xattr)
 +return log_oom();
 +
 +tmp = strv_split(i-argument, WHITESPACE);
 +if (!tmp)
 +return log_oom();
 +
 +for (n = 0; n  strv_length(tmp); ++n) {

strv_length() is relatively expensive (O(n)), please cache the result.


 +len = strlen(tmp[n]);
 +strncpy(xattr, tmp[n], len+1);
 +p = strchr(xattr, '=');
 +if (!p) {
 +log_error(%s: Attribute has incorrect format., 
 i-path);
 +return -EBADMSG;
 +}
 +if (p[1] == '\') {
 +while (true) {
 +if (!p)
 +p = tmp[n];
 +else
 +p += 2;
 +p = strchr(p, '\');
 +if (p  xattr[p-xattr-1] != '\\')
 +break;
 +p = NULL;
 +++n;
 +if (n == strv_length(tmp))
 +break;
 +len += strlen(tmp[n]) + 1;
 +strncat(xattr,  , 1);
 +strncat(xattr, tmp[n], len);
 +}
 +}
 +strstrip(xattr);

Hmm, this also is a job for split_pair and cunescape, no? Or am I confused?

Otherwise looks fine!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Inconsistencies in the systemd.mount documentation

2013-09-11 Thread Thomas Bächler
Am 11.09.2013 17:08, schrieb Lennart Poettering:
 Using FsckPassNo= as a way to add that dep sucks really, because the
 ordering it does is stupid and fsck can do the ordering internally
 anyway these days...

So, shouldn't systemd-fstab-generator omit that entirely, too? Instead,
every mount with pass!=0 should get the correct fsck dependency.

 Automatically adding deps to fsck for all mounts is wrong too, since
 only some block-based file systems need fsck and it would suck having to
 carry a whitelist for thos in systemd.

Fair enough.





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] [RFC v1] crontab-generator: new generator for crontab(5) support

2013-09-11 Thread Lennart Poettering
On Thu, 08.08.13 14:50, Shawn (shawnland...@gmail.com) wrote:

I am not convinced this is a really good idea. From my perspective at
least it appears that we should much rather just convert the crontabs
and that's it. Unlike sysv init scripts the number of crontab in use (at
least on Fedora) is relatively small, and very rare in third-party
packages.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Trying to turn off a UPS with home-made service unit

2013-09-11 Thread Lennart Poettering
On Sat, 10.08.13 17:02, Roger Price (ro...@rogerprice.org) wrote:

 I am new to systemd and I am trying to power off a UPS unit using a
 home-made service unit
 /lib/systemd/system/ups-delayed-shutdown.service running on openSUSE
 12.3.

So, it's a really bad idea to turn off UPS from userspace, simply
because you will race against the kernel's fs sync() code, and you
never know what will finish first: your UPS shutdown timeout or your fs
sync(). Doing this from userspace is hence racy.

If you want to use a hack like this then at least do it via the
/usr/lib/systemd/system-shutdown/ drop-in directory which is called very
late during shutdown. It will shorten the race window, but not erase it,
since the kernel will flush various buffers only after the reboot()
system call is invoked.

See systemd-shutdown(8) for details.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Inconsistencies in the systemd.mount documentation

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 20:04, Thomas Bächler (tho...@archlinux.org) wrote:

 Am 11.09.2013 17:08, schrieb Lennart Poettering:
  Using FsckPassNo= as a way to add that dep sucks really, because the
  ordering it does is stupid and fsck can do the ordering internally
  anyway these days...
 
 So, shouldn't systemd-fstab-generator omit that entirely, too? Instead,
 every mount with pass!=0 should get the correct fsck dependency.

Well, in classic fstab passno=0 means no fsck, passno!=0 means fsck. On
top of that the value of passno can be used to order things. We
honour those rules when we convert from fstab, and for that use
FsckPassNo=. That's why it is compat only... 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 1/3] systemctl: check for triggering units before calling StopUnit

2013-09-11 Thread Lennart Poettering
On Fri, 09.08.13 16:00, Michal Sekletar (msekl...@redhat.com) wrote:

Heya,

Hmm, so what I don't really like about this patch is that the stop might
have caused the triggering units also to go away via some deps. If we
check the triggers before executing the operations we will never take
that into account. (Note that so far the trigger message is delayed
after the job succeeded in order to make sure we can take the full
a-posteriori state into account).

So not sure, Zbigniew, do you have an opinion on this?

(Also, Michal, what about the other patches from this series, are they
still relevant? I amnot sure if you pulled them back or not, the thread
confused me)

Lennart

 
 From a62d3668fb2513b1ece827520d44d5b7cd560407 Mon Sep 17 00:00:00 2001
 From: Michal Sekletar msekl...@redhat.com
 Date: Thu, 8 Aug 2013 13:26:56 +0200
 Subject: [PATCH 1/3] systemctl: check for triggering units before calling
  StopUnit
 
 Rearranging the code in a way that we always check for triggers before
 we issue StopUnit D-Bus call. This will make behavior consistent,
 because triggers are always checked.
 
 https://bugzilla.redhat.com/show_bug.cgi?id=908690
 ---
  src/systemctl/systemctl.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)
 
 diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
 index 8ec1824..ee47841 100644
 --- a/src/systemctl/systemctl.c
 +++ b/src/systemctl/systemctl.c
 @@ -1980,6 +1980,16 @@ static int start_unit(DBusConnection *bus, char 
 **args) {
  return log_oom();
  }
  
 +/* When stopping units, warn if they can still be triggered by
 + * another active unit (socket, path, timer) */
 +if (!arg_quiet  streq(method, StopUnit)) {
 +if (one_name)
 +check_triggering_units(bus, one_name);
 +else
 +STRV_FOREACH(name, args+1)
 +check_triggering_units(bus, *name);
 +}
 +
  if (one_name) {
  ret = start_unit_one(bus, method, one_name, mode, error, s);
  if (ret  0)
 @@ -1998,16 +2008,6 @@ static int start_unit(DBusConnection *bus, char 
 **args) {
  r = wait_for_jobs(bus, s);
  if (r  0)
  return r;
 -
 -/* When stopping units, warn if they can still be triggered 
 by
 - * another active unit (socket, path, timer) */
 -if (!arg_quiet  streq(method, StopUnit)) {
 -if (one_name)
 -check_triggering_units(bus, one_name);
 -else
 -STRV_FOREACH(name, args+1)
 -check_triggering_units(bus, *name);
 -}
  }
  
  return ret;


Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Journald stops logging when lots of output

2013-09-11 Thread Lennart Poettering
On Sat, 03.08.13 23:14, Pedro Francisco (pedrogfranci...@gmail.com) wrote:

 (question migrated from t...@lists.fedoraproject.org )
 
 On Fedora 19, journald ( systemd-204-9.fc19.i686 ) stops logging. I
 had enabled lots of iwl3945 debugging ( various messages for each
 iwl3945 interaction -- modprobe iwl3945 debug=0x47ff ) throughout
 the night and the last thing `journalctl -b` has is:
 
 Ago 03 02:25:45 s2 systemd-journal[29414]: Allowing system journal
 files to grow to 1.4G.
 Ago 03 02:25:45 s2 systemd-journal[29414]: Journal started
 Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process
 exited, code=exited, status=1/FAILURE
 Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to
 Persistent Storage.
 Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process
 exited, code=killed, status=10/USR1
 Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to
 Persistent Storage.
 Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process
 exited, code=killed, status=10/USR1
 Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to
 Persistent Storage.
 Ago 03 02:25:45 s2 systemd-journal[29419]: Allowing system journal
 files to grow to 1.4G.
 Ago 03 02:25:45 s2 systemd-journal[29419]: Journal started
 Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process
 exited, code=exited, status=1/FAILURE
 Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to
 Persistent Storage.
 Ago 03 02:25:45 s2 systemd-journal[29423]: Allowing system journal
 files to grow to 1.4G.
 Ago 03 02:25:45 s2 systemd-journal[29423]: Journal started
 Ago 03 02:25:45 s2 systemd[1]: systemd-journald.service: main process
 exited, code=exited, status=1/FAILURE
 Ago 03 02:25:45 s2 systemd[1]: Started Trigger Flushing of Journal to
 Persistent Storage.
 
 It is now 10:35 and while dmesg has (lots) of new info, journalctl -f does 
 not.
 
 Any tips on what may be wrong?

Is this still a problem?

It seems journald dies for you for some reason. Is there a way how you
can reproduce the issue? If so, can you strace the journal daemon, then
reproduce it, and paste the last 100 strace lines somwhere before the
daemon exited? This should give us an indication what might have failed
that caused it to exit. 

(Of course, journald should not exit under any such circumstances, but
to find that we first need to track down why it does that currently).

Also, if you log using a tool like logger, does that get lost too
after the issue happens?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [Feature request] A way to native import /proc/cmdline within unit

2013-09-11 Thread Lennart Poettering
On Thu, 01.08.13 19:16, Jan Engelhardt (jeng...@inai.de) wrote:

 
 
 On Tuesday 2013-07-30 02:12, Gerardo Exequiel Pozzi wrote:
 
 In inside systemd unit, I want to avoid shell script if possible, using
 units only, doing things in a systemd way. Anyway for complex tasks
 where systemd does not fit, scripting seems to be necessary.
 
 The systemd way is not {avoiding shell scripts at all cost},
 but avoiding redundant code found in the many sysvinit scripts.
 At least, that is how I see it.

Yes. We want to deemphasize shell scripts, and get them out of the
default boot, but shell is incredibly useful otherwise and here to stay.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] .automount from user?

2013-09-11 Thread Lennart Poettering
On Tue, 30.07.13 01:02, rekt...@voodoowarez.com (rekt...@voodoowarez.com) wrote:

 Hello.  I'm curious, and perhaps maybe lazy: is there any way to do automount 
 units from a user
 systemd instance? I suppose I could write some silly script that collects 
 automount files out of the
 user units directories and validates and accepts them, but it would be 
 stellar if systemd had some
 plan for bestowing my users their ability to use their fuse group membership 
 in a cool rad
 automounting way. Peace love chicken grease- rektide.

This is currently not available to unprivileged processes and is very
unlikely to change, because there are all kinds of interesting ways how
userspace can deadlock the kernel and that's hard to fix. For priviliged
userspace code we can make the best of it and just protect ourselves
from running into these deadlocks, but opening this up to unprivileged
code would open a can of worms.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [systemd-commits] configure.ac Makefile.am src/login units/u...@.service.in

2013-09-11 Thread Kok, Auke-jan H
On Wed, Sep 11, 2013 at 12:39 PM, Zbigniew Jędrzejewski-Szmek
zbys...@kemper.freedesktop.org wrote:
  Makefile.am|5 +
  configure.ac   |7 +++
  src/login/pam-module.c |4 ++--
  src/login/systemd-user |8 
  units/u...@.service.in |2 +-
  5 files changed, 23 insertions(+), 3 deletions(-)

 New commits:
 commit 5c390a4ae0d383b2003074ed011d47876c7e630c
 Author: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
 Date:   Wed Sep 11 14:31:14 2013 -0400

 Add pam configuration to allow user sessions to work out of the box

 systemd-logind will start user@.service. user@.service unit uses
 PAM with service name 'systemd-user' to perform account and session
 managment tasks. Previously, the name was 'systemd-shared', it is
 now changed to 'systemd-user'.

 Most PAM installations use one common setup for different callers.
 Based on a quick poll, distributions fall into two camps: those that
 have system-auth (Redhat, Fedora, CentOS, Arch, Gentoo, Mageia,
 Mandriva), and those that have common-auth (Debian, Ubuntu, OpenSUSE).
 Distributions that have system-auth have just one configuration file
 that contains auth, password, account, and session blocks, and
 distributions that have common-auth also have common-session,
 common-password, and common-account. It is thus impossible to use one
 configuration file which would work for everybody. systemd-user now
 refers to system-auth, because it seems that the approach with one
 file is more popular and also easier, so let's follow that.


+1

Thanks for doing this - it'll be good for folks implementing user
sessions to have a consistent approach.

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


[systemd-devel] [PATCH] man: fix description of sysctl.d order

2013-09-11 Thread Mantas Mikulėnas
systemd-sysctl gives priority to the latest occurence as of commit
04bf3c1a60d82791e0320381e9268f727708f776, but the manpage hasn't been
updated for that.
---
 man/sysctl.d.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/sysctl.d.xml b/man/sysctl.d.xml
index 69e96ee..ce5c34f 100644
--- a/man/sysctl.d.xml
+++ b/man/sysctl.d.xml
@@ -92,7 +92,7 @@
 alphabetical order, regardless in which of the
 directories they reside, to guarantee that a specific
 configuration file takes precedence over another file
-with an alphabetically later name, if both files
+with an alphabetically earlier name, if both files
 contain the same variable setting./para
 
 paraIf the administrator wants to disable a
-- 
1.8.4.242.gbb80ee0

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


Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order

2013-09-11 Thread Kay Sievers
On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
 'Twas brillig, and Mantas Mikulėnas at 11/09/13 22:53 did gyre and gimble:
 systemd-sysctl gives priority to the latest occurence as of commit
 04bf3c1a60d82791e0320381e9268f727708f776, but the manpage hasn't been
 updated for that.

 Oh jeez... has the ordering flipped again??

 I only just rejigged things for the last time this flipped around and
 now sysctl has decided to buck the trend of the other tools and follow a
 later file has priority? I think consistency is good here (even if
 conceptually, a later file overriding an earlier one feels better.

Yes, and later-override-earlier is by far the bigger trend. :)

 The order was previously fixed such that earlier files win for several
 tools binfmt, tmpfiles

These are multi-options lines which cannot really be merged or
overwritten with multiple lines.

Avoiding conflicting entries seems the best approach here, and the
first-one-wins, the later ones complain sounds like the best approach.

 modules-load

This is just all loaded what's in there, no order, no overwrite, doesn't it?

 and sysctl in
 fabe5c0e5fce730aa66e10a9c4f9fdd443d7aeda back in February.

Sysctl really should be able to handle, and always did in the past,
conflicting entries, and we should not break that stuff. The old tool
just wrote the values multiple times into the kernel.

 Is there a reason why sysctl.conf cannot just be symlinked as
 sysctl.d/0-sysctl.conf rather than 99-sysctl.conf and keep the ordering
 consistent with the other tools?

Where is that defined? /etc/sysctl.conf should not exist, in the ideal case.

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


Re: [systemd-devel] [PATCH] build: allow specifying a custom pam session name

2013-09-11 Thread Lennart Poettering
On Fri, 26.07.13 00:28, Marc-Antoine Perennou (marc-anto...@perennou.com) wrote:

 for distribution now wanting to use systemd-shared

In systemd git this is now renamed to systemd-user. This really should
get a fixed PAM name of its own and shouldn't be configurable.

 
 Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
 ---
  Makefile.am|  1 +
  configure.ac   | 10 ++
  units/u...@.service.in |  2 +-
  3 files changed, 12 insertions(+), 1 deletion(-)
 
 diff --git a/Makefile.am b/Makefile.am
 index d013dfd..8030c5f 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -4072,6 +4072,7 @@ substitutions = \
 '|udevlibexecdir=$(udevlibexecdir)|' \
 '|SUSHELL=$(SUSHELL)|' \
 '|DEBUGTTY=$(DEBUGTTY)|' \
 +   '|PAM_NAME=$(PAM_NAME)|' \
 '|KILL=$(KILL)|' \
 '|KMOD=$(KMOD)|' \
 '|MKDIR_P=$(MKDIR_P)|' \
 diff --git a/configure.ac b/configure.ac
 index 759073a..c1d2dac 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -404,6 +404,15 @@ AC_SUBST(PAM_LIBS)
  AM_CONDITIONAL([HAVE_PAM], [test x$have_pam != xno])
  
  # 
 --
 +AC_ARG_WITH([pam-name],
 +AS_HELP_STRING([--with-pam-name=NAME],
 +[Specify the PAM session name to set up a session as]),
 +[PAM_NAME=$withval],
 +[PAM_NAME=systemd-shared])
 +
 +AC_SUBST(PAM_NAME)
 +
 +# 
 --
  AC_ARG_ENABLE([acl],
  AS_HELP_STRING([--disable-acl],[Disable optional ACL support]),
  [case ${enableval} in
 @@ -1027,6 +1036,7 @@ AC_MSG_RESULT([
  Installation Python: ${PYTHON_BINARY}
  firmware path:   ${FIRMWARE_PATH}
  PAM modules dir: ${with_pamlibdir}
 +PAM session name:${with_pam_name}
  D-Bus policy dir:${with_dbuspolicydir}
  D-Bus session dir:   ${with_dbussessionservicedir}
  D-Bus system dir:${with_dbussystemservicedir}
 diff --git a/units/u...@.service.in b/units/u...@.service.in
 index 8f9a3b3..ce53d31 100644
 --- a/units/u...@.service.in
 +++ b/units/u...@.service.in
 @@ -11,7 +11,7 @@ After=systemd-user-sessions.service
  
  [Service]
  User=%I
 -PAMName=systemd-shared
 +PAMName=@PAM_NAME@
  Type=notify
  ExecStart=-@rootlibexecdir@/systemd --user
  
 Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket


Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Colin Walters
On Wed, 2013-09-11 at 19:11 +0200, Lennart Poettering wrote:

 Can you elaborate on this? Why wouldn't it suffice to drop in a .mount
 unit for the mount in question which excludes the mount point from being
 unmounted with this?

It doesn't appear possible to remove the default Conflicts= just by
creating /etc/systemd/system/var.mount.

I tried doing my plan of adding a boolean to mount units if we detect
them at coldplug time, and ensuring we pass that from the dracut systemd
to the deserialized main pid.  But what I hit doing that was from
dracut-systemd's perspective it is /sysroot/var, and not /var.  Would
need to do some sort of device/inode pairing to fix up paths after a
potential switch-root.



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


Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

2013-09-11 Thread Lennart Poettering
On Wed, 11.09.13 19:48, Colin Walters (walt...@verbum.org) wrote:

 
 On Wed, 2013-09-11 at 19:11 +0200, Lennart Poettering wrote:
 
  Can you elaborate on this? Why wouldn't it suffice to drop in a .mount
  unit for the mount in question which excludes the mount point from being
  unmounted with this?
 
 It doesn't appear possible to remove the default Conflicts= just by
 creating /etc/systemd/system/var.mount.

You'd have to set DefaultDependencies=no in order to turn the implicit
shutdown.target conflict dep off.

 I tried doing my plan of adding a boolean to mount units if we detect
 them at coldplug time, and ensuring we pass that from the dracut systemd
 to the deserialized main pid.  But what I hit doing that was from
 dracut-systemd's perspective it is /sysroot/var, and not /var.  Would
 need to do some sort of device/inode pairing to fix up paths after a
 potential switch-root.

Still not convinced that we really want to do that. But note that on
Linux mounts have a fixed numeric ID, which is the first column in
/proc/self/mountinfo. You can also query that ID on many (but not all)
file systems via the name_to_handle_at() system call (which is really
nasty to use though, we already use it in path-util.c and tmpfiles.c
already.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Has systemd booted up command

2013-09-11 Thread Lennart Poettering
On Thu, 18.07.13 20:36, Umut Tezduyar (u...@tezduyar.com) wrote:

Hey,

 Implementing a tool that catches the dbus signal, like you have said
 must be relatively easy. In fact I believe it should be possible to do
 it by dbus-monitor but the main problem is, tool itself must be
 started by systemd as a service with a Before={target you are booting
 to}. Otherwise you cannot be sure if the StartupFinished signal has
 been sent before the tool starts.

This won't work. If you run the tool as a service like you suggest then
this service will have a job queued as long as it is running and you
will hence never get StartupFinished since your own tool is still queued.

 The other need is coming due to an item in our TODO list which is,
 when isolating, try to figure out a way how we implicitly can order
 all units we stop before the isolating unit Since the stop jobs
 are asynchronous, I would be using following command to make sure that
 isolation is fully complete: systemctl is-active MyIsolated.target 
 systemctl show -pNJobs | grep -q Njobs=0. I do believe, this might
 not be a common use case and I can live with parsing the output of
 systemctl show -pNJobs.

Note that if two units are ordered against each other (regardles whether
with Before= or After=) and a stop job is queued for one of them, and a
start job is queued for the other, then the stop job will always be
executed first, the start job second. Hence it is sufficient to simply
order all units you want to have finished before or after your isolated
unit and you get what you need.

It's usually safer (and less deadlock-prone) to use systemd's own job
queuing rather than attempting your own on the side...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Some thoughts about loop_read/loop_write in util.c

2013-09-11 Thread cee1
2013/9/11 Lennart Poettering lenn...@poettering.net:
 loop_read/loop_write:
 http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c#n2179

 In a scenario of pipes, loop_read on read side, if the write side is
 closed, loop_read will return 0 if do_poll is false(let's assume no
 data available to read). When do_poll is true, it will return:
 1) 0, if write side is closed while loop_read is just doing a read
 2) or -EIO when poll returns pollfd.revent with POLLHUP flag set

 The behavior is not very consistent.
 IMHO, it's preferred loop_read follows read behavior as much as
 possible -- returns 0 to indicate end of a file here, e.g. We can try
 to read 0 bytes when pollfd.revents != POLLIN.

 EOF and temporarily not being able to read more data is something very
 different.

 It might make sense to return EAGAIN if POLLHUP is set though.

 (But note that POLLHUP has more complex semantics when combined with
 shutdown() and half-open connections...)

 The same with loop_write.

 EOF doesn't exist for loop_write(), so this is even weirder
Sorry for not make myself clear, I mean EPIPE.

What about the following patch? It simply do read/write again if poll
returns, and let read/write report error if something is wrong.

From 3b83e839ebfc161565db76ce8d0e1dd4da1b0afc Mon Sep 17 00:00:00 2001
From: Chen Jie ch...@lemote.com
Date: Thu, 12 Sep 2013 09:21:41 +0800
Subject: [PATCH] util.c: not check pollfd.revent for loop_read/loop_write

If an error occurred, let read/write report it.
---
 src/shared/util.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/shared/util.c b/src/shared/util.c
index 1dde8af..e08ec44 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -2206,8 +2206,10 @@ ssize_t loop_read(int fd, void *buf, size_t
nbytes, bool do_poll) {
 return n  0 ? n : -errno;
 }

+/*
 if (pollfd.revents != POLLIN)
 return n  0 ? n : -EIO;
+ */

 continue;
 }
@@ -2254,8 +2256,10 @@ ssize_t loop_write(int fd, const void *buf,
size_t nbytes, bool do_poll) {
 return n  0 ? n : -errno;
 }

+/*
 if (pollfd.revents != POLLOUT)
 return n  0 ? n : -EIO;
+ */

 continue;
 }


-- 
Regards,

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


Re: [systemd-devel] [PATCH] libsystemd-login.so: fix undefined reference to 'cg_create'

2013-09-11 Thread Yang Chengwei
On Wed, Sep 11, 2013 at 01:27:03PM +0200, Lennart Poettering wrote:
 On Wed, 11.09.13 13:28, Yang Chengwei (chengwei.y...@intel.com) wrote:
 
  On Tue, Sep 10, 2013 at 06:02:55PM +0200, Lennart Poettering wrote:
   On Mon, 26.08.13 13:48, Chengwei Yang (chengwei.y...@intel.com) wrote:
   
   Hmm, can you elaborate on this one? libsystemd-login should be mostly
  
  This error occurs while building dbus with systemd support like below
  
  $ make
  make  all-recursive
  make[1]: Entering directory `/home/chengwei/Upstream/dbus.git'
  Making all in dbus
  make[2]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus'
  make  all-am
  make[3]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus'
CCLD   dbus-test
/usr/lib/libsystemd-login.so: undefined reference to `cg_create'
collect2: ld returned 1 exit status
make[3]: *** [dbus-test] Error 1
make[3]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/chengwei/Upstream/dbus.git'
make: *** [all] Error 2
  
  and cg_create referenced by libsystemd-login.so like below
  
  $ grep cg_create src/login/ -r
  Binary file src/login/systemd_logind-logind-session.o matches
  Binary file src/login/systemd_logind-logind-user.o matches
 
 But these files are not linked into libsystemd-login, but only into
 logind (the daemon)...

Yeah, just found that from Makefile.am, it's weird why the above error
happen.

--
Thanks,
Chengwei

 
 Lennart
 
 -- 
 Lennart Poettering - Red Hat, Inc.
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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


Re: [systemd-devel] [PATCH] libsystemd-login.so: fix undefined reference to 'cg_create'

2013-09-11 Thread Yang Chengwei
On Wed, Sep 11, 2013 at 02:09:58PM +0200, Kay Sievers wrote:
 On Wed, Sep 11, 2013 at 1:27 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Wed, 11.09.13 13:28, Yang Chengwei (chengwei.y...@intel.com) wrote:
 
  On Tue, Sep 10, 2013 at 06:02:55PM +0200, Lennart Poettering wrote:
   On Mon, 26.08.13 13:48, Chengwei Yang (chengwei.y...@intel.com) wrote:
  
   Hmm, can you elaborate on this one? libsystemd-login should be mostly
 
  This error occurs while building dbus with systemd support like below
 
  $ make
  make  all-recursive
  make[1]: Entering directory `/home/chengwei/Upstream/dbus.git'
  Making all in dbus
  make[2]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus'
  make  all-am
  make[3]: Entering directory `/home/chengwei/Upstream/dbus.git/dbus'
CCLD   dbus-test
/usr/lib/libsystemd-login.so: undefined reference to `cg_create'
collect2: ld returned 1 exit status
make[3]: *** [dbus-test] Error 1
make[3]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/chengwei/Upstream/dbus.git/dbus'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/chengwei/Upstream/dbus.git'
make: *** [all] Error 2
 
  and cg_create referenced by libsystemd-login.so like below
 
  $ grep cg_create src/login/ -r
  Binary file src/login/systemd_logind-logind-session.o matches
  Binary file src/login/systemd_logind-logind-user.o matches
 
  But these files are not linked into libsystemd-login, but only into
  logind (the daemon)...
 
 Does this print something when executed in the build tree?
   $ nm -D .libs/libsystemd-login.so | grep cg

$ nm -D /usr/lib/libsystemd-login.so | grep cg
 U tcgetattr

Seems irrelative with the problem.

--
Thanks,
Chengwei

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


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


Re: [systemd-devel] implies MemoryAccounting=true

2013-09-11 Thread Gao feng
On 09/11/2013 08:07 PM, Lennart Poettering wrote:
 On Wed, 11.09.13 09:18, Gao feng (gaof...@cn.fujitsu.com) wrote:
 
 The SYSTEMD.CGROUP(5) said if MemoryLimit=bytes is set for unit, it
 implies MemeoryAccounting=true for this unit.

 But seems systemd didn't implement this hint. CPUShares  BlockIO have
 the same problem, this is a shortage? patch needed?


 The logic for this is in src/core/cgroup.c's cgroup_context_get_mask()
 call, which will determine to which cgroup controllers to add a unit
 to. Note that setting MemoryLimit= will not actually propagate to the
 boolean exposed in MemoryAccounting=, it will just have the same effect
 as if it was set...


 Maybe we should also report MemoryAccounting=yes in cgroup_context_dump
 if we set MemoryLimit.
 
 What I don't really like about this is that we allow MemoryLimit to be
 altered dynamically, which would then need to influence
 MemoryAccounting= dynamically too. WHich means that we would have to
 shadow that field so that we can revert to the originally configured
 value. Also, it would have very weird effects if people then try to
 dynamically unset MemoryAccounting which would either possibly be a NOP
 or would have the effect of resseting MemoryLimit... If you follow what
 I mean.
 

make sense, thanks for your explanation :)

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


Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order

2013-09-11 Thread Kay Sievers
On Thu, Sep 12, 2013 at 1:22 AM, Kay Sievers k...@vrfy.org wrote:
 On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie gm...@colin.guthr.ie wrote:

 I only just rejigged things for the last time this flipped around and
 now sysctl has decided to buck the trend of the other tools and follow a
 later file has priority? I think consistency is good here (even if
 conceptually, a later file overriding an earlier one feels better.

 Yes, and later-override-earlier is by far the bigger trend. :)

 The order was previously fixed such that earlier files win for several
 tools binfmt, tmpfiles
 modules-load

Oh, what a mess. Quite a few man pages described pretty much the
opposite of what is done, not only in that file this patch fixed.

I now hopefully fixed all of the man pages to describe what the code
does. Now we have:

  binfmt - the last entry wins, people are allowed to overwrite earlier stuff
  tmpfiles - the first entry wins; uniqueness required, everything else an error
  sysctl - the last entry wins, people are allowed overwrite earlier stuff
  presets - the first entry wins, the search just stops there
  modules-load - there is no order, it's just a set of names that gets applied

There is no strictly consistent behavior between the different tools,
and I think for good reason, the do different things, some assign
values, some can't merge entries and require uniqueness, soem are just
lists; all seem to have their reason to do it in the way that makes
the most sense.

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


Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order

2013-09-11 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Sep 12, 2013 at 04:14:24AM +0200, Kay Sievers wrote:
 On Thu, Sep 12, 2013 at 1:22 AM, Kay Sievers k...@vrfy.org wrote:
  On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie gm...@colin.guthr.ie 
  wrote:
 
  I only just rejigged things for the last time this flipped around and
  now sysctl has decided to buck the trend of the other tools and follow a
  later file has priority? I think consistency is good here (even if
  conceptually, a later file overriding an earlier one feels better.
 
  Yes, and later-override-earlier is by far the bigger trend. :)
 
  The order was previously fixed such that earlier files win for several
  tools binfmt, tmpfiles
  modules-load
 
 Oh, what a mess. Quite a few man pages described pretty much the
 opposite of what is done, not only in that file this patch fixed.
 
 I now hopefully fixed all of the man pages to describe what the code
 does. Now we have:
 
   binfmt - the last entry wins, people are allowed to overwrite earlier stuff
   tmpfiles - the first entry wins; uniqueness required, everything else an 
 error
   sysctl - the last entry wins, people are allowed overwrite earlier stuff
   presets - the first entry wins, the search just stops there
   modules-load - there is no order, it's just a set of names that gets applied
Hm, and .service and service.d/*.conf? I think last entry wins also.

 There is no strictly consistent behavior between the different tools,
 and I think for good reason, the do different things, some assign
 values, some can't merge entries and require uniqueness, soem are just
 lists; all seem to have their reason to do it in the way that makes
 the most sense.

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


Re: [systemd-devel] [PATCH] man: fix description of sysctl.d order

2013-09-11 Thread Kay Sievers
On Thu, Sep 12, 2013 at 4:49 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Thu, Sep 12, 2013 at 04:14:24AM +0200, Kay Sievers wrote:
 On Thu, Sep 12, 2013 at 1:22 AM, Kay Sievers k...@vrfy.org wrote:
  On Thu, Sep 12, 2013 at 12:49 AM, Colin Guthrie gm...@colin.guthr.ie 
  wrote:

  I only just rejigged things for the last time this flipped around and
  now sysctl has decided to buck the trend of the other tools and follow a
  later file has priority? I think consistency is good here (even if
  conceptually, a later file overriding an earlier one feels better.
 
  Yes, and later-override-earlier is by far the bigger trend. :)
 
  The order was previously fixed such that earlier files win for several
  tools binfmt, tmpfiles
  modules-load

 Oh, what a mess. Quite a few man pages described pretty much the
 opposite of what is done, not only in that file this patch fixed.

 I now hopefully fixed all of the man pages to describe what the code
 does. Now we have:

   binfmt - the last entry wins, people are allowed to overwrite earlier stuff
   tmpfiles - the first entry wins; uniqueness required, everything else an 
 error
   sysctl - the last entry wins, people are allowed overwrite earlier stuff
   presets - the first entry wins, the search just stops there
   modules-load - there is no order, it's just a set of names that gets 
 applied
 Hm, and .service and service.d/*.conf? I think last entry wins also.

Right, that's also assignment-style, allows overwriting, like sysctl
or shell variable, and the last one wins.

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