[systemd-devel] [PATCH] test-dhcp6-client: Fix option length
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=
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
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=
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
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
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
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
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=
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
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
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
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
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
--- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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()
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
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
В 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