[systemd-devel] [PATCH] test-dhcp6-client: Fix option length

2014-08-29 Thread Patrik Flykt
The whole DHCPv6 test message length was incorrectly used as the length
of DHCPv6 options causing the following bad memory access:

$ build/test-dhcp6-client
Assertion 'interface_index = -1' failed at 
../src/libsystemd-network/sd-dhcp6-client.c:129, function 
sd_dhcp6_client_set_index(). Ignoring.
=
==29135==ERROR: AddressSanitizer: global-buffer-overflow on address 
0x7fe204aa9148 at pc 0x7fe204a5958f bp 0x7fff3e47d470 sp 0x7fff3e47d460
READ of size 1 at 0x7fe204aa9148 thread T0
#0 0x7fe204a5958e in option_parse_hdr 
../src/libsystemd-network/dhcp6-option.c:145
#1 0x7fe204a59884 in dhcp6_option_parse 
../src/libsystemd-network/dhcp6-option.c:165
#2 0x7fe204a4eb9c in test_advertise_option 
../src/libsystemd-network/test-dhcp6-client.c:227
#3 0x7fe204a51c58 in main ../src/libsystemd-network/test-dhcp6-client.c:584
#4 0x7fe2031590df in __libc_start_main (/lib64/libc.so.6+0x200df)
#5 0x7fe204a4cc5b (/home/test/systemd/build/test-dhcp6-client+0x25c5b)

0x7fe204aa9148 is located 2 bytes to the right of global variable 
'msg_advertise' from '../src/libsystemd-network/test-dhcp6-client.c' 
(0x7fe204aa9080) of size 198
0x7fe204aa9148 is located 56 bytes to the left of global variable 'msg_reply' 
from '../src/libsystemd-network/test-dhcp6-client.c' (0x7fe204aa9180) of size 
173
SUMMARY: AddressSanitizer: global-buffer-overflow 
../src/libsystemd-network/dhcp6-option.c:145 option_parse_hdr
---

This seems to be the cause of the bad memory access, please test.

Cheers,

Patrik


 src/libsystemd-network/test-dhcp6-client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/libsystemd-network/test-dhcp6-client.c 
