[systemd-devel] ExecStart vs ExecStartPre
Hi there, I'm wondering what the functional difference is between doing: ExecStartPre=/bin/foo ExecStart=/bin/bar and ExecStart=/bin/foo ExecStart=/bin/bar From my read of the systemd.service man page, they appear to have the same behavior in the common use case. The only difference I can see is that groups of ExecStartPre and ExecStart groups can be rearranged. That is, you could have an ExecStartPre line *after* the ExecStart line in the file, and the ExecStartPre would still be executed first. But the ordering of multiple ExecStart (or ExecStartPre) lines in a single systemd.service file matters, because it has explicit ordering as written in the file. Why would someone choose one over the other? What differences am I missing? - Steven ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-stable repo missing some tags
http://cgit.freedesktop.org/systemd/systemd-stable/ The last tag in the repo is v215. Can someone push the v216 through v219? - Steven ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd 219 unmounting things unexpectedly
This is weird. I issued a 'mount' command, which succeeds, but then systemd jumps in and immediately unmounts it. What's going on here? Command issued: mount -o loop,ro someisofile.iso /mnt Journal shows this mess: Mar 29 17:39:06 loki systemd[2460]: Unit mnt.mount is bound to inactive unit. Stopping, too. Mar 29 17:39:06 loki systemd[1]: Unit mnt.mount is bound to inactive unit. Stopping, too. Mar 29 17:39:06 loki systemd[2480]: Unit mnt.mount is bound to inactive unit. Stopping, too. Mar 29 17:39:06 loki systemd[2460]: Unmounting /mnt... Mar 29 17:39:06 loki systemd[2480]: Unmounting /mnt... Mar 29 17:39:06 loki systemd[1]: Unmounting /mnt... Mar 29 17:39:06 loki systemd[1]: mnt.mount mount process exited, code=exited status=32 Mar 29 17:39:06 loki systemd[1]: Unmounted /mnt. Mar 29 17:39:06 loki systemd[1]: Unit mnt.mount entered failed state. Mar 29 17:39:06 loki systemd[2460]: mnt.mount mount process exited, code=exited status=1 Mar 29 17:39:06 loki systemd[2460]: Unmounted /mnt. Mar 29 17:39:06 loki systemd[2460]: Unit mnt.mount entered failed state. Mar 29 17:39:06 loki umount[4173]: umount: /mnt: not mounted Mar 29 17:39:06 loki umount[4175]: umount: /mnt: not mounted Mar 29 17:39:06 loki systemd[1]: mnt.mount failed to run 'mount' task: No such file or directory Mar 29 17:39:06 loki systemd[1]: Failed to mount /mnt. Mar 29 17:39:06 loki systemd[1]: Mounting /mnt... Mar 29 17:39:06 loki systemd[2480]: Unmounted /mnt. systemd[1] is obviously PID1. systemd[2460] is the 'systemd --user' for my user systemd[2480] is the 'systemd --user' for root Why all three observed the '/mnt' mount appearing and all three decided to issue the unmount is beyond me. What inactive unit is it talking about? I don't have a 'mnt.mount' unit anywhere. Why did systemd decide to do this? Is there a way to tell systemd to keep its hands off? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 219 unmounting things unexpectedly
I cherry-picked some patches from git, which fixed it, but they are pretty big patches. At least it works now: commit 628c89cc68ab96fce2de7ebba5933725d147aecc Author: Lennart Poettering lenn...@poettering.net Date: Fri Feb 27 21:55:08 2015 +0100 core: rework device state logic This change introduces a new state tentative for device units. Device units are considered plugged when udev announced them, dead when they are not available in the kernel, and tentative when they are referenced in /proc/self/mountinfo or /proc/swaps but not (yet) announced via udev. This should fix a race when device nodes (like loop devices) are created and immediately mounted. Previously, systemd might end up seeing the mount unit before the device, and would thus pull down the mount because its BindTo dependency on the device would not be fulfilled. commit 98f738b62047229af4a929d7996e2ab04253b02c Author: Colin Walters walt...@verbum.org Date: Tue Feb 17 13:47:34 2015 -0500 unit: When stopping due to BindsTo=, log which unit caused it I'm trying to track down a relatively recent change in systemd which broke OSTree; see https://bugzilla.gnome.org/show_bug.cgi?id=743891 Systemd started to stop sysroot.mount, and this patch should help me debug why at least. While we're here, break on the first unit we find that will deactivate, as there's no point in further iteration commit 5bd4b173605142c7be493aa4d958ebaef21f421d Author: Lennart Poettering lenn...@poettering.net Date: Wed Feb 25 22:05:14 2015 +0100 unit: use weaker dependencies between mount and device units in --user mode When running in user mode unmounting of mount units when a device vanishes is unlikely to work, and even if it would work is already done by PID 1 anyway. HEnce, when creating implicit dependencies between mount units and their backing devices, created a Wants= type dependency in --user mode, but leave a BindsTo= dependency in --system mode. On Sun, Mar 29, 2015 at 5:56 PM, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Mar 29, 2015 at 6:48 PM, Steven Noonan ste...@uplinklabs.net wrote: This is weird. I issued a 'mount' command, which succeeds, but then systemd jumps in and immediately unmounts it. What's going on here? Command issued: mount -o loop,ro someisofile.iso /mnt Journal shows this mess: Mar 29 17:39:06 loki systemd[2460]: Unit mnt.mount is bound to inactive unit. Stopping, too. Mar 29 17:39:06 loki systemd[1]: Unit mnt.mount is bound to inactive unit. Stopping, too. Mar 29 17:39:06 loki systemd[2480]: Unit mnt.mount is bound to inactive unit. Stopping, too. Mar 29 17:39:06 loki systemd[2460]: Unmounting /mnt... Mar 29 17:39:06 loki systemd[2480]: Unmounting /mnt... Mar 29 17:39:06 loki systemd[1]: Unmounting /mnt... Mar 29 17:39:06 loki systemd[1]: mnt.mount mount process exited, code=exited status=32 Mar 29 17:39:06 loki systemd[1]: Unmounted /mnt. Mar 29 17:39:06 loki systemd[1]: Unit mnt.mount entered failed state. Mar 29 17:39:06 loki systemd[2460]: mnt.mount mount process exited, code=exited status=1 Mar 29 17:39:06 loki systemd[2460]: Unmounted /mnt. Mar 29 17:39:06 loki systemd[2460]: Unit mnt.mount entered failed state. Mar 29 17:39:06 loki umount[4173]: umount: /mnt: not mounted Mar 29 17:39:06 loki umount[4175]: umount: /mnt: not mounted Mar 29 17:39:06 loki systemd[1]: mnt.mount failed to run 'mount' task: No such file or directory Mar 29 17:39:06 loki systemd[1]: Failed to mount /mnt. Mar 29 17:39:06 loki systemd[1]: Mounting /mnt... Mar 29 17:39:06 loki systemd[2480]: Unmounted /mnt. systemd[1] is obviously PID1. systemd[2460] is the 'systemd --user' for my user systemd[2480] is the 'systemd --user' for root Why all three observed the '/mnt' mount appearing and all three decided to issue the unmount is beyond me. What inactive unit is it talking about? I don't have a 'mnt.mount' unit anywhere. Why did systemd decide to do this? Is there a way to tell systemd to keep its hands off? https://bugs.freedesktop.org/show_bug.cgi?id=89383 The propose patch works for me. Regards. -- Canek Peláez Valdés Profesor de asignatura, Facultad de Ciencias Universidad Nacional Autónoma de México ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] kdbus in d-bus project
Hi all, Is anyone maintaining a patch series against upstream d-bus for kdbus integration? I checked the kdbus-dev branch linked to by the kdbus Google Code page: https://review.tizen.org/git/?p=platform/upstream/dbus.git;a=shortlog;h=refs/heads/kdbus-dev But it hasn't been updated in over a year, and in that time kdbus has changed almost completely (i.e. now is kdbusfs...). - Steven ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] job_type_lookup_merge assertion failure in systemd
On Tue, Dec 2, 2014 at 5:34 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 12.11.14 09:57, Steven Noonan (ste...@uplinklabs.net) wrote: Hi all, I've been seeing this happen every now and then on a couple machines. When I wake up in the morning and go to log in, I find X11 stopped, and when I try to log in to the VT it hangs when trying to create a session. I am forced to reset the box and then dig through logs on the next boot. This is the cause: We fixed a couple of bugs recently in the code involving job handling. Any chance you can check if you can reproduce the issue with current git of systemd? I haven't been able to reproduce it with some quick testing. I suspect this commit fixed it, since job_type_is_conflicting checks whether either job is a NOP before checking if it's mergeable: commit c21b92ffe7ef939dd32502ac912cf8ad1c5638fd Author: Michal Schmidt mschm...@redhat.com Date: Thu Nov 27 15:23:58 2014 +0100 core: fix transaction destructiveness check once more The previous fix e0312f4db core: fix check for transaction destructiveness broke test-engine (noticed by Zbyszek). Apparently I had a wrong idea of the intended semantics of --fail. The manpage says the operation should fail if it conflicts with a pending job (more specifically: causes an already pending start job to be reversed into a stop job or vice versa). So let's check job_type_is_conflicting, instead of !is_superset. This makes both test-engine and TEST-03-JOBS pass again. diff --git a/src/core/transaction.c b/src/core/transaction.c index b992edd..6ad11b2 100644 --- a/src/core/transaction.c +++ b/src/core/transaction.c @@ -511,7 +511,7 @@ static int transaction_is_destructive(Transaction *tr, JobMode mode, sd_bus_erro assert(!j-transaction_next); if (j-unit-job (mode == JOB_FAIL || j-unit-job-irreversible) -!job_type_is_superset(j-unit-job-type, j-type)) +job_type_is_conflicting(j-unit-job-type, j-type)) return sd_bus_error_setf(e, BUS_ERROR_TRANSACTION_IS_DESTRUCTIVE, Transaction is destructive.); } ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] job_type_lookup_merge assertion failure in systemd
Forgot to explain my setup a bit: Arch Linux, x86_64, systemd 217 On Wed, Nov 12, 2014 at 9:57 AM, Steven Noonan ste...@uplinklabs.net wrote: Hi all, I've been seeing this happen every now and then on a couple machines. When I wake up in the morning and go to log in, I find X11 stopped, and when I try to log in to the VT it hangs when trying to create a session. I am forced to reset the box and then dig through logs on the next boot. This is the cause: Nov 12 08:01:01 dispater crond[12331]: pam_unix(crond:session): session opened for user root by (uid=0) Nov 12 08:01:01 dispater CROND[12332]: (root) CMD (run-parts /etc/cron.hourly) Nov 12 08:01:01 dispater CROND[12331]: pam_unix(crond:session): session closed for user root Nov 12 08:03:37 dispater dhcpcd[1075]: br0: fe80::2472:37ff:fea0:49d2 is unreachable, expiring it Nov 12 08:05:03 dispater dhcpcd[1075]: br0: Router Advertisement from fe80::9844:a4ff:fe69:acd5 Nov 12 08:05:03 dispater dhcpcd[1075]: br0: adding address 2002:6898:6b85:beef:6a05:caff:fe0a:6ec2/64 Nov 12 08:05:03 dispater systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory. Nov 12 08:05:03 dispater systemd[1]: Stopping Name Service Cache Daemon... Nov 12 08:05:03 dispater systemd[1]: Assertion 'a = 0 a _JOB_TYPE_MAX_MERGING' failed at src/core/job.c:314, function job_type_lookup_merge(). Aborting. Nov 12 08:05:03 dispater systemd[1]: Caught ABRT, dumped core as pid 12419. Nov 12 08:05:03 dispater systemd[1]: Freezing execution. Nov 12 08:05:03 dispater systemd-coredump[12420]: Process 12419 (systemd) of user 0 dumped core. Nov 12 08:05:08 dispater acpid[554]: client 608[0:0] has disconnected Nov 12 08:05:08 dispater acpid[554]: client connected from 653[82:82] Nov 12 08:05:08 dispater acpid[554]: 1 client rule loaded I get an IPv6 router advertisement, then dhcpcd (which is spawned by Arch's netctl for the connection) appears to trigger an nscd restart somehow, although I can't find a hook responsible for doing that. When the nscd restart is attempted, an assertion failure is hit in systemd. systemd-coredump did pick up on it, but I'm not certain how useful the dump actually is. Most of the variable contents are optimized out, the best we can get cleanly seems to just be the stack trace, which is this: (gdb) bt #0 0x7f1fa89260c9 in raise () from /usr/lib/libpthread.so.0 #1 0x7f1fa9a5b3c8 in crash.lto_priv.222 (sig=6) at src/core/main.c:168 #2 signal handler called #3 0x7f1fa85a6967 in raise () from /usr/lib/libc.so.6 #4 0x7f1fa85a7d3a in abort () from /usr/lib/libc.so.6 #5 0x7f1fa9a90012 in log_assert_failed (text=text@entry=0x7f1fa9aa78b8 a = 0 a _JOB_TYPE_MAX_MERGING, file=file@entry=0x7f1fa9a9a212 src/core/job.c, line=line@entry=314, func=func@entry=0x7f1fa9ab8370 __PRETTY_FUNCTION__.15000 job_type_lookup_merge) at src/shared/log.c:718 #6 0x7f1fa99e943f in job_type_lookup_merge (a=optimized out, b=optimized out) at src/core/job.c:314 #7 0x7f1fa9a330a5 in job_type_is_superset () at src/core/job.h:198 #8 transaction_is_destructive (e=optimized out, mode=optimized out, tr=optimized out) at src/core/transaction.c:516 #9 transaction_activate (e=optimized out, mode=optimized out, m=optimized out, tr=optimized out) at src/core/transaction.c:722 #10 manager_add_job (m=0x7f1fab518380, type=_JOB_TYPE_MAX_MERGING, unit=0x6, mode=_JOB_MODE_INVALID, override=false, e=0x7f1fa9b07180 buffer, _ret=0x7fff46a422b0) at src/core/manager.c:1224 #11 0x7f1fa9a1bbc5 in bus_unit_queue_job (bus=0x7f1fab5f9090, message=0x7f1fab66dd20, u=0x7f1fab5b5820, type=_JOB_TYPE_MAX_IN_TRANSACTION, mode=JOB_FAIL, reload_if_possible=128, error=0x7fff46a42440) at src/core/dbus-unit.c:777 #12 0x7f1fa9a1bfe6 in bus_unit_method_start_generic (bus=0x7f1fab5f9090, message=0x7f1fab66dd20, u=0x7f1fab5b5820, job_type=_JOB_TYPE_MAX_IN_TRANSACTION, reload_if_possible=reload_if_possible@entry=false, error=0x7fff46a42440) at src/core/dbus-unit.c:383 #13 0x7f1fa9a756c6 in method_start_unit_generic (bus=0x7f1fab5f9090, message=0x7f1fab66dd20, m=0x7f1fab518380, job_type=_JOB_TYPE_MAX_IN_TRANSACTION, reload_if_possible=optimized out, error=0x7fff46a42440) at src/core/dbus-manager.c:478 #14 0x7f1fa9a6b3ee in method_callbacks_run (found_object=optimized out, require_fallback=optimized out, c=optimized out, m=optimized out, bus=optimized out) at src/libsystemd/sd-bus/bus-objects.c:400 #15 object_find_and_run.lto_priv.239 (bus=0x7f1fab5f9090, m=0x7f1fab66dd20, p=0x6 error: Cannot access memory at address 0x6, require_fallback=false, found_object=0x7fff46a425b0) at src/libsystemd/sd-bus/bus-objects.c:1224 #16 0x7f1fa9a85ace in bus_process_object (m=optimized out, bus=0x7f1fab5f9090) at src/libsystemd/sd-bus/bus-objects.c:1340 #17 process_message (m=optimized out, bus=0x7f1fab5f9090) at src/libsystemd/sd-bus/sd-bus.c
Re: [systemd-devel] job_type_lookup_merge assertion failure in systemd
On Wed, Nov 12, 2014 at 11:22 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/12/2014 07:00 PM, Steven Noonan wrote: What's the best way to approach debugging this issue? Should I do a debug build to get a better core dump and wait for this to happen again? Looks like a regression or dupe of [1] not sure why this bug has not been reopen since there is a recent comment there. Add your info and coredump there Thanks, I've done so. I'd like to understand in general how one debugs issues like this with systemd. Given that it's /sbin/init, it's not easy to just attach a debugger to it and poke around. Do people operate primarily on core dumps of -O0 -g builds or something? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] job_type_lookup_merge assertion failure in systemd
On Wed, Nov 12, 2014 at 1:55 PM, Steven Noonan ste...@uplinklabs.net wrote: On Wed, Nov 12, 2014 at 11:22 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/12/2014 07:00 PM, Steven Noonan wrote: What's the best way to approach debugging this issue? Should I do a debug build to get a better core dump and wait for this to happen again? Looks like a regression or dupe of [1] not sure why this bug has not been reopen since there is a recent comment there. Add your info and coredump there Thanks, I've done so. I'd like to understand in general how one debugs issues like this with systemd. Given that it's /sbin/init, it's not easy to just attach a debugger to it and poke around. Do people operate primarily on core dumps of -O0 -g builds or something? Well I've worked out some of the logic that leads to this assertion failure: https://bugs.freedesktop.org/show_bug.cgi?id=67427#c21 I also attached a patch. It does stop the reproducible systemd assertion failure as intended, but I'm not sure I'm doing this change in the right place. The comments around JOB_NOP's declaration suggest that since it's not a mergeable job, it's special-cased in a few places. Perhaps this is just one of those places where special-casing was missed? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/4] Add ENVIRONMENT to hostnamectl
On Mon, Jul 7, 2014 at 5:55 PM, Kay Sievers k...@vrfy.org wrote:
On Tue, Jul 8, 2014 at 2:38 AM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
---
src/hostname/hostnamectl.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..e164086 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,7 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *environment;
char *kernel_name;
char *kernel_release;
char *os_pretty_name;
@@ -92,9 +93,11 @@ static void print_status_info(StatusInfo *i) {
printf(Transient hostname: %s\n, i-hostname);
printf( Icon name: %s\n
- Chassis: %s\n,
+ Chassis: %s\n
+ Environment: %s\n,
Shouldn't we possibly we find a word for environment which explains
itself a bit better? Environment we usually call the numerous
variables of a process or service.
How about stage?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd DHCPv6 segfault
There's a bug in the DHCPv6 implementation somewhere. systemd-networkd was crashing every time it started, so I took a look in gdb: # gdb /usr/lib/systemd/systemd-networkd GNU gdb (GDB) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from /usr/lib/systemd/systemd-networkd...Reading symbols from /usr/lib/debug//usr/lib/systemd/systemd-networkd.debug...done. done. (gdb) run Starting program: /usr/lib/systemd/systemd-networkd warning: Could not load shared library symbols for linux-vdso.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /usr/lib/libthread_db.so.1. [/etc/systemd/network/bridge-dhcp.network:5] Unknown section 'DHCP'. Ignoring. br0 : netdev ready br0 : gained carrier enp3s0 : gained carrier lo : gained carrier [New Thread 0x771fe700 (LWP 1407)] [Thread 0x771fe700 (LWP 1407) exited] br0 : link configured enp3s0 : link configured br0 : DHCPv4 address 192.168.106.64/24 via 192.168.106.1 [New Thread 0x771fe700 (LWP 1408)] br0 : link configured Program received signal SIGSEGV, Segmentation fault. 0x555d3006 in dhcp6_lease_clear_timers (ia=0x20) at src/libsystemd-network/sd-dhcp6-lease.c:30 30 src/libsystemd-network/sd-dhcp6-lease.c: No such file or directory. (gdb) thread apply all bt full Thread 3 (Thread 0x771fe700 (LWP 1408)): #0 0x777c06cd in close () from /usr/lib/libpthread.so.0 No symbol table info available. #1 0x555a7ea2 in close_nointr (fd=9) at src/shared/util.c:169 r = 0 __PRETTY_FUNCTION__ = close_nointr #2 0x555a7f02 in safe_close (fd=9) at src/shared/util.c:205 _saved_errno_ = 0 __PRETTY_FUNCTION__ = safe_close #3 0x555d6331 in close_thread (p=0x9) at src/shared/async.c:76 No locals. #4 0x777b9124 in start_thread () from /usr/lib/libpthread.so.0 No symbol table info available. #5 0x774ed4bd in clone () from /usr/lib/libc.so.6 No symbol table info available. Thread 1 (Thread 0x77fe97c0 (LWP 1403)): #0 0x555d3006 in dhcp6_lease_clear_timers (ia=0x20) at src/libsystemd-network/sd-dhcp6-lease.c:30 __PRETTY_FUNCTION__ = dhcp6_lease_clear_timers #1 0x555d1e9a in client_receive_reply (client=0x55616fd0, reply=0x55611f20, len=126) at src/libsystemd-network/sd-dhcp6-client.c:711 r = 0 lease = 0x5560e200 rapid_commit = true #2 0x555d2302 in client_receive_message (s=0x55617460, fd=11, revents=1, userdata=0x55616fd0) at src/libsystemd-network/sd-dhcp6-client.c:823 client = 0x55616fd0 _dont_destroy_client = 0x55616fd0 message = 0x55611f20 r = 0 buflen = 126 len = 126 __PRETTY_FUNCTION__ = client_receive_message __func__ = client_receive_message #3 0x55576a24 in source_dispatch (s=0x55617460) at src/libsystemd/sd-event/sd-event.c:2001 r = 0 __PRETTY_FUNCTION__ = source_dispatch __func__ = source_dispatch #4 0x55577920 in sd_event_run (e=0x5560d500, timeout=18446744073709551615) at src/libsystemd/sd-event/sd-event.c:2288 ev_queue = 0x7fffda40 ev_queue_max = 15 p = 0x55617460 r = 0 i = 1 m = 1 timedout = false __PRETTY_FUNCTION__ = sd_event_run #5 0x55577a36 in sd_event_loop (e=0x5560d500) at src/libsystemd/sd-event/sd-event.c:2307 r = 1 __PRETTY_FUNCTION__ = sd_event_loop #6 0xd3d7 in main (argc=1, argv=0x7fffdcd8) at src/network/networkd.c:118 m = 0x5560d480 user = 0x555dd280 systemd-network uid = 193 gid = 193 r = 1 __func__ = main (gdb) up #1 0x555d1e9a in client_receive_reply (client=0x55616fd0, reply=0x55611f20, len=126) at src/libsystemd-network/sd-dhcp6-client.c:711 711 src/libsystemd-network/sd-dhcp6-client.c: No such file or directory. (gdb) inspect client-lease $1 = (struct sd_dhcp6_lease *) 0x0 (gdb) In sd-dhcp6-client.c:711, client-lease is NULL, causing the dhcp6_lease_clear_timers call to break (it asserts whether 'ia' is NULL or not, but since
[systemd-devel] systemd.network DHCP section on 215
The docs say to use the section [DHCP] now, and [DHCPv4] is presumably deprecated? I'm getting this on systemd 215: [/etc/systemd/network/bridge-dhcp.network:5] Unknown section 'DHCP'. Ignoring. Looks like networkd-network.c still looks for DHCPv4: r = config_parse(NULL, filename, file, Match\0Network\0Address\0Route\0DHCPv4\0, config_item_perf_lookup, (void*) network_network_gperf_lookup, false, false, network); Shall I submit a patch? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] networkd: accept section DHCP in systemd.network files
---
src/network/networkd-network.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c
index 9ab4f23..9f6de18 100644
--- a/src/network/networkd-network.c
+++ b/src/network/networkd-network.c
@@ -92,7 +92,7 @@ static int network_load_one(Manager *manager, const char
*filename) {
network-dhcp_routes = true;
network-dhcp_sendhost = true;
-r = config_parse(NULL, filename, file,
Match\0Network\0Address\0Route\0DHCPv4\0, config_item_perf_lookup,
+r = config_parse(NULL, filename, file,
Match\0Network\0Address\0Route\0DHCP\0DHCPv4\0, config_item_perf_lookup,
(void*) network_network_gperf_lookup, false, false,
network);
if (r 0) {
log_warning(Could not parse config file %s: %s, filename,
strerror(-r));
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] networkd: don't clear dhcpv6 lease timers if there's no previous lease
If client-lease is NULL, dhcp6_lease_clear_timers will cause a segmentation fault. --- src/libsystemd-network/sd-dhcp6-client.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/libsystemd-network/sd-dhcp6-client.c b/src/libsystemd-network/sd-dhcp6-client.c index 8fdbbfe..a83778e 100644 --- a/src/libsystemd-network/sd-dhcp6-client.c +++ b/src/libsystemd-network/sd-dhcp6-client.c @@ -708,7 +708,8 @@ static int client_receive_reply(sd_dhcp6_client *client, DHCP6Message *reply, return 0; } -dhcp6_lease_clear_timers(client-lease-ia); +if (client-lease) +dhcp6_lease_clear_timers(client-lease-ia); client-lease = sd_dhcp6_lease_unref(client-lease); client-lease = lease; -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