b/src/libsystemd-network/test-dhcp6-client.c
index 96c68e1..259db33 100644
--- a/src/libsystemd-network/test-dhcp6-client.c
+++ b/src/libsystemd-network/test-dhcp6-client.c
@@ -207,7 +207,7 @@ static int test_advertise_option(sd_event *e) {
 DHCP6Message *advertise = (DHCP6Message *)msg_advertise;
 uint8_t *optval, *opt = msg_advertise[sizeof(DHCP6Message)];
 uint16_t optcode;
-size_t optlen, len = sizeof(msg_advertise);
+size_t optlen, len = sizeof(msg_advertise) - sizeof(DHCP6Message);
 be32_t val;
 uint8_t preference = 255;
 struct in6_addr addr;
-- 
1.9.1

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


Re: [systemd-devel] [PATCH 3/3] systemd-journal-upload: fix invalid After=

2014-08-29 Thread Umut Tezduyar Lindskog
Hi, this is already in the backlog:
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022368.html
Thanks anyways.

On Thu, Aug 28, 2014 at 10:01 PM, Marius Tessmann mus@gmail.com wrote:
 After= belongs into [Unit], not [Install]. Found with systemd-analyze
 verify.
 ---
  units/systemd-journal-upload.service.in | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/units/systemd-journal-upload.service.in 
 b/units/systemd-journal-upload.service.in
 index e79f962..359ff10 100644
 --- a/units/systemd-journal-upload.service.in
 +++ b/units/systemd-journal-upload.service.in
 @@ -7,6 +7,7 @@

  [Unit]
  Description=Journal Remote Upload Service
 +After=network.target

  [Service]
  ExecStart=@rootlibexecdir@/systemd-journal-upload \
 @@ -18,4 +19,3 @@ WatchdogSec=20min

  [Install]
  WantedBy=multi-user.target
 -After=network.target
 --
 2.1.0

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


Re: [systemd-devel] Systemd-networkd doesn't add static routes anymore

2014-08-29 Thread David Herrmann
Hi

On Thu, Aug 28, 2014 at 11:39 PM, Moviuro movi...@gmail.com wrote:
 After git bisect-ing (following dreisner's instructions on #systemd), I get
 the following info:

 38de08a does not add static routes
 ccf1c02 systemd-networkd is broken (does not run) (crash)
 54cba0b systemd-networkd is broken (does not run) (crash)
 3c9b886 systemd-networkd is broken (does not run) (crash)

That one looks like the culprit. Putting Tom on CC as he works on that stuff.

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


Re: [systemd-devel] [PATCH 3/3] systemd-journal-upload: fix invalid After=

2014-08-29 Thread David Herrmann
Hi

On Fri, Aug 29, 2014 at 9:53 AM, Umut Tezduyar Lindskog
u...@tezduyar.com wrote:
 Hi, this is already in the backlog:
 http://lists.freedesktop.org/archives/systemd-devel/2014-August/022368.html
 Thanks anyways.

Yepp, and Zbigniew applied and pushed it.

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


Re: [systemd-devel] Systemd-networkd doesn't add static routes anymore

2014-08-29 Thread Tom Gundersen
On Thu, Aug 28, 2014 at 11:39 PM, Moviuro movi...@gmail.com wrote:
 After git bisect-ing (following dreisner's instructions on #systemd), I get
 the following info:

 38de08a does not add static routes
 ccf1c02 systemd-networkd is broken (does not run) (crash)
 54cba0b systemd-networkd is broken (does not run) (crash)
 3c9b886 systemd-networkd is broken (does not run) (crash)
 68ba387 systemd-networkd works as expected

 I can't help review the code as I know no C, but I hope that helps

Thanks for the report, I'll have a look.

Cheers,

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


[systemd-devel] systemd --user environment

2014-08-29 Thread arnaud gaboury
systemd 216-1


I start to play with systemd/user. I understand that the user instance
does not inherit from all my environment variables listed by the
printenv command. When a variable is needed for a service, I add a
/etc/systemd/system/user@.service.d/myService.conf drop-In file with
the Environment=myVariable.
I can also edit /etc/environment, or /etc/systemd/user.conf

Is there any way to define a per user environment file somewhere in my
user home directory, so I can add variables?

I tried some hacks with no success, mainly because the home directory
will be /root (I guess so).

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


Re: [systemd-devel] systemd --user environment

2014-08-29 Thread David Herrmann
Hi

On Fri, Aug 29, 2014 at 12:45 PM, arnaud gaboury
arnaud.gabo...@gmail.com wrote:
 systemd 216-1


 I start to play with systemd/user. I understand that the user instance
 does not inherit from all my environment variables listed by the
 printenv command. When a variable is needed for a service, I add a
 /etc/systemd/system/user@.service.d/myService.conf drop-In file with
 the Environment=myVariable.
 I can also edit /etc/environment, or /etc/systemd/user.conf

 Is there any way to define a per user environment file somewhere in my
 user home directory, so I can add variables?

systemd run with --system reads config-files from /etc/systemd/system/
and equivalents (in /usr, /run, ...). If run with --user, it reads
from /etc/systemd/user/ and equivalents (/usr, /run, ...).
Additionally, --user also adds the home-directory of the user as
source: ~/.config/systemd/user/

So I guess, what you want to do is to create a file in:
  ~/.config/systemd/user/your_service.conf.d/your_drop_in_file.conf

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


[systemd-devel] [PATCH] Fix a few typos in log messages

2014-08-29 Thread Ruben Kerkhof
From 6a320e9e83fd32a60fadc735646edf96d36a0cd1 Mon Sep 17 00:00:00 2001
From: Ruben Kerkhof ru...@rubenkerkhof.com
Date: Fri, 29 Aug 2014 12:58:16 +0200
Subject: [PATCH] Fix a few typos in log messages

---
 src/libsystemd-network/sd-dhcp-client.c | 12 ++--
 src/libsystemd/sd-rtnl/sd-rtnl.c|  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp-client.c 
b/src/libsystemd-network/sd-dhcp-client.c
index 7cf1b80..2f94c16 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -919,7 +919,7 @@ static int client_handle_offer(sd_dhcp_client *client, 
DHCPMessage *offer,
 
 r = dhcp_option_parse(offer, len, dhcp_lease_parse_options, lease);
 if (r != DHCP_OFFER) {
-log_dhcp_client(client, receieved message was not an OFFER, 
ignoring);
+log_dhcp_client(client, received message was not an OFFER, 
ignoring);
 return -ENOMSG;
 }
 
@@ -930,7 +930,7 @@ static int client_handle_offer(sd_dhcp_client *client, 
DHCPMessage *offer,
 if (lease-address == INADDR_ANY ||
 lease-server_address == INADDR_ANY ||
 lease-lifetime == 0) {
-log_dhcp_client(client, receieved lease lacks address, server 

+log_dhcp_client(client, received lease lacks address, server 
 address or lease lifetime, ignoring);
 return -ENOMSG;
 }
@@ -938,7 +938,7 @@ static int client_handle_offer(sd_dhcp_client *client, 
DHCPMessage *offer,
 if (lease-subnet_mask == INADDR_ANY) {
 r = dhcp_lease_set_default_subnet_mask(lease);
 if (r  0) {
-log_dhcp_client(client, receieved lease lacks subnet 
+log_dhcp_client(client, received lease lacks subnet 
 mask, and a fallback one can not be 
 generated, ignoring);
 return -ENOMSG;
@@ -983,7 +983,7 @@ static int client_handle_ack(sd_dhcp_client *client, 
DHCPMessage *ack,
 }
 
 if (r != DHCP_ACK) {
-log_dhcp_client(client, receieved message was not an ACK, 
ignoring);
+log_dhcp_client(client, received message was not an ACK, 
ignoring);
 return -ENOMSG;
 }
 
@@ -994,7 +994,7 @@ static int client_handle_ack(sd_dhcp_client *client, 
DHCPMessage *ack,
 if (lease-address == INADDR_ANY ||
 lease-server_address == INADDR_ANY ||
 lease-lifetime == 0) {
-log_dhcp_client(client, receieved lease lacks address, server 

+log_dhcp_client(client, received lease lacks address, server 
 address or lease lifetime, ignoring);
 return -ENOMSG;
 }
@@ -1002,7 +1002,7 @@ static int client_handle_ack(sd_dhcp_client *client, 
DHCPMessage *ack,
 if (lease-subnet_mask == INADDR_ANY) {
 r = dhcp_lease_set_default_subnet_mask(lease);
 if (r  0) {
-log_dhcp_client(client, receieved lease lacks subnet 
+log_dhcp_client(client, received lease lacks subnet 
 mask, and a fallback one can not be 
 generated, ignoring);
 return -ENOMSG;
diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c b/src/libsystemd/sd-rtnl/sd-rtnl.c
index f883f28..a3f314b 100644
--- a/src/libsystemd/sd-rtnl/sd-rtnl.c
+++ b/src/libsystemd/sd-rtnl/sd-rtnl.c
@@ -680,7 +680,7 @@ int sd_rtnl_call(sd_rtnl *rtnl,
 if (r  0)
 return r;
 if (r  0)
-/* receieved message, so try to process straight away 
*/
+/* received message, so try to process straight away */
 continue;
 
 if (timeout  0) {
-- 
2.1.0

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


Re: [systemd-devel] [PATCH 3/3] systemd-journal-upload: fix invalid After=

2014-08-29 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Aug 29, 2014 at 09:53:00AM +0200, Umut Tezduyar Lindskog wrote:
 Hi, this is already in the backlog:
 http://lists.freedesktop.org/archives/systemd-devel/2014-August/022368.html
 Thanks anyways.
Ah, sorry, I missed it.

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


Re: [systemd-devel] [PATCH] test-dhcp6-client: Fix option length

2014-08-29 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Aug 29, 2014 at 09:20:46AM +0300, Patrik Flykt wrote:
 The whole DHCPv6 test message length was incorrectly used as the length
 of DHCPv6 options causing the following bad memory access:
 
 $ build/test-dhcp6-client
 Assertion 'interface_index = -1' failed at 
 ../src/libsystemd-network/sd-dhcp6-client.c:129, function 
 sd_dhcp6_client_set_index(). Ignoring.
 =
 ==29135==ERROR: AddressSanitizer: global-buffer-overflow on address 
 0x7fe204aa9148 at pc 0x7fe204a5958f bp 0x7fff3e47d470 sp 0x7fff3e47d460
 READ of size 1 at 0x7fe204aa9148 thread T0
 #0 0x7fe204a5958e in option_parse_hdr 
 ../src/libsystemd-network/dhcp6-option.c:145
 #1 0x7fe204a59884 in dhcp6_option_parse 
 ../src/libsystemd-network/dhcp6-option.c:165
 #2 0x7fe204a4eb9c in test_advertise_option 
 ../src/libsystemd-network/test-dhcp6-client.c:227
 #3 0x7fe204a51c58 in main 
 ../src/libsystemd-network/test-dhcp6-client.c:584
 #4 0x7fe2031590df in __libc_start_main (/lib64/libc.so.6+0x200df)
 #5 0x7fe204a4cc5b (/home/test/systemd/build/test-dhcp6-client+0x25c5b)
 
 0x7fe204aa9148 is located 2 bytes to the right of global variable 
 'msg_advertise' from '../src/libsystemd-network/test-dhcp6-client.c' 
 (0x7fe204aa9080) of size 198
 0x7fe204aa9148 is located 56 bytes to the left of global variable 'msg_reply' 
 from '../src/libsystemd-network/test-dhcp6-client.c' (0x7fe204aa9180) of size 
 173
 SUMMARY: AddressSanitizer: global-buffer-overflow 
 ../src/libsystemd-network/dhcp6-option.c:145 option_parse_hdr
 ---
 
 This seems to be the cause of the bad memory access, please test.
Hm, I thiink it helps, but there's another one:

$ build/test-dhcp6-client 
Assertion 'interface_index = -1' failed at 
../src/libsystemd-network/sd-dhcp6-client.c:129, function 
sd_dhcp6_client_set_index(). Ignoring.
DHCPv6 CLIENT: Sent SOLICIT
DHCPv6 CLIENT: Next retransmission in 1.049185s
=
==29571==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x61109708 at pc 0x7fd00190458f bp 0x7fff287de8d0 sp 0x7fff287de8c0
READ of size 1 at 0x61109708 thread T0
#0 0x7fd00190458e in option_parse_hdr 
../src/libsystemd-network/dhcp6-option.c:145
#1 0x7fd001904884 in dhcp6_option_parse 
../src/libsystemd-network/dhcp6-option.c:165
#2 0x7fd0019008ff in client_parse_message 
../src/libsystemd-network/sd-dhcp6-client.c:582
#3 0x7fd001901078 in client_receive_advertise 
../src/libsystemd-network/sd-dhcp6-client.c:732
#4 0x7fd001901822 in client_receive_message 
../src/libsystemd-network/sd-dhcp6-client.c:809
#5 0x7fd001918c77 in source_dispatch 
../src/libsystemd/sd-event/sd-event.c:2035
#6 0x7fd00191b7f1 in sd_event_dispatch 
../src/libsystemd/sd-event/sd-event.c:2384
#7 0x7fd00191bad4 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:2413
#8 0x7fd00191bc1d in sd_event_loop 
../src/libsystemd/sd-event/sd-event.c:2428
#9 0x7fd0018fca81 in test_client_solicit 
../src/libsystemd-network/test-dhcp6-client.c:562
#10 0x7fd0018fcc65 in main ../src/libsystemd-network/test-dhcp6-client.c:585
#11 0x7fd040df in __libc_start_main (/lib64/libc.so.6+0x200df)
#12 0x7fd0018f7c5b (/home/test/systemd/build/test-dhcp6-client+0x25c5b)

0x61109708 is located 2 bytes to the right of 198-byte region 
[0x61109640,0x61109706)
allocated by thread T0 here:
#0 0x7fd000827cf5 in calloc (/lib64/libasan.so.1+0x57cf5)
#1 0x7fd00190152b in client_receive_message 
../src/libsystemd-network/sd-dhcp6-client.c:769
#2 0x7fd001918c77 in source_dispatch 
../src/libsystemd/sd-event/sd-event.c:2035
#3 0x7fd00191b7f1 in sd_event_dispatch 
../src/libsystemd/sd-event/sd-event.c:2384
#4 0x7fd00191bad4 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:2413
#5 0x7fd00191bc1d in sd_event_loop 
../src/libsystemd/sd-event/sd-event.c:2428
#6 0x7fd0018fca81 in test_client_solicit 
../src/libsystemd-network/test-dhcp6-client.c:562
#7 0x7fd0018fcc65 in main ../src/libsystemd-network/test-dhcp6-client.c:585
#8 0x7fd040df in __libc_start_main (/lib64/libc.so.6+0x200df)

SUMMARY: AddressSanitizer: heap-buffer-overflow 
../src/libsystemd-network/dhcp6-option.c:145 option_parse_hdr
Shadow bytes around the buggy address:
  0x0c227fff9290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92c0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff92d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=0x0c227fff92e0: 06[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fff92f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fff9300: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
  0x0c227fff9310: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c227fff9320: 00 00 00 00 00 00 00 00 00 00 00 00 

Re: [systemd-devel] [PATCH] journal: grant systemd-journal group permission

2014-08-29 Thread WaLyong Cho
On 08/27/2014 02:55 AM, Lennart Poettering wrote:
 On Tue, 26.08.14 15:43, WaLyong Cho (walyong@samsung.com) wrote:
 
 There is no Bofore= or After= dependencies between
 systemd-journald.service and systemd-tmpfiles-setup.service. So if both
 /run/log/journal and /var/log/journal does not exist then those can
 be make as root:root and also its ids directory and journal files. To
 make sure, do chown systemd-journal group to journal directories and
 files.
 
 Hmm? /run/log/journal will be recursively updated, and /var/log/journal
 is not created by journald ever, but only by tmpfiles, which uses g+s to
 ensure all files that will be created have the right owner from the
 beginning.
 
I hope you test like me. Set *Storage=persistent* in journald.conf and
remove(back it up to other) /var/log/journal and restart.
Then maybe you can see like me:

[walyong@laptop ~]$ ls -alh
/var/log/journal/9017c5267dfb4ec1869084165173ecb6/
total 16M
drwxr-sr-x  1 root systemd-journal   62 Aug 29 21:48 .
drwxr-sr-x  1 root systemd-journal   64 Aug 29 21:47 ..
-rw-r-  1 root root8.0M Aug 29 21:53 system.journal
-rw-r-+ 1 root root8.0M Aug 29 21:53 user-1000.journal

[walyong@laptop system]$ systemctl status systemd-tmpfiles-setup.service
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded
(/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static)
   Active: active (exited) since Fri 2014-08-29 21:48:43 KST; 6min ago
 Docs: man:tmpfiles.d(5)
   man:systemd-tmpfiles(8)
  Process: 482 ExecStart=/usr/bin/systemd-tmpfiles --create --remove
--boot --exclude-prefix=/dev (code=exited, status=0/SUCCESS)
 Main PID: 482 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/systemd-tmpfiles-setup.service


After this, we can NOT read system.journal until journal file is
rotated(newly generated system.journal will have root:systemd-journal
permission) even if HAVE systemd-journal group permission.

Am I wrong?


 +static int chown_group_systemd_journal(const char *path) {
 +int r;
 +gid_t gid;
 +_cleanup_free_ char *journal_group = NULL;
 +
 +r = in_group(systemd-journal);
 +if (r  0)
 +return r;
 +
 +r = access(path, F_OK);
 +if (r  0)
 +return -errno;
 +
 +r = asprintf(journal_group, systemd-journal);
 +if (r  0)
 +return -ENOMEM;
 +
 +r = get_group_creds((const char **)journal_group, gid);
 +if (r  0)
 +return r;
 
 We cannot do this. This internally invokes getpwent() which is an NSS
 calls. NSS calls might end up being IPC calls to some external daemon,
 which might want to log, back into journald. This hence means we'd have
 a cyclic dependency.
 
 journald is not allowed to *ever* do NSS calls (and neither is PID 1
 actually). We must apply the ownership from the outside via tmpfiles or
 so hence.
 
 Lennart
 
WaLyong
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation

2014-08-29 Thread Jan Janssen



On 2014-08-29 04:28, Andrei Borzenkov wrote:

В Thu, 28 Aug 2014 19:36:53 +0200
Jan Janssen medhe...@web.de пишет:


On Thursday 28 August 2014 11:33:44 Ivan Shapovalov wrote:

On Thursday 28 August 2014 at 06:25:51, Jan Janssen wrote:

Ivan Shapovalov intelfx100 at gmail.com writes:

On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote:

On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx100 at gmail.com) wrote:

This patchset allows systemd to parse resume= kernel command line


parameter


and initiate resume from the specified device.


What about swap files with the resume_offset= parameter? Are they
still
being used?


I don't know if somebody uses that, but for now it's missing
functionality.

After a cursory search, I could not find a mechanism to initiate a
resume with offset from userspace. In Arch, it was never implemented
even if possible.

I'm a heavy user of this myself. It's especially useful because you can
just have a single luks encrypted ext4 without a lvm in between for a
swap partition or (even more yuck) using a separate (encrypted) swap
partition.

Arch does support this, mostly because as far as I know, the
resume_offset=
is consumed by the kernel, while resume= has to refer to the (unencrypted)
filesystem (/dev/mapper/root in my case). So, as long as this solution
waits for the device to show up in /dev/ (and especially /dev/mapper/ for
my case), this should work out.

Here's information to set this up. Imho more people should be aware this
is
possible:
https://wiki.archlinux.org/index.php/Suspend#Hibernation_into_swap_file

Jan


Hmm, so is resume_offset= parsed independently of resume=? If that's the
case, and resume_offset= can be parsed by kernel while resume= is parsed
by userspace, then yes, I was wrong and this should work.

Actually, it should work _just like before_, sans tuxonice support.


I gave it a try and resume works for me with that sd-resume hook in arch. But 
I'm not too sure whether fsck is delayed properly:

systemd[1]: Started Cryptography Setup for 
luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
systemd[1]: Found device /dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78.
systemd[1]: Starting File System Check on 
/dev/mapper/luks-ab8e32ef-3a85-4fee-8377-f41df2e0cb78...


Hmm ... it is not systemd-fsck-root.service. Do you have
local-fs-pre.target installed in initrd? What units are there at all?


never mind, I failed to update the system-fsk@.service that had the new 
dependency.


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


Re: [systemd-devel] [PATCH] Fix a few typos in log messages

2014-08-29 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Aug 29, 2014 at 01:28:04PM +0200, Ruben Kerkhof wrote:
 From 6a320e9e83fd32a60fadc735646edf96d36a0cd1 Mon Sep 17 00:00:00 2001
 From: Ruben Kerkhof ru...@rubenkerkhof.com
 Date: Fri, 29 Aug 2014 12:58:16 +0200
 Subject: [PATCH] Fix a few typos in log messages
Applied.

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


[systemd-devel] [PATCH] cryptsetup-generator: Allow specifiying a name on the kernel command line

2014-08-29 Thread Jan Janssen
---
 man/systemd-cryptsetup-generator.xml  |  8 ++--
 src/cryptsetup/cryptsetup-generator.c | 32 +---
 2 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/man/systemd-cryptsetup-generator.xml 
b/man/systemd-cryptsetup-generator.xml
index 3abb39d..44c8658 100644
--- a/man/systemd-cryptsetup-generator.xml
+++ b/man/systemd-cryptsetup-generator.xml
@@ -120,8 +120,12 @@
 activate the specified device as part
 of the boot process as if it was
 listed in
-filename/etc/fstab/filename. This
-option may be specified more than once
+filename/etc/fstab/filename.
+If the UUID is followed with 
literal:name/literal,
+the plain test device will appear under that 
name
+in filename/dev/mapper//filename, otherwise
+it will be literalluks-UUID/literal./para
+paraThis option may be specified more than 
once
 in order to set up multiple
 devices. varnamerd.luks.uuid=/varname
 is honored only by initial RAM disk
diff --git a/src/cryptsetup/cryptsetup-generator.c 
b/src/cryptsetup/cryptsetup-generator.c
index 3233e15..dea2b1f 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -279,7 +279,7 @@ static int parse_proc_cmdline_item(const char *key, const 
char *value) {
 
 } else if (STR_IN_SET(key, luks.uuid, rd.luks.uuid)  value) {
 
-if (strv_extend(arg_disks, value)  0)
+if (strv_extend(arg_disks, startswith(value, luks-) ? 
value+5 : value)  0)
 return log_oom();
 
 } else if (STR_IN_SET(key, luks.options, rd.luks.options)  
value) {
@@ -401,13 +401,14 @@ int main(int argc, char *argv[]) {
 */
 STRV_FOREACH(i, arg_disks) {
 _cleanup_free_ char *proc_device = 
NULL, *proc_name = NULL;
-const char *p = *i;
+const char *p = NULL;
 
-if (startswith(p, luks-))
-p += 5;
-
-proc_name = strappend(luks-, p);
-proc_device = strappend(UUID=, p);
+p = strchrnul(*i, ':');
+proc_device = strnappend(UUID=, *i, 
p - *i);
+if (*p  !isempty(p + 1))
+proc_name = strdup(p + 1);
+else
+proc_name = 
strnappend(luks-, *i, p - *i);
 
 if (!proc_name || !proc_device) {
 log_oom();
@@ -418,7 +419,7 @@ int main(int argc, char *argv[]) {
 if (create_disk(name, device, 
password, options)  0)
 goto cleanup;
 
-if (strv_extend(disks_done, 
p)  0) {
+if (strv_extend(disks_done, 
*i)  0) {
 log_oom();
 goto cleanup;
 }
@@ -440,16 +441,17 @@ next:
 */
 
 _cleanup_free_ char *name = NULL, *device = NULL, *options = 
NULL;
-const char *p = *i;
-
-if (startswith(p, luks-))
-p += 5;
+const char *p = NULL;
 
-if (strv_contains(disks_done, p))
+if (strv_contains(disks_done, *i))
 continue;
 
-name = strappend(luks-, p);
-device = strappend(UUID=, p);
+p = strchrnul(*i, ':');
+device = strnappend(UUID=, *i, p - *i);
+if (*p  !isempty(p + 1))
+name = strdup(p + 1);
+else
+name = strnappend(luks-, *i, p - *i);
 
 if (!name || !device) {
 log_oom();
-- 
2.1.0

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


Re: [systemd-devel] Suppressing automounting

2014-08-29 Thread Dale R. Worley
 From: Mantas Mikulėnas graw...@gmail.com

 For fstab, the units are created by a 'generator'
 (systemd-fstab-generator), which writes them under /run/systemd/generator
 every time the configuration is reloaded.
 
 I'm not at my PC right now so I cannot check, but I /do/ remember someone
 mentioning that if a fstab entry has the 'auto' option, then the generator
 also symlinks the corresponding .mount unit under devpath.device.wants/
 (e.g. dev-sda3.device.wants/mnt-backup.mount), causing the .mount unit to
 be triggered *every* time that device appears on the system.
 
 That is, in addition to local-fs.target triggering foo.mount and waiting
 for bar.device one time only (as you describe), it makes bar.device itself
 trigger foo.mount every time as well.

Thanks for the information!

I finally thought to do man -k fstab to see if it turned up
anything, and I found the manual page for systemd-fstab-generator,
which references systemd.mount, which tells me that I'm not the
first person with this complaint:

   When reading /etc/fstab a few special mount options are
   understood by systemd which influence how dependencies are
   created for mount points from /etc/fstab. [...]  If
   x-systemd.device-timeout= is specified it may be used to
   configure how long systemd should wait for a device to show up
   before giving up on an entry from /etc/fstab. Specify a time in
   seconds or explicitly specify a unit as s, min, h, ms.

I haven't tried this yet, but it should suffice for my problem.

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


Re: [systemd-devel] Suppressing automounting

2014-08-29 Thread Dale R. Worley
 From: Andrei Borzenkov arvidj...@gmail.com

   Here's an interesting fact:  What systemd does (in this situation)
   isn't true automounting; rather it waits for the *first* time the
   device/volume becomes available, and then mounts it.  Any later
   attachments of the volume do not cause mounting (until the next
   reboot).
 
 Well, that's how /etc/fstab always behaved, right? Anything in there is
 automounted just once, when system boots. Later you have to manually
 do it.

That's true, it's how it is expected to work.  But that's not how I
described the situation originally -- I called it automounting -- so
upon discovering that I was wrong, I had to correct the record.

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


[systemd-devel] [PATCH] shutdown: pass own argv to /run/initramfs/shutdown

2014-08-29 Thread Marius Tessmann
Since commit b1e90ec515408aec2702522f6f68c4920b56375b systemd passes
its log settings to systemd-shutdown via command line parameters.
However, systemd-shutdown doesn't pass these parameters to
/run/initramfs/shutdown, causing it to fall back to the default log
settings.

This fixes the following bugs about the shutdown not being quiet
despite quiet being in the kernel parameters:

https://bugs.freedesktop.org/show_bug.cgi?id=79582
https://bugs.freedesktop.org/show_bug.cgi?id=57216
---
 src/core/shutdown.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 1e88b05..d361cbe 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -313,7 +313,7 @@ int main(int argc, char *argv[]) {
 access(/run/initramfs/shutdown, X_OK) == 0) {
 r = switch_root_initramfs();
 if (r = 0) {
-arguments[0] = (char*) /shutdown;
+argv[0] = (char*) /shutdown;
 
 setsid();
 make_console_stdio();
@@ -321,7 +321,7 @@ int main(int argc, char *argv[]) {
 log_info(Successfully changed into root pivot.\n
  Returning to initrd...);
 
-execv(/shutdown, arguments);
+execv(/shutdown, argv);
 log_error(Failed to execute shutdown binary: %m);
 } else
 log_error(Failed to switch root to 
\/run/initramfs\: %s, strerror(-r));
-- 
2.1.0

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


[systemd-devel] [PATCH] Update Russian translation

2014-08-29 Thread Sergey Ptashnick
By analogy with commit 19773.
From 21d0fcba6de31c7710e4dc9e41e80c98d5d15c36 Mon Sep 17 00:00:00 2001
From: Sergey Ptashnick 0comff...@inbox.ru
Date: Fri, 29 Aug 2014 19:29:30 +0400
Subject: [PATCH] po: update Russian translation

---
 po/ru.po |   28 ++--
 1 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/po/ru.po b/po/ru.po
index 1ad4efb..de283f7 100644
--- a/po/ru.po
+++ b/po/ru.po
@@ -1,13 +1,13 @@
 # translation of ru.po to Rissian
 # Julia Dronova juliette@gmail.com, 2013.
-# Sergey Ptashnick 0comff...@inbox.ru, 2013.
+# Sergey Ptashnick 0comff...@inbox.ru, 2013-2014.
 #
 msgid 
 msgstr 
 Project-Id-Version: systemd\n
 Report-Msgid-Bugs-To: 0comff...@inbox.ru\n
 POT-Creation-Date: 2013-03-24 19:22+0300\n
-PO-Revision-Date: 2013-11-18 02:18+0400\n
+PO-Revision-Date: 2014-08-29 19:29+0400\n
 Last-Translator: Sergey Ptashnick 0comff...@inbox.ru\n
 Language: ru\n
 MIME-Version: 1.0\n
@@ -293,3 +293,27 @@ msgstr Привилегированный доступ к системному
 #: ../src/core/org.freedesktop.systemd1.policy.in.in.h:4
 msgid Authentication is required to access the system and service manager.
 msgstr Для привилегированного доступа к системному менеджеру необходимо пройти аутентификацию.
+
+#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:5
+msgid Manage system services or units
+msgstr Управление системными службами и юнитами
+
+#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:6
+msgid Authentication is required to manage system services or units.
+msgstr Для управления системными службами и юнитами, необходимо пройти аутентификацию.
+
+#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:7
+msgid Manage system service or unit files
+msgstr Управление файлами конфигурации системных служб и юнитов
+
+#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:8
+msgid Authentication is required to manage system service or unit files.
+msgstr Для управления файлами конфигурации системных служб и юнитов, необходимо пройти аутентификацию.
+
+#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:9
+msgid Reload the systemd state
+msgstr Перечитать конфигурацию systemd
+
+#: ../src/core/org.freedesktop.systemd1.policy.in.in.h:10
+msgid Authentication is required to reload the systemd state.
+msgstr Чтобы заставить systemd перечитать конфигурацию, необходимо пройти аутентификацию.
-- 
1.7.2.5

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


[systemd-devel] [PATCH] journalctl: Fix --list-boots and --boot

2014-08-29 Thread Jan Janssen
For some reason, sd_journal_query_unique() and sd_journal_add_match() don't
work as they used to. There's a chance boots will be skipped; in my
case only 60 of 393 boots show up. Therefore, do sd_journal_query_unique() first
and then iterate over those to query their timespec.

https://bugs.freedesktop.org/show_bug.cgi?id=79380
---
 src/journal/journalctl.c | 124 ---
 1 file changed, 53 insertions(+), 71 deletions(-)

diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index f3680d1..0aec5fb 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -804,33 +804,45 @@ static int boot_id_cmp(const void *a, const void *b) {
 return _a  _b ? -1 : (_a  _b ? 1 : 0);
 }
 
-static int list_boots(sd_journal *j) {
+static int get_boots(sd_journal *j, boot_id_t **boot_ids, unsigned int *count, 
boot_id_t *query_ref_boot_id) {
 int r;
+boot_id_t *id;
 const void *data;
-unsigned int count = 0;
-int w, i;
 size_t length, allocated = 0;
-boot_id_t *id;
-_cleanup_free_ boot_id_t *all_ids = NULL;
+
+assert(j);
+assert(boot_ids);
+assert(count);
 
 r = sd_journal_query_unique(j, _BOOT_ID);
 if (r  0)
 return r;
 
+*count = 0;
 SD_JOURNAL_FOREACH_UNIQUE(j, data, length) {
 if (length  strlen(_BOOT_ID=))
 continue;
 
-if (!GREEDY_REALLOC(all_ids, allocated, count + 1))
+if (!GREEDY_REALLOC(*boot_ids, allocated, *count + 1))
 return log_oom();
 
-id = all_ids[count];
+id = *boot_ids + *count;
 
 r = sd_id128_from_string(((const char *)data) + 
strlen(_BOOT_ID=), id-id);
 if (r  0)
 continue;
 
-r = sd_journal_add_match(j, data, length);
+(*count)++;
+id-first = id-last = 0;
+}
+
+for (id = *boot_ids; id  *boot_ids + *count; id++) {
+char boot_id_str[9+32+1] = _BOOT_ID=;
+
+sd_journal_flush_matches(j);
+sd_id128_to_string(id-id, boot_id_str + 9);
+
+r = sd_journal_add_match(j, boot_id_str, strlen(boot_id_str));
 if (r  0)
 return r;
 
@@ -839,35 +851,47 @@ static int list_boots(sd_journal *j) {
 return r;
 
 r = sd_journal_next(j);
-if (r  0)
+if (r = 0)
 return r;
-else if (r == 0)
-goto flush;
 
 r = sd_journal_get_realtime_usec(j, id-first);
 if (r  0)
 return r;
 
+if (query_ref_boot_id) {
+if (sd_id128_equal(id-id, query_ref_boot_id-id))
+*query_ref_boot_id = *id;
+continue;
+}
+
 r = sd_journal_seek_tail(j);
 if (r  0)
 return r;
 
 r = sd_journal_previous(j);
-if (r  0)
+if (r = 0)
 return r;
-else if (r == 0)
-goto flush;
 
 r = sd_journal_get_realtime_usec(j, id-last);
 if (r  0)
 return r;
-
-count++;
-flush:
-sd_journal_flush_matches(j);
 }
 
-qsort_safe(all_ids, count, sizeof(boot_id_t), boot_id_cmp);
+sd_journal_flush_matches(j);
+qsort_safe(*boot_ids, *count, sizeof(boot_id_t), boot_id_cmp);
+
+return 0;
+}
+
+static int list_boots(sd_journal *j) {
+int r, w, i;
+unsigned int count = 0;
+boot_id_t *id;
+_cleanup_free_ boot_id_t *all_ids = NULL;
+
+r = get_boots(j, all_ids, count, NULL);
+if (r  0)
+return r;
 
 /* numbers are one less, but we need an extra char for the sign */
 w = DECIMAL_STR_WIDTH(count - 1) + 1;
@@ -885,76 +909,34 @@ static int list_boots(sd_journal *j) {
 return 0;
 }
 
-static int get_relative_boot_id(sd_journal *j, sd_id128_t *boot_id, int 
relative) {
+static int get_boot_id_by_offset(sd_journal *j, sd_id128_t *boot_id, int 
offset) {
 int r;
-const void *data;
 unsigned int count = 0;
-size_t length, allocated = 0;
-boot_id_t ref_boot_id = {SD_ID128_NULL}, *id;
+boot_id_t ref_boot_id = {}, *id;
 _cleanup_free_ boot_id_t *all_ids = NULL;
 
 assert(j);
 assert(boot_id);
 
-r = sd_journal_query_unique(j, _BOOT_ID);
+ref_boot_id.id = *boot_id;
+r = get_boots(j, all_ids, count, ref_boot_id);
 if (r  0)
 return r;
 
-

Re: [systemd-devel] [PATCH 1/8] timesyncd: check if stratum is valid

2014-08-29 Thread Kay Sievers
On Wed, Aug 27, 2014 at 4:47 PM, Miroslav Lichvar mlich...@redhat.com wrote:
 ---
  src/timesync/timesyncd-manager.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

Applied.

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


Re: [systemd-devel] [PATCH 2/8] timesyncd: fix calculation of transmit time

2014-08-29 Thread Kay Sievers
On Wed, Aug 27, 2014 at 4:47 PM, Miroslav Lichvar mlich...@redhat.com wrote:
 The kernel timestamp (recv_time) is made earlier than current time
 (now_ts), use the timestamp captured before sending packet directly.

Applied.

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


Re: [systemd-devel] [PATCH 4/8] timesyncd: check root distance

2014-08-29 Thread Kay Sievers
On Wed, Aug 27, 2014 at 4:47 PM, Miroslav Lichvar mlich...@redhat.com wrote:
 NTPv4 servers don't reply with unsynchronized status when they lost
 synchronization, they only keep increasing the root dispersion and it's
 up to the client to decide at which point they no longer consider it
 synchronized.

 Ignore replies with root distance over 5 seconds.

Applied.

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


Re: [systemd-devel] [PATCH 5/8] timesyncd: use longer PLL time constant

2014-08-29 Thread Kay Sievers
On Wed, Aug 27, 2014 at 4:47 PM, Miroslav Lichvar mlich...@redhat.com wrote:
 The shortest time constant that is stable with the kernel PLL (compiled
 with SHIFT_PLL=2) is about log2 of update interval - 3. Set the constant
 to poll - 2 to make room for one missed update.

Experimentation did show, that the adjustment of the kernel was too
gentle to reach the target time in the desired window, so we made it
more stiff. All timesyncd really cares is that we are not jumping, we
do not really need to smooth out the adjustments.

We would re-check what happens with your patch, I'll hold back
applying this for now.

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


Re: [systemd-devel] [PATCH 6/8] timesyncd: allow two missed replies before reselecting server

2014-08-29 Thread Kay Sievers
On Wed, Aug 27, 2014 at 4:47 PM, Miroslav Lichvar mlich...@redhat.com wrote:
 After receiving a reply from the server, allow two missed replies before
 switching to another server to avoid unnecessary clock hopping when
 packets are getting lost in the network.

Hmm, what's the reason to do this? The servers in the list are not
better or worse or sorted, are they?

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


Re: [systemd-devel] [PATCH 7/8] timesyncd: don't reset polling interval when reselecting server

2014-08-29 Thread Kay Sievers
On Wed, Aug 27, 2014 at 4:47 PM, Miroslav Lichvar mlich...@redhat.com wrote:
 ---
  src/timesync/timesyncd-manager.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

It did not apply without the earlier patch and in systemd we try to
avoid using ! to test integers for 0. Added the fix.

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


Re: [systemd-devel] [PATCH 8/8] timesyncd: wait before reconnecting to first server

2014-08-29 Thread Kay Sievers
On Wed, Aug 27, 2014 at 4:47 PM, Miroslav Lichvar mlich...@redhat.com wrote:
 When all servers are exhausted, wait for one poll interval before trying
 to connect again to the first server in the list. Also, keep increasing
 the polling interval to make sure a client not getting any valid replies
 will not send requests to any server more frequently than is allowed by
 the maximum polling interval.

What is the reason to keep track if we asked all servers, and not just
decrease the frequency of switching them?

There is also some code in src/timesync/timesyncd-manager.c +209:
  /* re-arm timer with increasing timeout,
  in case the packets never arrive back */

which used to work but maybe broke with other changes.

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


Re: [systemd-devel] Suppressing automounting

2014-08-29 Thread Dale R. Worley
 From: wor...@alum.mit.edu (Dale R. Worley)

When reading /etc/fstab a few special mount options are
understood by systemd which influence how dependencies are
created for mount points from /etc/fstab. [...]  If
x-systemd.device-timeout= is specified it may be used to
configure how long systemd should wait for a device to show up
before giving up on an entry from /etc/fstab. Specify a time in
seconds or explicitly specify a unit as s, min, h, ms.
 
 I haven't tried this yet, but it should suffice for my problem.

OK, that test failed:  systemd does *not* stop attempting to mount a
partition after x-systemd.device-timeout has passed.

Here's the line in /etc/fstab:

/dev/Freeze02/Store2/Store ext4 
nofail,x-systemd.device-timeout=1m,defaults 0 0

And here's /run/systemd/generator/Store.mount:

# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
DefaultDependencies=no
After=local-fs-pre.target
Conflicts=umount.target
Before=umount.target

[Mount]
What=/dev/Freeze02/Store2
Where=/Store
Type=ext4
FsckPassNo=0
Options=nofail,x-systemd.device-timeout=1m,defaults

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


Re: [systemd-devel] Systemd-networkd doesn't add static routes anymore

2014-08-29 Thread Moviuro
On Friday 29 August 2014 15:00:06 you wrote:
 On Thu, Aug 28, 2014 at 5:27 PM, Moviuro movi...@gmail.com wrote:
  I'm using systemd 216 on Archlinux (uptodate).
  Everything worked fine at last boot (systemd 215, kernel 3.14.1)
  
  Here is my tap0.network:
  [Match]
  Name=tap0
  
  [Network]
  DHCP=yes
  
  [Route]
  Gateway=10.3.16.1
  Destination=10.3.14.0/24
  
  [Route]
  Gateway=10.3.16.1
  Destination=10.3.15.0/24
  
  And the routes:
  % ip route show
  default via 192.168.1.1 dev wlan0  proto dhcp  metric 1024
  10.3.16.0/24 dev tap0  proto kernel  scope link  src 10.3.16.201
  192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.128
  192.168.1.1 dev wlan0  proto dhcp  scope link  metric 1024
  
  And relevant journal snippet:
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : gained carrier
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network
  is unreachable
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : could not set route: Network
  is unreachable
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : DHCPv4 address
  10.3.16.201/24
  Aug 28 15:37:01 systemd-networkd[371]: tap0 : link configured
  **At this point I do have all my routes**
  **Shutdown begins**
  Aug 28 16:58:54 systemd-networkd[371]: wlan0 : lost carrier
  Aug 28 16:58:54 systemd-networkd[371]: wlan0 : DHCP lease lost
  Aug 28 16:58:54 systemd-networkd[371]: tap0 : lost carrier
  Aug 28 16:58:54 systemd-networkd[371]: tap0 : DHCP lease lost
  -- Reboot --
  Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a
  nonexistent link, ignoring
  Aug 28 16:59:20 systemd-networkd[364]: rtnl: received address for a
  nonexistent link, ignoring
  Aug 28 16:59:23 systemd-networkd[364]: wlan0 : gained carrier
  Aug 28 16:59:24 systemd-networkd[364]: wlan0 : DHCPv4 address
  192.168.1.128/24 via 192.168.1.1
  Aug 28 16:59:24 systemd-networkd[364]: wlan0 : link configured
  Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a
  nonexistent link, ignoring
  Aug 28 16:59:37 systemd-networkd[364]: rtnl: received address for a
  nonexistent link, ignoring
  Aug 28 16:59:37 systemd-networkd[364]: tap0 : gained carrier
  Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network
  is unreachable
  Aug 28 16:59:37 systemd-networkd[364]: tap0 : could not set route: Network
  is unreachable
  Aug 28 16:59:37 systemd-networkd[364]: tap0 : DHCPv4 address
  10.3.16.201/24
  
  Note that tap0 never becomes 'configured'.
  The man does not tell any changes in networkd configuration and my setup
  is  2 months old.
 
 What's happening (in case that was not obvious) is that your
 statically configured routes depend on the address received over DHCP
 to be configured before they are set up. The current code assumes that
 there are no such dependencies so does the static and dynamic setup
 independently (in parallel). I guess we should either support this
 explicitly, or verify the config up-front and fail with a clearer
 error message.
 
 Out of interest, is there some way you could get these routes out of
 your DHCP server (if the server sends routes we should set them up)? I
 mean, your current config would fail if your DHCP server configuration
 was changed, which does not sound ideal...
 
 Cheers,
 
 Tom

So, actually, the VPN server should push the routes to me (just noticed indeed 
this strange workaroud I used). However, when the openvpn server pushes its 
routes, ip route add fails:

openvpn@profile[6649]: /usr/bin/ip route add 10.3.14.0/24 via 10.3.16.1
openvpn@profile[6649]: ERROR: Linux route add command failed: external program 
exited with error status: 2

I'm looking into this issue.

Cheers,
-- 
Moviuro @ Schizophrenia
Our life is the immortals' death

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Bridge not picking up DHCP address

2014-08-29 Thread Mauricio Tavares
  So I have a system 2 interfaces, each of them using dhcp in
different networks (both served by the same nameserver but in
different vlans). Let's begin by showing my config files:

core@coreos ~ $ more /etc/systemd/network/{10,16}-*
::
/etc/systemd/network/10-
bridge.netdev
::
[NetDev]
Name=br0
Kind=bridge
::
/etc/systemd/network/10-bridge.network
::
[Match]
Name=enp0s17

[Network]
Bridge=br0
::
/etc/systemd/network/16-internal.network
::
[Match]
Name=br0

[Network]
DHCP=yes

[DHCP]
UseHostname=false
UseRoutes=false
UseDNS=false
core@coreos ~ $  more /etc/systemd/network/15-management.network
[Match]
Name=enp0s18

[Network]
DHCP=yes

[DHCPv4]
UseHostname=false

core@coreos ~ $

As you can see, br0 is a bridge on the top of enp0s17. Only IP I am
seeing assigned is for enp0s18:

core@coreos ~ $ ip add
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp0s17: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
pfifo_fast master br0 state UNKNOWN qlen 1000
link/ether 00:0c:29:2e:cf:e3 brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fe2e:cfe3/64 scope link
   valid_lft forever preferred_lft forever
3: enp0s18: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc
pfifo_fast state UNKNOWN qlen 1000
link/ether 00:0c:29:2e:cf:ed brd ff:ff:ff:ff:ff:ff
inet 192.168.4.109/24 brd 192.168.4.255 scope global dynamic enp0s18
   valid_lft 5634sec preferred_lft 5634sec
inet6 fe80::20c:29ff:fe2e:cfed/64 scope link
   valid_lft forever preferred_lft forever
4: br0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP
link/ether 1a:f3:7b:69:cb:54 brd ff:ff:ff:ff:ff:ff
inet6 fe80::18f3:7bff:fe69:cb54/64 scope link
   valid_lft forever preferred_lft forever
core@coreos ~ $

We can see my dhcp/dns server really wants to give the box an IP
(10.0.0.0/24) to br0:

Aug 29 09:38:18 venus dhcpd: DHCPDISCOVER from 1a:f3:7b:69:cb:54
(coreos) via eth0
Aug 29 09:38:18 venus dhcpd: DHCPOFFER on 10.0.0.104 to
1a:f3:7b:69:cb:54 (coreos) via eth0
Aug 29 09:38:18 venus dhcpd: DHCPDISCOVER from 00:0c:29:2e:cf:ed
(coreos) via 192.168.4.1
Aug 29 09:38:19 venus dhcpd: DHCPOFFER on 192.168.4.109 to
00:0c:29:2e:cf:ed (coreos) via 192.168.4.1
Aug 29 09:38:19 venus dhcpd: DHCPREQUEST for 192.168.4.109
(192.168.3.10) from 00:0c:29:2e:cf:ed (coreos) via 192.168.4.1
Aug 29 09:38:19 venus dhcpd: DHCPACK on 192.168.4.109 to
00:0c:29:2e:cf:ed (coreos) via 192.168.4.1
Aug 29 09:38:19 venus dhcpd: DHCPDISCOVER from 1a:f3:7b:69:cb:54
(coreos) via eth0
Aug 29 09:38:19 venus dhcpd: DHCPOFFER on 10.0.0.104 to
1a:f3:7b:69:cb:54 (coreos) via eth0
Aug 29 09:38:20 venus dhcpd: DHCPREQUEST for 192.168.4.109
(192.168.3.10) from 00:0c:29:2e:cf:ed (coreos) via 192.168.4.1
Aug 29 09:38:20 venus dhcpd: DHCPACK on 192.168.4.109 to
00:0c:29:2e:cf:ed (coreos) via 192.168.4.1

but that host is not taking it (no DHCPREQUEST nor DHCPACK) on the br0
interface (compare it to enp0s18, which does the entire DHCP dance).
Let's do some asking on the log file (after I restarted networkd in
hope I would get an IP in br0):

journalctl -u systemd-networkd:
Aug 29 13:30:59 coreos systemd[1]: Stopping Network Service...
Aug 29 13:30:59 coreos systemd[1]: Starting Network Service...
Aug 29 13:30:59 coreos systemd-networkd[827]: br0 : netdev ready
Aug 29 13:30:59 coreos systemd-networkd[827]: br0 : gained carrier
Aug 29 13:30:59 coreos systemd-networkd[827]: enp0s18 : gained carrier
Aug 29 13:30:59 coreos systemd-networkd[827]: enp0s17 : gained carrier
Aug 29 13:30:59 coreos systemd-networkd[827]: lo  : gained carrier
Aug 29 13:30:59 coreos systemd[1]: Started Network Service.
Aug 29 13:30:59 coreos systemd-networkd[827]: br0 : link configured
Aug 29 13:30:59 coreos systemd-networkd[827]: enp0s18 : link configured
Aug 29 13:30:59 coreos systemd-networkd[827]: lo  : link configured
Aug 29 13:30:59 coreos systemd-networkd[827]: enp0s17 : link configured
Aug 29 13:31:02 coreos systemd-networkd[827]: enp0s18 : DHCPv4
address 192.168.4.109/24 via 192.168.4.1
Aug 29 13:31:02 coreos systemd-networkd[827]: enp0s18 : link configured
(Time is UTC)

Once again, enp0s18 gets an IP. I do not know if the order shown in
journalctl is important but br0 is being mentioned way before enp0s17.
What am I doing wrong here?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Update Russian translation

2014-08-29 Thread Zbigniew Jędrzejewski-Szmek
On Fri, Aug 29, 2014 at 07:48:47PM +0400, Sergey Ptashnick wrote:
 By analogy with commit 19773.

 From 21d0fcba6de31c7710e4dc9e41e80c98d5d15c36 Mon Sep 17 00:00:00 2001
 From: Sergey Ptashnick 0comff...@inbox.ru
 Date: Fri, 29 Aug 2014 19:29:30 +0400
 Subject: [PATCH] po: update Russian translation
Applied.

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


[systemd-devel] [PATCH] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()

2014-08-29 Thread Michael Biebl
Those symbols were introduced in commit
14cb733684d3c3f50d088a3a370ddf8e8894dfa4 and released in v215


(Please mark this commit as Backport: bugfix)

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From 7f6739c14e019d1b0575fc77d23f4b331591aef2 Mon Sep 17 00:00:00 2001
From: Michael Biebl bi...@debian.org
Date: Sat, 30 Aug 2014 02:01:51 +0200
Subject: [PATCH] libudev: fix symbol version for udev_queue_flush() and
 udev_queue_get_fd()

Those symbols were introduced in commit
14cb733684d3c3f50d088a3a370ddf8e8894dfa4 and released in v215.
---
 src/libudev/libudev.sym | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/libudev/libudev.sym b/src/libudev/libudev.sym
index 95cd1c7..6e40f59 100644
--- a/src/libudev/libudev.sym
+++ b/src/libudev/libudev.sym
@@ -82,8 +82,6 @@ global:
 udev_queue_get_udev;
 udev_queue_get_udev_is_active;
 udev_queue_get_udev_seqnum;
-udev_queue_get_fd;
-udev_queue_flush;
 udev_queue_new;
 udev_queue_ref;
 udev_queue_unref;
@@ -114,3 +112,8 @@ LIBUDEV_199 {
 global:
 udev_device_set_sysattr_value;
 } LIBUDEV_196;
+LIBUDEV_215 {
+global:
+udev_queue_flush;
+udev_queue_get_fd;
+} LIBUDEV_215;
-- 
2.1.0

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


Re: [systemd-devel] [PATCH v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()

2014-08-29 Thread Michael Biebl
Updated patch which the correct version information.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From 67c99a5a1acb4b61fdad687485e8f6c4fd25cc82 Mon Sep 17 00:00:00 2001
From: Michael Biebl bi...@debian.org
Date: Sat, 30 Aug 2014 02:01:51 +0200
Subject: [PATCH] libudev: fix symbol version for udev_queue_flush() and
 udev_queue_get_fd()

Those symbols were introduced in commit
14cb733684d3c3f50d088a3a370ddf8e8894dfa4 and released in v215.
---
 src/libudev/libudev.sym | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/libudev/libudev.sym b/src/libudev/libudev.sym
index 95cd1c7..76726fc 100644
--- a/src/libudev/libudev.sym
+++ b/src/libudev/libudev.sym
@@ -82,8 +82,6 @@ global:
 udev_queue_get_udev;
 udev_queue_get_udev_is_active;
 udev_queue_get_udev_seqnum;
-udev_queue_get_fd;
-udev_queue_flush;
 udev_queue_new;
 udev_queue_ref;
 udev_queue_unref;
@@ -114,3 +112,9 @@ LIBUDEV_199 {
 global:
 udev_device_set_sysattr_value;
 } LIBUDEV_196;
+
+LIBUDEV_215 {
+global:
+udev_queue_flush;
+udev_queue_get_fd;
+} LIBUDEV_199;
-- 
2.1.0

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


Re: [systemd-devel] [LightDM] New multi-seat behaviour

2014-08-29 Thread poma
On 27.08.2014 07:15, Robert Ancell wrote:
 With LightDM 1.11.7 we have new behaviour for multi-seat configuration.
 Thanks to the great work of Laércio de Sousa LightDM now starts seats as
 defined by logind. I have taken the decision to deprecate the old manual
 method of specifying seats as I think it is confusing to have two systems
 trying to define what seats exist.
 
 What this means to users of LightDM 1.12 onwards:
 
 * LightDM will continue to work without logind installed. In this case it
 will just start a single seat (seat0).
 
 * If logind has more than one seat defined then lightdm will attempt to
 automatically start these seats.
 
 * If you were previously defining seats in the LightDM configuration like
 this:
 [Seat:0]
 # ...
 [Seat:1]
 # ...
 These seats will not be started and this configuration will be ignored.
 Please set your system so that logind reports the seats as you had them
 defined (it might do this automatically). If you need to set any per-seat
 LightDM configuration then you can set the sections [Seat:(seat name)]
 where (seat name) is the XDG seat name as reported by logind. The xdg-seat
 property is no longer supported. e.g.
 [Seat:seat-usb-pci-_00_1d_0-usb-0_1_4]
 autologin-user=foo
 The AddSeat() D-Bus method now has no action. Logind has methods to
 dynamically add/remove seats.
 
 * If you need to do a multi-seat setup and you are not running logind
 please shout out. The proposed solution will be to add
 /etc/lightdm/seats.conf that is a fallback in the same way that
 /etc/lightdm/users.conf is a fallback if AccountsService is not available.
 If there's no demand we wont bother adding it.
 
 --Robert
 

You asked, here it is.


poma


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


Re: [systemd-devel] Suppressing automounting

2014-08-29 Thread Andrei Borzenkov
В Fri, 29 Aug 2014 14:59:05 -0400
wor...@alum.mit.edu (Dale R. Worley) пишет:

  From: wor...@alum.mit.edu (Dale R. Worley)
 
 When reading /etc/fstab a few special mount options are
 understood by systemd which influence how dependencies are
 created for mount points from /etc/fstab. [...]  If
 x-systemd.device-timeout= is specified it may be used to
 configure how long systemd should wait for a device to show up
 before giving up on an entry from /etc/fstab. Specify a time in
 seconds or explicitly specify a unit as s, min, h, ms.
  
  I haven't tried this yet, but it should suffice for my problem.
 
 OK, that test failed:  systemd does *not* stop attempting to mount a
 partition after x-systemd.device-timeout has passed.
 

You misunderstand what happens here. x-systemd.device-timeout sets
*job* timeout - i.e. how long systemd waits when requested to mount
filesystem (systemctl start Store.mount in this case).

But when creating mount unit systemd also silently adds dependency to
*device*:

bor@opensuse:~/src/systemd systemctl show boot.mount  -p WantedBy --no-pager
WantedBy=dev-sda1.device

Which has the effect that if device was not present at boot but appears
later, the very appearance of device triggers start of mount unit -
filesystem gets mounted.

And yes, this makes semantic very different from
traditional /etc/fstab. And I'm not sure it has to do it by default ...
honestly, I'm not sure it has to do it at all. I think about situation
where I have persistent device names (SAN, iSCSI, LVM) and need to do
maintenance which causes device nodes disappear and appear again. I
definitely do not want any filesystem to be suddenly mounted in this
case until I have finished my tasks.

And of course it is not documented anywhere.

 Here's the line in /etc/fstab:
 
 /dev/Freeze02/Store2  /Store ext4 
 nofail,x-systemd.device-timeout=1m,defaults 0 0
 
 And here's /run/systemd/generator/Store.mount:
 
 # Automatically generated by systemd-fstab-generator
 
 [Unit]
 SourcePath=/etc/fstab
 DefaultDependencies=no
 After=local-fs-pre.target
 Conflicts=umount.target
 Before=umount.target
 
 [Mount]
 What=/dev/Freeze02/Store2
 Where=/Store
 Type=ext4
 FsckPassNo=0
 Options=nofail,x-systemd.device-timeout=1m,defaults
 

I expected timeout to go in generated unit actually, not in mount
options.

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