Re: [systemd-devel] tentative state and unmount on mapper
On Mon, May 18, 2015 at 11:02 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 18.05.15 15:59, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, There have been few discussions about tentative state and unmounting and I am experiencing different problem in the same device logic. I am at 219 + 628c89cc + 496068a8 + 5259bcf6 I have 2 mounts (one is bind mount) on mapper device. /proc/self/mountinfo: 47 37 254:0 / /var/spool/storage/SD_DISK rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered 49 37 254:0 / /var/spool/storage/areas/SD_DISK/root rw,nosuid,nodev,noexec,noatime,nodiratime shared:18 - ext4 /dev/mapper/mmcblk0p1 rw,journal_checksum,commit=1,data=ordered systemctl -t device --all | grep map: dev-mapper-mmcblk0p1.device loaded activating tentative /dev/mapper/mmcblk0p1 As soon as I unmount the bind mount, systemd picks up the change in /proc/self/mountinfo and changes the tentative device to dead and due to that all file systems BindsTo to the device are being unmounted. Application which mounted the partitions is not getting a chance to unmount the fs. Should I enumerate available mount units to see if anyone else has been mounted on the device that is about to be set as DEVICE_DEAD in device_update_found_one()? The right fix is to ensure you ship the right udev rules for your DM setup, so that the devices are properly announced by udev. Note that DM/LVM/... might require compile switches to be specified to enable proper udev support. The tentative state is nothing the system should continously leave devices in. It's a state only used for very short time windows, before udev is up, or when a pseudo device (like a loopback block device) is created and immediately mounted. If you have booted up and see a device in tentative state, then something is really *wrong*. Lennart - Isn't there a race in that short time window that if one tries to unmount stuff, things might go south! - If tentative is just a temporary state, than maybe we shouldn't send the StartupFinished signal until device goes to plugged or dead state. - Seems like poky is enabling udev rules for DM. Maybe we should add required switches on README file to make DM work. So far I found CONFIG_DM_UEVENT on kernel and some switches on lvm, --enable-udev_sync, --enable-udev_rules, --with-udev-prefix=. Umut -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] error when starting the service : Bad message
On Tue, May 19, 2015 at 9:05 AM, arnaud gaboury arnaud.gabo...@gmail.com wrote: I maybe did a typo, but looking carefully it doesn't seems so. Starting this unit file gives me: - ● gunicorn.service - gunicorn daemon Loaded: error (Reason: Bad message) Active: inactive (dead) May 19 08:45:53 poppy systemd[1]: [/etc/systemd/system/gunicorn.service:5] Missing '='. I can't see any missing '=' Issue solved. My service file was not correctly writen Noting to do with systemd. Sorry for the noise /etc/systemd/system/gunicorn.service --- [Unit] Description=gunicorn daemon Requires=gunicorn.socket After=systemd-networkd.service [Service] PIDFile=/run/gunicorn/pid User=django ExecStart=/storage/django/django-slacklog/django_slacklog/venv/bin/gunicorn [Install] WantedBy=multi-user.target - systemd 219.15 on Fedora Thank you for hints -- google.com/+arnaudgabourygabx -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] dev-root.device is not active, results in an umount spree
Hello,
Lennart Poettering [2015-05-18 22:57 +0200]:
+if (dev) {
+sysfs = udev_device_get_syspath(dev);
+if (!sysfs)
+return 0;
+}
Why move this down? In order to keep the patch small and easy to grok,
can this stay up where it was, but simply be enclosed in the if (dev) {}
check?
Right, that was probably just the result of multiple edits/iterations;
moved back.
-if (!S_ISBLK(st.st_mode) !S_ISCHR(st.st_mode))
-return 0;
+dev = udev_device_new_from_devnum(m-udev,
S_ISBLK(st.st_mode) ? 'b' : 'c', st.st_rdev);
+if (!dev errno != ENOENT)
+return log_oom();
Hmm, why are all these errors supposed to be OOM?
Not sure, perhaps hysterical raisins? But..
udev_device_new_from_devnum sets errno correctly, hence we should just
print what it really is set to with log_error_errno(), unless of
course it is ENOENT.
Makes sense, done now. It's an unrelated change to this patch, but if
you don't mind let's clean it up.
+} else {
+if (errno != ENOENT)
+return log_error_errno(errno, Failed to
stat device node file %s: %m, node);
The if else { and if (errn... lines could be merged into one
else if (errno != ..., no?
Right, done.
Updated patch attached. It doesn't look significantly smaller, mostly
because lots of it is an indentation change :/
Re-tested on a normal system, nspawn, LXC, and with ejecting a mounted
CD.
Subject: [PATCH 2/3] device: never transition from tentative to dead
Not following on this patch
Will reply on your other response. TL/DR: Current code in master is
overzealous, this patch is overcautious, this needs some more thought
and work; I don't have an updated patch yet.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 8bbd9d1df6877867ce7958c2e51574b3e74c68e6 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Sun, 17 May 2015 15:07:47 +0200
Subject: [PATCH] device: create units with intended found value
Change device_found_node() to also create a .device unit if a device is not
known by udev; this is the case for tentative devices picked up by mountinfo
(DEVICE_FOUND_MOUNT). With that we can record the found attribute on the
unit.
Change device_setup_unit() to also accept a NULL udev_device, and don't
add the extra udev information in that case.
Previously device_found_node() would not create a .device unit, and
unit_add_node_link() would then create a dead stub one via
manager_load_unit(), so we lost the found attribute and unmounted everything
from that device.
https://launchpad.net/bugs/102
http://lists.freedesktop.org/archives/systemd-devel/2015-May/031658.html
---
src/core/device.c | 51 ---
1 file changed, 24 insertions(+), 27 deletions(-)
diff --git a/src/core/device.c b/src/core/device.c
index 8eca4c2..c784cab 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -292,18 +292,19 @@ static int device_add_udev_wants(Unit *u, struct udev_device *dev) {
static int device_setup_unit(Manager *m, struct udev_device *dev, const char *path, bool main) {
_cleanup_free_ char *e = NULL;
-const char *sysfs;
+const char *sysfs = NULL;
Unit *u = NULL;
bool delete;
int r;
assert(m);
-assert(dev);
assert(path);
-sysfs = udev_device_get_syspath(dev);
-if (!sysfs)
-return 0;
+if (dev) {
+sysfs = udev_device_get_syspath(dev);
+if (!sysfs)
+return 0;
+}
r = unit_name_from_path(path, .device, e);
if (r 0)
@@ -312,6 +313,7 @@ static int device_setup_unit(Manager *m, struct udev_device *dev, const char *pa
u = manager_get_unit(m, e);
if (u
+sysfs
DEVICE(u)-sysfs
!path_equal(DEVICE(u)-sysfs, sysfs)) {
log_unit_debug(u, Device %s appeared twice with different sysfs paths %s and %s, e, DEVICE(u)-sysfs, sysfs);
@@ -336,17 +338,19 @@ static int device_setup_unit(Manager *m, struct udev_device *dev, const char *pa
/* If this was created via some dependency and has not
* actually been seen yet -sysfs will not be
* initialized. Hence initialize it if necessary. */
+if (sysfs) {
+r = device_set_sysfs(DEVICE(u), sysfs);
+if (r 0)
+goto fail;
-r = device_set_sysfs(DEVICE(u), sysfs);
-if (r 0)
-goto fail;
+(void) device_update_description(u, dev, path);
-(void) device_update_description(u, dev,
[systemd-devel] Problem when m-finish_timestamp is set before running manager_loop
Hi all, I found a Startup finished in 155ms (userspace) = 155ms( which is of course incorrect) log on the board at hand, which is caused by something likes: Job cache.mount/stop finished, result=canceled Following the code, I find m-finish_timestamp is set in manager_check_finished(), which is in turn invoked in job_finish_and_invalidate() -- All these happens before the manager_loop running. -- Regards, - cee1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] hostname: Allow comments in /etc/hostname
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:20150519055620.GC3222%40piware.de -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [correct PATCH v2] dev-root.device is not active, results in an umount spree
Lennart Poettering [2015-05-18 23:04 +0200]: On Mon, 18.05.15 16:08, Martin Pitt (martin.p...@ubuntu.com) wrote: Martin Pitt [2015-05-17 15:54 +0200]: This fixes the original systemd immediately unmounts my mounts bug, but not for very long: If you remount or unmount just one mount on a tentative device, mountinfo changes, and device_found_node() now calls device_update_found_one() with add == 0. Then n = add ? (d-found | found) : (d-found ~found); would unset the previous DEVICE_FOUND_MOUNT flag, leaving 0 (i. e. DEVICE_NOT_FOUND). Thus the previously tentative device would once again be set to dead, and systemd would unmount all other mounts from it. This must never happen, we simply can't declare tentative devices as dead and clean up their unmounts, this only works for plugged ones that we know via udev. Eek, I attached the wrong 0002- patch, sorry about that. The above is fixed by the attached patch, please ignore 0002- from the previous mail. For completeness I also re-attach 0001- again (unchanged). Still not getting what the purpose of the 0002 patch is, even in this revision... Please elaborate! I'll try to explain step by step: Say you are booting with plan9 fs, a container, or some other thing with a mount that references a device /dev/foo which isn't actually available as /dev/foo and in udev. Note that you can't reproduce this in nspawn, as it forcefully mounts /sys as r/o, which triggers the unit_type_supported(UNIT_DEVICE) safety check in unit_add_node_link(); this happens in environments with writable /sys. - Boot, dev-foo.device becomes DEVICE_FOUND_MOUNT/tentative - Do some more mounts from /dev/foo, e. g. mkdir /tmp/etc /tmp/boot mount -o bind /etc /tmp/etc mount -o bind /boot /tmp/boot (In practice, you'd probably do such bind mounts with nspawn --bind or lxc.mount.entry) tmp-etc.mount and tmp-boot.mount will be BindsTo=dev-foo.device, and dev-foo.device's status is still unchanged (DEVICE_FOUND_MOUNT/tentative) - Now do umount /tmp/boot. This *also* umounts /tmp/etc! Journal says systemd[1]: Requested transaction contradicts existing jobs: Resource deadlock avoided systemd[1]: Unmounted /tmp/etc. and dev-sda3.device is now inactive/dead, which tears down the bound tmp-etc.mount. Boom! Reason: Unmounting /tmp/boot triggers device_update_found_one(found==DEVICE_FOUND_MOUNT, add==0). d-found previously was DEVICE_FOUND_MOUNT, and this n = add ? (d-found | found) : (d-found ~found); computes the new state to 0 (i. e. DEVICE_NOT_FOUND), and calls device_set_state(DEVICE_DEAD). Thus here we (1) don't consider that dev-foo.device is still bound by other units (tmp-etc.mount) and (2) lose the information that dev-foo.device is tentative. So the problem is that this tentative → dead transition only works if a device is referenced once, but causes overzealous unmounts if there are more references. We need a reference count, or check if the device is bound by other device still. Come to think of it now, we actually already have that: Id=dev-foo.device BoundBy=tmp-boot.mount tmp-etc.mount But my patch doesn't take that into account yet. Devices that show up in /proc/self/mountinfo or /proc/swap, and then disappear again, without ever showing up in udev, need to be cleaned up. That's right, I forgot about that, thanks for catching! So current master is too overzealous, and my current patch never cleans up. So this needs some more work. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] dev-root.device is not active, results in an umount spree
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:20150519062916.GD3222%40piware.de -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] error when starting the service : Bad message
I maybe did a typo, but looking carefully it doesn't seems so. Starting this unit file gives me: - ● gunicorn.service - gunicorn daemon Loaded: error (Reason: Bad message) Active: inactive (dead) May 19 08:45:53 poppy systemd[1]: [/etc/systemd/system/gunicorn.service:5] Missing '='. I can't see any missing '=' /etc/systemd/system/gunicorn.service --- [Unit] Description=gunicorn daemon Requires=gunicorn.socket After=systemd-networkd.service [Service] PIDFile=/run/gunicorn/pid User=django ExecStart=/storage/django/django-slacklog/django_slacklog/venv/bin/gunicorn [Install] WantedBy=multi-user.target - systemd 219.15 on Fedora Thank you for hints -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts
Hello all,
I have a better fix now.
Martin Pitt [2015-05-19 8:59 +0200]:
- Boot, dev-foo.device becomes DEVICE_FOUND_MOUNT/tentative
- Do some more mounts from /dev/foo, e. g.
mkdir /tmp/etc /tmp/boot
mount -o bind /etc /tmp/etc
mount -o bind /boot /tmp/boot
(In practice, you'd probably do such bind mounts with nspawn --bind
or lxc.mount.entry)
tmp-etc.mount and tmp-boot.mount will be BindsTo=dev-foo.device,
and dev-foo.device's status is still unchanged
(DEVICE_FOUND_MOUNT/tentative)
- Now do umount /tmp/boot. This *also* umounts /tmp/etc!
With this patch, the unit states are now as expected:
Id=dev-foo.device
BindsTo=
BoundBy=tmp-boot.mount
ActiveState=activating
SubState=tentative
Id=tmp-boot.mount
BindsTo=dev-foo.device
BoundBy=
ActiveState=active
SubState=mounted
And /tmp/etc stays around. After manually unmounting /tmp/mount, the
device state properly goes to dead:
Id=dev-foo.device
BindsTo=
BoundBy=
ActiveState=inactive
SubState=dead
So the problem is that this tentative → dead transition only works if
a device is referenced once, but causes overzealous unmounts if there
are more references.
We need a reference count, or check if the device is bound by other
device still. Come to think of it now, we actually already have that:
Id=dev-foo.device
BoundBy=tmp-boot.mount tmp-etc.mount
But my patch doesn't take that into account yet.
This one does now. I left a fairly comprehensive commit log as this
isn't that easy to explain/understand. If it's too verbose for you I
can also trim it back a bit.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From bfd1d6f2032dd68d36fbba716ec0e645cb3cbf97 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Tue, 19 May 2015 09:59:21 +0200
Subject: [PATCH 2/2] device: Fix overzealous unmounting of tentative device
mounts
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Scenario: booting with plan9 fs, a container with writable /sys, or some other
thing with a mount that references a device /dev/foo which isn't actually
available as /dev/foo and in udev, i. e. it is state tentative.
- Boot, dev-foo.device becomes DEVICE_FOUND_MOUNT/tentative
- Do some more mounts from /dev/foo, e. g.
mkdir /tmp/etc /tmp/boot
mount -o bind /etc /tmp/etc
mount -o bind /boot /tmp/boot
(In practice, you'd probably do such bind mounts with nspawn --bind
or lxc.mount.entry)
tmp-etc.mount and tmp-boot.mount will be BindsTo=dev-foo.device,
and dev-foo.device's status is still unchanged
(DEVICE_FOUND_MOUNT/tentative)
- Now do umount /tmp/boot. This *also* umounts /tmp/etc!
Journal says
systemd[1]: tmp-boot.mount: Changed mounted - dead
systemd[1]: dev-foo.device: Changed tentative - dead
systemd[1]: tmp-etc.mount: Changed mounted - unmounting
systemd[1]: Unmounted /tmp/etc.
and dev-foo.device is now inactive/dead, which tears down
the bound tmp-etc.mount. Boom!
Reason: Unmounting /tmp/boot triggers
device_update_found_one(found==DEVICE_FOUND_MOUNT, add==0).
d-found previously was DEVICE_FOUND_MOUNT, and this
n = add ? (d-found | found) : (d-found ~found);
computes the new state to 0 (i. e. DEVICE_NOT_FOUND), and calls
device_set_state(DEVICE_DEAD). Thus here we (1) don't consider that
dev-foo.device is still bound by other units (tmp-etc.mount) and (2) lose the
information that dev-foo.device is tentative.
We must only do this tentative → dead transition if there are no other mount
references to dev-foo.device any more, otherwise it must keep its state to
prevent systemd from unmounting everything else from a tentative device as soon
as one mount from it gets unmounted.
Add a check device_update_found_one() to see if there any active mounts bound
to a device when we pick up an unmount from mountinfo, and keep the state if
so.
https://launchpad.net/bugs/102
http://lists.freedesktop.org/archives/systemd-devel/2015-May/031658.html
http://lists.freedesktop.org/archives/systemd-devel/2015-May/031952.html
---
src/core/device.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/core/device.c b/src/core/device.c
index c784cab..65eb773 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -450,6 +450,25 @@ static void device_update_found_one(Device *d, bool add, DeviceFound found, bool
if (n == d-found)
return;
+/* If we found a tentative device via mountinfo which is still
+ * referenced by other mounts than the one that just got unmounted, we
+ * must leave it FOUND_MOUNT/tentative; otherwise we'd trigger
+ * unmounting of all other bound mounts. */
+if (d-found == DEVICE_FOUND_MOUNT n == 0) {
+Iterator i;
+Unit *bound;
+
+
Re: [systemd-devel] [PATCH 2/3] sd-daemon: Use LISTEN_NAMES env when available
On 05/18/2015 11:05 PM, Filipe Brandenburger wrote: Hi, On Mon, May 18, 2015 at 7:26 AM, Krzysztof Opasiak k.opas...@samsung.com wrote: Matching between fds and list of expected paths is done in n^2 I don't think that's the case, because you can just stat() all the names and fstat() all the fds, then sort both lists on inode numbers and then traverse both in order matching inode orders on each list, so it's actually O(n * log n). Not that it matters that much, I don't expect this scheme to be used for a very large number of fds/labels... True but it is not possible using sd_is_*() functions, you have to implement this on your own;) -- Krzysztof Opasiak Samsung RD Institute Poland Samsung Electronics ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd: dbus API for networkd reconfiguration at run-time
Hi Lennart, Thanks for the answers. One more questions. Just a curiosity of mine. Currently, a user has to write scripts if he wants to save the run-time configuration in networkd format or to use a configuration management tool like chef for example. Even with the latter, the user still needs to write scripts. What about saving the run-time configuration in networkd format with networkctl maybe ? Something like networkctl save or networkctl save config with extensions to provide per port configuration saving, output directory for saved configuration and so on ... ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Friday, May 15, 2015 7:34 PM To: Rauta, Alin Cc: systemd-devel@lists.freedesktop.org; Tom Gundersen; Belkind, Nadav Subject: Re: networkd: dbus API for networkd reconfiguration at run-time On Thu, 30.04.15 12:57, Rauta, Alin (alin.ra...@intel.com) wrote: Hi Tom, Lennart, I have some questions regarding dbus API and run-time networkd configuration. I would really appreciate your answers/suggestions. First, when upstreaming BridgeFDB support in networkd, I had (in the first place) a patch composed of 2 parts: - One part for clearing existing configuration; - One part for setting new FDB entries; Since networkd doesn't currently clear existing configuration, only the first part of the patch was accepted. At that time you said that: In the future we plan to get a dbus API where networkd can be reconfigured at run-time (i.e., change which .network file is applied to a link), and then it definitely would make sense to flush routes and addresses when removing the .network from the link, but currently we don't do that at all. Do you have any updates or more information on dbus API (how would this be actually done, how would work) ? Not really, nobody hasbeen working on adding any API for this yet. Given the delays around kdbus I think we should start adding an API for this now however, but this requires careful consideration I figure. I'll try to get this process started with Tom. What extensions to existing networkd functionality would the dbus API bring ? Well, initially it will just open up what we already have. i.e. it will carry an API for creating .netdev interface, and for applying .link and .network files to interfaces. Second, regarding BindCarrier= functionality, would dbus API make it possible to modify the string content or the bind carrier functionality at run-time ? Yes, but I think this would be the second step... Moreover, we currently have the case where networkd is running and has some ports involved in BindCarrier= dependencies. Then some of this ports are run-time added to a team (link aggregation) device (maybe through command line). In this case the carrier dependencies affect the team device functionality creating confusion at one point in time (team tries to get the childs up/down, but the functionality is affected by the carrier dependencies between childs or between childs and other ports outside of the team device). Would dbus API be of any help in this case ? or Do you have any suggestions on how to avoid these cases ? well, sure, if we make BindCarrier= dynamically settable, then you should be able to cover this nicely... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] core: Add LISTEN_NAMES environment variable
On 05/18/2015 09:45 PM, Lennart Poettering wrote:
On Mon, 18.05.15 17:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Mon, May 18, 2015 at 06:01:10PM +0200, Lennart Poettering wrote:
Being able to attach a name to the fds is hence really useful. logind
could use this to attach the session identifier to the fds, and would
hence be able to safely map the fds back to their sessions after
coming back from a restart...
Yeah, that makes sense. But currently there's no proposal how to specify
those identifiers. Would be nice discuss both sides of the proposal at
the same time.
sd_pid_notify_with_fds() would probably have to be extended to be
sd_pid_notify_with_fds2(pid_t pid, int unset_environment, const char
*state, const int *fds, const char* const *names, unsigned n_fds)
Hmm, nah. I think we can avoid adding a new call. Instead we should
explicitly allow non-unique names, and then simply pass the name to
use in a normal sd_notify_with_fds() text field, so that it is applied
to all fds pushed the same way. If you want to send multiple fds with
different ids, then one would do this with multiple
sd_pid_notify_with_fds() invocations.
Example:
sd_pid_notify_with_fds(0, false, FDSTORE=1\nFDNAME=foobar, (int[]) {
STDIN_FILENO, STDOUT_FILENO }, 2);
This would push stdin and stdout of the client into PID 1 and label
both of them foobar. On next invocation the process would then see:
LISTEN_FDS=2
LISTEN_NAMES=foobar:foobar
And what about socket units: we could automatically generate identifiers
like blah.socket-1, foo.socket-1, foo.socket-2 to allow sockets from multiple
socket files be distinguished. In principle this could be made configurable
through a new option, but I don't think it's worth the trouble.
I'd add a new option for this:
FileDescriptorName=waldi
would apply to all fds declared with a .socket unit. If you want to
apply distinct names to multiple fds, you should define them in two
seperate .socket units.
Hope that makes sense?
Make sens for me. I now see your point of view more clearly.
I will update my patches according to your remarks and idea described here.
Thank you for the review and clarification,
--
Krzysztof Opasiak
Samsung RD Institute Poland
Samsung Electronics
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:20150519082346.GG3222%40piware.de -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tentative state and unmount on mapper
Hello Umut, Umut Tezduyar Lindskog [2015-05-19 8:23 +0200]: On Mon, May 18, 2015 at 11:02 PM, Lennart Poettering lenn...@poettering.net wrote: The tentative state is nothing the system should continously leave devices in. It's a state only used for very short time windows, before udev is up, or when a pseudo device (like a loopback block device) is created and immediately mounted. If you have booted up and see a device in tentative state, then something is really *wrong*. Note that it's a permanent state in containers where you don't actually have udev. My very first patch avoided creating these device units at all, to simplify state handling; but Lennart nack'ed this as we want devices/mounts to exist uniformly on real iron and containers, which is certainly a valid point. So if we need the .devices at all, they need to be tentative, as they can't be plugged (not present in the container /dev) nor dead (as that would immediately unmount everything). - Isn't there a race in that short time window that if one tries to unmount stuff, things might go south! Correct, or a permanent situation in containers (with writable /sys at least, as a r/o sys is handled in a special case). Note that I just sent an updated patch for this: http://lists.freedesktop.org/archives/systemd-devel/2015-May/032030.html Would be nice if you could give it a try. - Seems like poky is enabling udev rules for DM. Maybe we should add required switches on README file to make DM work. So far I found CONFIG_DM_UEVENT on kernel and some switches on lvm, --enable-udev_sync, --enable-udev_rules, --with-udev-prefix=. That's still a preferable fix for non-containers of course. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clarification on daemon-reload
On 19 May 2015 at 12:08, Lennart Poettering lenn...@poettering.net wrote: On Tue, 19.05.15 08:22, Igor Bukanov (i...@mir2.org) wrote: In any case, I thought that if I add a dependency like After=my-config-is-ready.target for most default services that can be configured, load a config from a mount or network, generate unit files and place them under /run and then call systemctl daemon-reload, then it would work. But if daemon-reload does not affect what was already scheduled, then I need a better plan. One option is to add a target you enqueue after installing the new configuration and reloading. Then, add all units that shall start to it as dependencies. Thanks, that is a nice solution that does not sounds like a workaround! And if a custom-network-loaded config wants to disable a services that would be otherwise started by default, it could just mask it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tentative state and unmount on mapper
On Tue, 19.05.15 12:43, Martin Pitt (martin.p...@ubuntu.com) wrote: Lennart Poettering [2015-05-19 12:28 +0200]: Note that it's a permanent state in containers where you don't actually have udev. NO! Martin, as mentioned earlier: current systemd will not bother with device units at all in containers, and they hence will not be in tentative state either. Ok ok :) -- FTR, I can't personally stop people from misconfiguring their containers to have writable /sys, I'm just the messenger here. But we've seen that there are other situations where exactly the same situation applies (plan9 in VM, device mapper, etc.): I. e. we have a real-iron machine or VM (writable /sys) with devices which aren't in /dev, and thus end up being tentative. Making a container with writable /sys is just a convenient way to reproduce/test this, I'm not saying it's an actual use case we need to optimize for. So please consider my previous reply to replace container with situations with a mounted device not being in /dev. Again, devices should stay in tentative state only very shortly. If your device stays in tentative state continously after boot, then that's something to fix in your device layer. i.e. the plan9 or device mapper devices need to be fixed so that they show up propery in udev. Yes, we shouldn't unmount tentative devices prematurely, since the time windows exists, but to say this clearly: if you device stays in that state for a long time then that's indication that there's something wrong with your device setup, and not with systemd... You are probably missing udev rules that mark your devices as ready for systemd to pick it up. And you should fix *that*, and not rely on systemd not being too agressive with tentative devices. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] dev-root.device is not active, results in an umount spree
On Tue, 19.05.15 08:29, Martin Pitt (martin.p...@ubuntu.com) wrote: From 8bbd9d1df6877867ce7958c2e51574b3e74c68e6 Mon Sep 17 00:00:00 2001 From: Martin Pitt martin.p...@ubuntu.com Date: Sun, 17 May 2015 15:07:47 +0200 Subject: [PATCH] device: create units with intended found value Applied this one! Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, May 19, 2015 at 1:26 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 19.05.15 00:55, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 14.05.15 21:23, Evert (evert.gen...@planet.nl) wrote: Hi, According to the systemd documentation, Requisite disallows starting a unit unless the specified unit has been started. This seems to work fine, however, if the specified unit has been restarted, this unit will be started too! This is not what should happen and it doesn't happen with a stop and start of the specified unit, so clearly, restart behaves different than stop followed by start. Hmm, I figure this is a bug in systemd. Whenever you have a unit A declare a Requisite= on a unit B then this will actually create two dependencies: the actual Requisite= one plus one in the opposite direction, of type RequiredBy=. Dependencies of type RequiredBy= are mostly internal to systemd, you cannot configure them directly (though you can query them using systemctl show). They are used to track down what to stop when we get systemctl stop by the user. Now, as a special shortcut we currently map Requisite= and Required= to a reverse dependency of RequiredBy=, which is problematichere, since we'll hence make no distinction between the two when processing systemctl stop. I figure we need to split up the reverse dep here, and introduce a seperate RequisiteBy= dependency so that we can avoid this problem... Fixed in git. Please verify. The commit be7d9ff730cb88d7c6a869dd5c47754c78ceaef2 (core: introduce seperate reverse dependencies for Requires= and Requisite=) introduced a regression in rkt: the container does not stop anymore when the main service terminates. In my test, grep says we have one unit using a Requisite* option (systemd-update-utmp-runlevel.service). The main unit file uses one Requires option: == sha512-0543bc3759cd76d21d8605cd55e19bea.service == [Unit] Description=coreos.com/rkt-inspect DefaultDependencies=false OnFailureJobMode=isolate OnFailure=reaper.service Wants=exit-watcher.service Requires=prepare-app@-opt-stage2-sha512\x2d0543bc3759cd76d21d8605cd55e19bea-rootfs.service After=prepare-app@-opt-stage2-sha512\x2d0543bc3759cd76d21d8605cd55e19bea-rootfs.service [Service] Restart=no ExecStart=/diagexec /opt/stage2/sha512-0543bc3759cd76d21d8605cd55e19bea/rootfs / /rkt/env/sha512-0543bc3759cd76d21d8605cd55e19bea 0 0 /inspect -print-msg=Hellooo -sleep=3 User=0 Group=0 I am trying to understand the regression... it's possible that it is rkt using systemd incorrectly. Cheers, Alban ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 2015-05-19 at 01:26 +0200, Lennart Poettering wrote: On Tue, 19.05.15 00:55, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 14.05.15 21:23, Evert (evert.gen...@planet.nl) wrote: According to the systemd documentation, Requisite disallows starting a unit unless the specified unit has been started. This seems to work fine, however, if the specified unit has been restarted, this unit will be started too! This is not what should happen and it doesn't happen with a stop and start of the specified unit, so clearly, restart behaves different than stop followed by start. systemctl stop by the user. Now, as a special shortcut we currently map Requisite= and Required= to a reverse dependency of RequiredBy=, which is problematichere, since we'll hence make no distinction between the two when processing systemctl stop. I figure we need to split up the reverse dep here, and introduce a seperate RequisiteBy= dependency so that we can avoid this problem... Fixed in git. Please verify. I think you're talking about something quite different than the problem described by Evert. The bug report was about a currently stopped depending unit being started by actions on a depended-on unit, which is equally wrong for either Requires= or Requisite=, and is no reason for adding any new distinction between them! And the problem was also about systemctl restart, while systemctl stop worked as expected. Did your change disable propagation of STOP from depended-on unit to the one using Requisite=? If so, I think that's wrong and should be reverted - the documentation says Requisite is similar to Requires=, and gives no reason to expect that propagation in the direction from the depended-on unit to the depending-on unit would be affected. As for Evert's original problem, I think it's that RESTART is propagated to all RequiredBy units unconditionally - even if those are currently stopped! This affects both Requires= and Requisite= in exactly the same way. The problem is not easily visible because systemd aggressively garbage collects units that are not active, and RequiredBy only exists when the requiring unit is loaded; this means currently stopped units are usually hidden from the logic that could incorrectly start them. But if there is some other reason to keep the unit loaded, then the bug is visible. A configuration like this should be sufficient to reproduce: a1.service is arbitrary a2.service has Requires=a1.service a3.service has OnFailure=a1.service a2.service Keep a3.service running to ensure that the OnFailure references keep everything else loaded. Leave a2.service stopped. Restart a1.service; this will start a2.service (via propagated restart), when it clearly should not. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, May 19, 2015 at 2:15 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: As for Evert's original problem, I think it's that RESTART is propagated to all RequiredBy units unconditionally - even if those are currently stopped! This affects both Requires= and Requisite= in exactly the same way. Exactly. At least I do not see anything obvious in code that would check whether dependent units are running or not. And try-restart is pure forntend option which is not propagated to systemd manager itself. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] exec: introduce StandardOutputFile/StandardErrorFile option
On Tue, 19.05.15 11:44, WaLyong Cho (walyong@samsung.com) wrote: To redirect stdout/stderr to file add 'file' option to StandardOutput/StandardError. And to specify the file path, add StandardOutputFile/StandardErrorFile option. If only set StandardOutput/StandardError to 'file' without set of StandardOutputFile/StandardErrorFile option, then it will be redirected to '/dev/null'. This has been requested before, but I am really not convinced this is a good idea since such a simple scheme for stdout/stderr ignores the need for some kind of file rotation. Just filling up the disk like this unbounded isn't really an option. And you cannot really add any kind of rotation if you connect the fds directly. And if you don't connect them directly, then you'd basically implement a second journald which I am really not interested in... Connecting stdin to a file otoh makes more sense, but I doubt that's what you are after... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] exec: introduce StandardOutputFile/StandardErrorFile option
On Tue, 19.05.15 14:19, WaLyong Cho (walyong@samsung.com) wrote: You should start with describing your use case and what is missing in current logging. You can fetch all unit output from journal already. journal is already good logging infrastructure under systemd system. But the centralized logging is very heavy if there are many logging messages. I know, we should reduce the log messages. But it is really hard on short development lifecycle product. We should fix many problems with many logging message. I think, this can correspond to many of embedded system. By this reason, in Tizen, dlog is still main logging system. If the journal isn't as quick as you wish then we should work on that really, rather than bypass it... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] hostname: Allow comments in /etc/hostname
On Tue, 19.05.15 07:56, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey Lennart, Lennart Poettering [2015-05-18 17:12 +0200]: This code will result in ENOENT being returned on OOM... That's not right... Fixed. Also consider using strstrip() here. hostname_cleanup() already filters out whitespace, so I don't think that's needed? true! Given that this same code is needed twice in different components, please add a new call read_etc_hostname() to src/shared/hostname-util.c (which I just added to git). It should then also do hostname_cleanup() on the name, and thus pretty much replace read_and_strip_hostname() entirely in hostname-setup.c. Done. However, I called the function read_hostname_config() and give it a path argument. This is mostly so that we can write tests for it, but maybe one of these days we actually want to use it for other purposes (reading hostnames from container root fs). Thanks! Applied! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] exec: introduce StandardOutputFile/StandardErrorFile option
On Tuesday, May 19, 2015, Lennart Poettering lenn...@poettering.net wrote: On Tue, 19.05.15 14:19, WaLyong Cho (walyong@samsung.com javascript:;) wrote: You should start with describing your use case and what is missing in current logging. You can fetch all unit output from journal already. journal is already good logging infrastructure under systemd system. But the centralized logging is very heavy if there are many logging messages. I know, we should reduce the log messages. But it is really hard on short development lifecycle product. We should fix many problems with many logging message. I think, this can correspond to many of embedded system. By this reason, in Tizen, dlog is still main logging system. If the journal isn't as quick as you wish then we should work on that really, rather than bypass it... As you know we (samsung tizen team) did and doing now. We sent kernel patches to reduce proc reading but rejected and trying to add addiotinal SCM but rejected again. Well we are trying but still don't have successful solution at ARM environment. Thank you, Kyungmin Park Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org javascript:; 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-udev causes slow boot and high load
On Tue, 19.05.15 12:02, Marco Steinacher (mailingli...@websource.ch) wrote: Hi, After upgrading my system to Debian jessie and switching to systemd I have the following problem: 1. During boot there is the message [**] A start job is running for udev Wait for Complete De...on (11s / 3min) after systemd-fsck[452]: /dev/sda5: clean and it takes about 2 minutes until the boot process continues. systemd-analyze blame shows: 2min 2.945s systemd-udev-settle.service systemd-udev-settle.service just waits for devices to be probed. It will wait for the kernel drivers to initialize and the udev rules to be pliugged in. In fact, there's really no need to have this in the boot process at all, unless you are using some broken software that assumes that there's a point in time where all hardware has been plugged in, but such a point in time does not actually exist, and hasn't existed in a long time (simply because USB and other busses can take any time they want before initialization is complete and the devices have shown up). 2. dmesg also shows: [ 254.305831] INFO: task systemd-udevd:296 blocked for more than 120 seconds. [ 254.305962] Not tainted 3.16.0-4-686-pae #1 [ 254.306069] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 254.306165] systemd-udevd D 0 296234 0x0004 and similar messages for the tasks systemd-udevd:308 and systemd-udevd:307. The messages repeat a couple of times (see full log below). There you go: your kernel is hung, some driver or your xen irq handling is borked and hangs during initialization. This is a kernel problem, please report this to the kernel bugzilla. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tentative state and unmount on mapper
On Tue, 19.05.15 10:30, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello Umut, Umut Tezduyar Lindskog [2015-05-19 8:23 +0200]: On Mon, May 18, 2015 at 11:02 PM, Lennart Poettering lenn...@poettering.net wrote: The tentative state is nothing the system should continously leave devices in. It's a state only used for very short time windows, before udev is up, or when a pseudo device (like a loopback block device) is created and immediately mounted. If you have booted up and see a device in tentative state, then something is really *wrong*. Note that it's a permanent state in containers where you don't actually have udev. NO! Martin, as mentioned earlier: current systemd will not bother with device units at all in containers, and they hence will not be in tentative state either. If you run systemd git in a container and try to enqueue a job for a device you get this: # systemctl start dev-foobar.device Operation on or unit type of dev-foobar.device not supported on this system. # Moreover, systemd will not generate any .device dependencies either in this case. All this depends on /sys being mounted read-only. And that's the only scheme we support with systemd in containers. If you mount /sys writable anyway, then the fucked up .device situation is the least of your problems really. To make this clear: if *zero* interest in making systemd work in containers where /sys is writable. This is out of focus for us really. Or to say this a different way: if you leave /sys writable in a container, then we assume that you run in a scheme where /sys (and the related uevent netlink stuff) is fully virtualized, like it might be on some future kernel, where .device units and udevd would then make sense. But on the current kernel that's not the case, and to indicate that to systemd in the container you have to mount /sys read-only. My very first patch avoided creating these device units at all, to simplify state handling; but Lennart nack'ed this as we want devices/mounts to exist uniformly on real iron and containers, NO! As mentioned before and above: the way I see it .device units should *not* exist in containers, as the kernel doesn't virtualize devices for them. which is certainly a valid point. So if we need the .devices at all, they need to be tentative, as they can't be plugged (not present in the container /dev) nor dead (as that would immediately unmount everything). NO! There will not be tentative nor plugged device units in containers, because there will be none at all! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tentative state and unmount on mapper
Lennart Poettering [2015-05-19 12:28 +0200]: Note that it's a permanent state in containers where you don't actually have udev. NO! Martin, as mentioned earlier: current systemd will not bother with device units at all in containers, and they hence will not be in tentative state either. Ok ok :) -- FTR, I can't personally stop people from misconfiguring their containers to have writable /sys, I'm just the messenger here. But we've seen that there are other situations where exactly the same situation applies (plan9 in VM, device mapper, etc.): I. e. we have a real-iron machine or VM (writable /sys) with devices which aren't in /dev, and thus end up being tentative. Making a container with writable /sys is just a convenient way to reproduce/test this, I'm not saying it's an actual use case we need to optimize for. So please consider my previous reply to replace container with situations with a mounted device not being in /dev. Sorry for the confusion! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts
On Tue, 19.05.15 10:23, Martin Pitt (martin.p...@ubuntu.com) wrote:
Hello all,
I have a better fix now.
So the problem is that this tentative → dead transition only works if
a device is referenced once, but causes overzealous unmounts if there
are more references.
Ah, indeed, that makes sense!
We need a reference count, or check if the device is bound by other
device still. Come to think of it now, we actually already have that:
Id=dev-foo.device
BoundBy=tmp-boot.mount tmp-etc.mount
But my patch doesn't take that into account yet.
This one does now. I left a fairly comprehensive commit log as this
isn't that easy to explain/understand. If it's too verbose for you I
can also trim it back a bit.
I have now committed a different fix now, that keeps counting of the
mount points in mount.c, instead of reaching over from device.c.
I only gave this light testing, would be cool if you could check if
this fixes things for you.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=fcd8b266edf0df2b85079fcf7b099cd4028740e6
This commit will now collect two sets of devices while going through
/proc/self/mountinfo: the devices of lines that are no longer there,
and the devices of lines that are there. Only for devices in the
former set that are not in the latter we will now propagate an event
to device.c.
Does this make sense?
+/* If we found a tentative device via mountinfo which is still
+ * referenced by other mounts than the one that just got unmounted,
we
+ * must leave it FOUND_MOUNT/tentative; otherwise we'd trigger
+ * unmounting of all other bound mounts. */
+if (d-found == DEVICE_FOUND_MOUNT n == 0) {
+Iterator i;
+Unit *bound;
+
+SET_FOREACH(bound, UNIT(d)-dependencies[UNIT_BOUND_BY], i) {
+if (bound-type == UNIT_MOUNT
+MOUNT(bound)-state != MOUNT_DEAD
MOUNT(bound)-state != MOUNT_FAILED) {
+log_unit_debug(UNIT(d), Still bound by %s
(%s), keeping state.,
+ bound-id,
mount_state_to_string(MOUNT(bound)-state));
+return;
+}
+}
+log_unit_debug(UNIT(d), Not referenced by any mounts any
more, changing to dead.);
+}
+
previous = d-found;
d-found = n;
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 19.05.15 14:15, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Tue, 2015-05-19 at 01:26 +0200, Lennart Poettering wrote: On Tue, 19.05.15 00:55, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 14.05.15 21:23, Evert (evert.gen...@planet.nl) wrote: According to the systemd documentation, Requisite disallows starting a unit unless the specified unit has been started. This seems to work fine, however, if the specified unit has been restarted, this unit will be started too! This is not what should happen and it doesn't happen with a stop and start of the specified unit, so clearly, restart behaves different than stop followed by start. systemctl stop by the user. Now, as a special shortcut we currently map Requisite= and Required= to a reverse dependency of RequiredBy=, which is problematichere, since we'll hence make no distinction between the two when processing systemctl stop. I figure we need to split up the reverse dep here, and introduce a seperate RequisiteBy= dependency so that we can avoid this problem... Fixed in git. Please verify. I think you're talking about something quite different than the problem described by Evert. The bug report was about a currently stopped depending unit being started by actions on a depended-on unit, which is equally wrong for either Requires= or Requisite=, and is no reason for adding any new distinction between them! And the problem was also about systemctl restart, while systemctl stop worked as expected. Did your change disable propagation of STOP from depended-on unit to the one using Requisite=? If so, I think that's wrong and should be reverted - the documentation says Requisite is similar to Requires=, and gives no reason to expect that propagation in the direction from the depended-on unit to the depending-on unit would be affected. Hmm, you might have a point. But I figure we should still split the reverse of requisite and requires (simply because it is confusing when looking at systemctl show), so I think I'll leave that part in, but otoh i'll make sure the two backwards deps work the same way again... As for Evert's original problem, I think it's that RESTART is propagated to all RequiredBy units unconditionally - even if those are currently stopped! This affects both Requires= and Requisite= in exactly the same way. The problem is not easily visible because systemd aggressively garbage collects units that are not active, and RequiredBy only exists when the requiring unit is loaded; this means currently stopped units are usually hidden from the logic that could incorrectly start them. But if there is some other reason to keep the unit loaded, then the bug is visible. Hmm, so basically you are saying that currently RESTART is propagated as RESTART to all depending units, but you suggest that it should be propagated as TRY_RESTART? Did I get this right? That does make sense indeed. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] buildsys: remove always true autoconf checks
All this checks are always true in any modernish linux system. --- configure.ac | 11 --- 1 file changed, 11 deletions(-) diff --git a/configure.ac b/configure.ac index 3efee22..cd6375b 100644 --- a/configure.ac +++ b/configure.ac @@ -1293,17 +1293,6 @@ AC_CHECK_HEADERS_ONCE([valgrind/memcheck.h valgrind/valgrind.h]) have_myhostname=no AC_ARG_ENABLE(myhostname, AS_HELP_STRING([--disable-myhostname], [disable nss-myhostname support])) if test x$enable_myhostname != xno; then -AC_HEADER_STDC -AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h netinet/in.h stdlib.h string.h sys/socket.h sys/time.h unistd.h nss.h sys/ioctl.h sys/auxv.h]) - -AC_C_CONST -AC_TYPE_SIZE_T -AC_HEADER_TIME - -AC_FUNC_MALLOC -AC_FUNC_SELECT_ARGTYPES -AC_CHECK_FUNCS([gethostbyaddr gethostbyname gettimeofday inet_ntoa memset select socket strcspn strdup strerror strncasecmp strcasecmp strspn]) - have_myhostname=yes fi AM_CONDITIONAL(HAVE_MYHOSTNAME, [test $have_myhostname = yes]) -- 2.4.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] `journalctl -m` does not show /var/log/journal/remote/*
On Mon, Apr 27, 2015 at 04:02:15AM +0900, a wrote:
Hello,
I have some remote journal from vps. It has come with
systemd-journal{-remote,-upload}.
```
$ ls -l /var/log/journal/remote/
remote-10.8.0.2@b9e0664324d845afa9e8a4f9c17db0c8-0001-000513ba70b17fc3.journal
remote-10.8.0.2@b9e0664324d845afa9e8a4f9c17db0c8-00d0-000513ba710c9056.journal
remote-10.8.0.2@b9e0664324d845afa9e8a4f9c17db0c8-061e-000513bb668ea2c1.journal
remote-10.8.0.2.journal
remote-:::10.8.0.2.journal
```
I can see these logs with `journalctl -d /var/log/journal/remote`. But
when I'd tried with '-m' merge flag, it just showed localhost's journal.
How could i see logs from both localhost and remote in realtime?
Good point, this should be supported, but currently is not. Added to TODO.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] buildsys: remove always true autoconf checks
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432077432-9267-1-git-send-email-crrodriguez%40opensuse.org -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts
Hey Lennart, Lennart Poettering [2015-05-19 13:56 +0200]: I have now committed a different fix now, that keeps counting of the mount points in mount.c, instead of reaching over from device.c. I only gave this light testing, would be cool if you could check if this fixes things for you. http://cgit.freedesktop.org/systemd/systemd/commit/?id=fcd8b266edf0df2b85079fcf7b099cd4028740e6 This commit will now collect two sets of devices while going through /proc/self/mountinfo: the devices of lines that are no longer there, and the devices of lines that are there. Only for devices in the former set that are not in the latter we will now propagate an event to device.c. Does this make sense? It does, and it indeed should avoid some round trips. However, it does not work yet. I added this for extra debugging: --- a/src/core/device.c +++ b/src/core/device.c @@ -771,6 +771,9 @@ int device_found_node(Manager *m, const char *node, bool add, DeviceFound found, assert(m); assert(node); +if (node[0] == '/') +log_warning( device_found_node node %s add %i found %i now %i, node, add, found, now); + /* This is called whenever we find a device referenced in * /proc/swaps or /proc/self/mounts. Such a device might be * mounted/enabled at a time where udev has not finished After unmounting /tmp/etc, my dev-sda3.device (which plays the role of dev-foo.device) still becomes dead, and /tmp/boot gets unmounted: unmounting /tmp/etc Id=dev-sda3.device BindsTo= BoundBy= ActiveState=inactive SubState=dead Id=tmp-boot.mount BindsTo= BoundBy= ActiveState=inactive SubState=dead Journal follows. The first bits are from the manual mount commands: | systemd[1]: device_found_node node /dev/sda3 add 1 found 2 now 1 | systemd[1]: device_found_node node /dev/sda3 add 1 found 2 now 1 | systemd[1]: tmp-etc.mount: Changed dead - mounted | systemd[1]: device_found_node node /dev/sda3 add 1 found 2 now 1 | systemd[1]: device_found_node node /dev/sda3 add 1 found 2 now 1 | systemd[1]: device_found_node node /dev/sda3 add 1 found 2 now 1 | systemd[1]: tmp-boot.mount: Changed dead - mounted | systemd[1]: device_found_node node /dev/sda3 add 1 found 2 now 1 | systemd[1]: device_found_node node /dev/sda3 add 1 found 2 now 1 Now umount /tmp/etc happens: | systemd[1]: tmp-etc.mount: Changed mounted - dead | systemd[1]: device_found_node node /dev/sda3 add 0 found 2 now 1 ^ So device_found_node() already gets called here, although there should still be another active mount on sda3. This now causes the usual cleanup unmount slaughter: | systemd[1]: dev-sda3.device: Changed tentative - dead | systemd[1]: tmp-boot.mount: Trying to enqueue job tmp-boot.mount/stop/replace | systemd[1]: tmp-boot.mount: Installed new job tmp-boot.mount/stop as 357 | systemd[1]: tmp-boot.mount: Enqueued job tmp-boot.mount/stop as 357 | systemd[1]: tmp-etc.mount: Collecting. | systemd[1]: Failed to reset devices.list on /lxc/test/system.slice/tmp-boot.mount: Permission denied (FTR, I get thousands of those, but that's unrelated) | systemd[1]: tmp-boot.mount: About to execute: /bin/umount /tmp/boot -n | systemd[1]: tmp-boot.mount: Forked /bin/umount as 641 | systemd[1]: tmp-boot.mount: Changed mounted - unmounting | systemd[1]: Unmounting /tmp/boot... | systemd[641]: tmp-boot.mount: Executing: /bin/umount /tmp/boot -n I'm not sure where this comes from now; there is no manual mount command to bring back /tmp/boot. It looks like it bounces, and quickly remounts /tmp/boot and then unmounts it again: | systemd[1]: device_found_node node /dev/sda3 add 1 found 2 now 1 | systemd[1]: dev-sda3.device: Changed dead - tentative | systemd[1]: tmp-boot.mount: Trying to enqueue job tmp-boot.mount/start/fail | systemd[1]: Requested transaction contradicts existing jobs: Resource deadlock avoided | systemd[1]: device_found_node node /dev/sda3 add 0 found 2 now 1 | systemd[1]: dev-sda3.device: Changed tentative - dead | systemd[1]: Received SIGCHLD from PID 641 (umount). | systemd[1]: Child 641 (umount) died (code=exited, status=0/SUCCESS) | systemd[1]: tmp-boot.mount: Child 641 belongs to tmp-boot.mount | systemd[1]: tmp-boot.mount: Mount process exited, code=exited status=0 | systemd[1]: tmp-boot.mount: Changed unmounting - dead | systemd[1]: tmp-boot.mount: Job tmp-boot.mount/stop finished, result=done | systemd[1]: Unmounted /tmp/boot. | systemd[1]: tmp-boot.mount: Collecting. | systemd[1]: dev-sda3.device: Collecting. My first hunch is that this is caused by calling mount_load_proc_self_mountinfo() in mount_dispatch_io() (src/core/mount.c:1682) *before* it goes through that new SET_FOREACH() loop. That call will already see the removed mount and call device_found_node() with the removal. I'll debug this more closely ASAP, just need to finish something else first. Martin -- Martin Pitt|
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, May 19, 2015 at 3:44 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 19.05.15 13:08, Alban Crequy (al...@endocode.com) wrote: The commit be7d9ff730cb88d7c6a869dd5c47754c78ceaef2 (core: introduce seperate reverse dependencies for Requires= and Requisite=) introduced a regression in rkt: the container does not stop anymore when the main service terminates. In my test, grep says we have one unit using a Requisite* option (systemd-update-utmp-runlevel.service). The main unit file uses one Requires option: I have the suspicion that f3b85044c845de03de05135c1dd5f3298bf3e5a2 might fix your issue, can you check? Yes, it works now. Thanks! (only if you have units that use StopWhenUnneeded=yes, otherwise it's a different issue) Yes, there was a unit with StopWhenUnneeded=yes. Cheers, Alban ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util: fix typo
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1432038369-21930-1-git-send-email-jsynacek%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts
Martin Pitt [2015-05-19 15:17 +0200]:
My first hunch is that this is caused by calling
mount_load_proc_self_mountinfo() in mount_dispatch_io()
(src/core/mount.c:1682) *before* it goes through that new
SET_FOREACH() loop. That call will already see the removed mount and
call device_found_node() with the removal.
That was a red herring. Turns out that your patch only added devices
to around which had mount-just_mounted || mount-just_changed,
which is obviously not the case for mounts which have been around for
a while (and these are the ones we need to keep!). This patch fixes
that; although I'm unsure yet whether we *also* need to record the ones
with mount-just_mounted || mount-just_changed; my gut feeling says
yes, and we need to restructure this a bit to run the set_put(around, ...)
for all mount-is_mounted Mount units. WDYT?
Anyway, with this it behaves as it should.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From fb089bb6dfccd63b395fbda8461bba6ad3541827 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Tue, 19 May 2015 15:55:23 +0200
Subject: [PATCH] mount: Fix mountinfo check for devices which are still around
Fix commit fcd8b266: For recording the devices for which there are still mounts
around in mountinfo we need to consider the mounts which did *not* just get
mounted or changed, but actually have existed for a longer time.
TODO: check if we *also* need to consider mounts with just_{mounted,changed}
---
src/core/mount.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index c1a9ea5..06e0807 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1751,12 +1751,11 @@ static int mount_dispatch_io(sd_event_source *source, int fd, uint32_t revents,
break;
}
-if (mount-parameters_proc_self_mountinfo.what) {
-
-if (set_ensure_allocated(around, string_hash_ops) 0 ||
-set_put(around, mount-parameters_proc_self_mountinfo.what) 0)
-log_oom();
-}
+} else if (mount-state != MOUNT_DEAD mount-state != MOUNT_FAILED
+ mount-parameters_proc_self_mountinfo.what) {
+if (set_ensure_allocated(around, string_hash_ops) 0 ||
+set_put(around, mount-parameters_proc_self_mountinfo.what) 0)
+log_oom();
}
/* Reset the flags for later calls */
--
2.1.4
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 19.05.15 13:08, Alban Crequy (al...@endocode.com) wrote: The commit be7d9ff730cb88d7c6a869dd5c47754c78ceaef2 (core: introduce seperate reverse dependencies for Requires= and Requisite=) introduced a regression in rkt: the container does not stop anymore when the main service terminates. In my test, grep says we have one unit using a Requisite* option (systemd-update-utmp-runlevel.service). The main unit file uses one Requires option: I have the suspicion that f3b85044c845de03de05135c1dd5f3298bf3e5a2 might fix your issue, can you check? (only if you have units that use StopWhenUnneeded=yes, otherwise it's a different issue) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] util: fix typo
From: Jan Synacek jsyna...@redhat.com
---
src/shared/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index da6343f..fd837d9 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1697,7 +1697,7 @@ int loop_write(int fd, const void *buf, size_t nbytes,
bool do_poll) {
int parse_size(const char *t, off_t base, off_t *size) {
-/* Soo, sometimes we want to parse IEC binary suffxies, and
+/* Soo, sometimes we want to parse IEC binary suffixes, and
* sometimes SI decimal suffixes. This function can parse
* both. Which one is the right way depends on the
* context. Wikipedia suggests that SI is customary for
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts
On Tue, May 19, 2015 at 1:56 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Tue, 19.05.15 10:23, Martin Pitt (martin.p...@ubuntu.com) wrote:
Hello all,
I have a better fix now.
So the problem is that this tentative → dead transition only works if
a device is referenced once, but causes overzealous unmounts if there
are more references.
Ah, indeed, that makes sense!
We need a reference count, or check if the device is bound by other
device still. Come to think of it now, we actually already have that:
Id=dev-foo.device
BoundBy=tmp-boot.mount tmp-etc.mount
But my patch doesn't take that into account yet.
This one does now. I left a fairly comprehensive commit log as this
isn't that easy to explain/understand. If it's too verbose for you I
can also trim it back a bit.
I have now committed a different fix now, that keeps counting of the
mount points in mount.c, instead of reaching over from device.c.
I only gave this light testing, would be cool if you could check if
this fixes things for you.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=fcd8b266edf0df2b85079fcf7b099cd4028740e6
This commit will now collect two sets of devices while going through
/proc/self/mountinfo: the devices of lines that are no longer there,
and the devices of lines that are there. Only for devices in the
former set that are not in the latter we will now propagate an event
to device.c.
Does this make sense?
+/* If we found a tentative device via mountinfo which is still
+ * referenced by other mounts than the one that just got unmounted,
we
+ * must leave it FOUND_MOUNT/tentative; otherwise we'd trigger
+ * unmounting of all other bound mounts. */
+if (d-found == DEVICE_FOUND_MOUNT n == 0) {
+Iterator i;
+Unit *bound;
+
+SET_FOREACH(bound, UNIT(d)-dependencies[UNIT_BOUND_BY], i)
{
+if (bound-type == UNIT_MOUNT
+MOUNT(bound)-state != MOUNT_DEAD
MOUNT(bound)-state != MOUNT_FAILED) {
+log_unit_debug(UNIT(d), Still bound by %s
(%s), keeping state.,
+ bound-id,
mount_state_to_string(MOUNT(bound)-state));
+return;
+}
+}
+log_unit_debug(UNIT(d), Not referenced by any mounts any
more, changing to dead.);
+}
+
previous = d-found;
d-found = n;
Lennart
Didn't work for me. Removed device doesn't go in to either cases, so
it never makes it to the around set but it makes it to gone set.
if (!mount-is_mounted)
{
}
else if (mount-just_mounted || mount-just_changed)
{
}
Umut
--
Lennart Poettering, Red Hat
___
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
[systemd-devel] [PATCH v2 4/5] import/pull: Tag replaced with reference
Default pull version set to V2
---
src/import/pull.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/src/import/pull.c b/src/import/pull.c
index ef7b035..0f2ad92 100644
--- a/src/import/pull.c
+++ b/src/import/pull.c
@@ -227,7 +227,7 @@ static void on_dkr_finished(DkrPull *pull, int error, void
*userdata) {
static int pull_dkr(int argc, char *argv[], void *userdata) {
_cleanup_(dkr_pull_unrefp) DkrPull *pull = NULL;
_cleanup_event_unref_ sd_event *event = NULL;
-const char *name, *tag, *local;
+const char *name, *reference, *local, *digest;
int r;
if (!arg_dkr_index_url) {
@@ -240,13 +240,19 @@ static int pull_dkr(int argc, char *argv[], void
*userdata) {
return -EINVAL;
}
-tag = strchr(argv[1], ':');
-if (tag) {
-name = strndupa(argv[1], tag - argv[1]);
-tag++;
+digest = strchr(argv[1], '@');
+if (digest) {
+reference = digest + 1;
+name = strndupa(argv[1], digest - argv[1]);
+}
+
+reference = strchr(argv[1], ':');
+if (reference) {
+name = strndupa(argv[1], reference - argv[1]);
+reference++;
} else {
name = argv[1];
-tag = latest;
+reference = latest;
}
if (!dkr_name_is_valid(name)) {
@@ -254,8 +260,8 @@ static int pull_dkr(int argc, char *argv[], void *userdata)
{
return -EINVAL;
}
-if (!dkr_tag_is_valid(tag)) {
-log_error(Tag name '%s' is not valid., tag);
+if (!dkr_ref_is_valid(reference)) {
+log_error(Tag name '%s' is not valid., reference);
return -EINVAL;
}
@@ -288,9 +294,9 @@ static int pull_dkr(int argc, char *argv[], void *userdata)
{
}
}
-log_info(Pulling '%s' with tag '%s', saving as '%s'., name,
tag, local);
+log_info(Pulling '%s' with reference '%s', saving as '%s'.,
name, reference, local);
} else
-log_info(Pulling '%s' with tag '%s'., name, tag);
+log_info(Pulling '%s' with reference '%s'., name, reference);
r = sd_event_default(event);
if (r 0)
@@ -304,7 +310,7 @@ static int pull_dkr(int argc, char *argv[], void *userdata)
{
if (r 0)
return log_error_errno(r, Failed to allocate puller: %m);
-r = dkr_pull_start(pull, name, tag, local, arg_force);
+r = dkr_pull_start(pull, name, reference, local, arg_force,
DKR_PULL_V2);
if (r 0)
return log_error_errno(r, Failed to pull image: %m);
--
2.1.0
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] [ANNOUNCE] Separating gudev from systemd
Hi We're about to remove gudev from the systemd repository, as it is in no way related to the systemd code-base, nor used by the systemd project. To preserve backwards compatibility, gudev was extracted into a separate repository and is now managed on gnome.org: Homepage: https://wiki.gnome.org/Projects/libgudev Bugtracker: http://bugzilla.gnome.org/browse.cgi?product=libgudev Releases: http://download.gnome.org/sources/libgudev/ Repository: http://git.gnome.org/browse/libgudev/ ArchLinux: https://aur.archlinux.org/packages/li/libgudev/PKGBUILD Others: TBD The new libgudev project is binary-compatible to gudev as provided by systemd-219. Distributions are encouraged to pass --disable-gudev to systemd and provide gudev via the libgudev project. We haven't decided at which point gudev will be dropped from the systemd repository, but chances are systemd-221 will not include it, anymore. If there are any issues, please let me know. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts
On Tue, 19.05.15 16:05, Martin Pitt (martin.p...@ubuntu.com) wrote: That was a red herring. Turns out that your patch only added devices to around which had mount-just_mounted || mount-just_changed, which is obviously not the case for mounts which have been around for a while (and these are the ones we need to keep!). This patch fixes that; although I'm unsure yet whether we *also* need to record the ones with mount-just_mounted || mount-just_changed; my gut feeling says yes, and we need to restructure this a bit to run the set_put(around, ...) for all mount-is_mounted Mount units. WDYT? Yes, we need to also record those which were just mounted or changed, in case systemd rereads /proc/self/mountinfo at a time where two mounts where created at once from the same device. I now committed a change to implement that, can you check if this fixes the issue for you? Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Timers and Service Conditions
On Thu, 02.04.15 12:01, Merten Sach (mer...@tabinin.eu) wrote: Hi, I have a problem with a timer that trigges a service that has a condition set. The timer defines the following properties: [Timer] OnBootSec=1h OnUnitInactiveSec=1h Unit=autobackup@%i.service The service unit set the following condition: ConditionACPower=true When I'm now on AC power the service is never active and, therefor, the inactive timestamp is never set. This causes the timer to be triggered repeatedly which causes a very high system load. I want to keep the timer relative to bootup. So, can I avoid OnCalendar= ? Hmm, so I tried to reproduce this issue here, bu I couldn't. I used the same unit files as you propose, but this works cleanly, as the code already contains checks that if the triggered unit doesn't have an initialized inactive timestamp we'll fall back to the last trigger time of the unit. And if that's not set, we'll simply not set any timer... Hence, which version of systemd did you run this into with? Any chance you can check if you can reproduce this with current git or at least 219? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 2/5] shared/json: Added DOM-like JSON parser
This makes working with complexly structured documents easy
and more reliable as the parser is not susceptible to
element re-ordering.
Also fixes a bug when the tokenizer would choke after reading
a number.
---
src/shared/json.c | 432 --
src/shared/json.h | 37 +
2 files changed, 459 insertions(+), 10 deletions(-)
diff --git a/src/shared/json.c b/src/shared/json.c
index 45c8ece..f6c44f4 100644
--- a/src/shared/json.c
+++ b/src/shared/json.c
@@ -21,17 +21,171 @@
#include sys/types.h
#include math.h
-
#include macro.h
-#include util.h
#include utf8.h
#include json.h
-enum {
-STATE_NULL,
-STATE_VALUE,
-STATE_VALUE_POST,
-};
+int json_variant_new(JsonVariant **ret, JsonVariantType type) {
+JsonVariant *v;
+v = new0(JsonVariant, 1);
+if (!v)
+return -ENOMEM;
+v-type = type;
+*ret = v;
+return 0;
+}
+
+static int json_variant_deep_copy(JsonVariant *ret, JsonVariant *variant) {
+assert(ret);
+assert(variant);
+
+ret-type = variant-type;
+ret-size = variant-size;
+
+if (variant-type == JSON_VARIANT_STRING) {
+ret-string = memdup(variant-string, variant-size+1);
+if (!ret-string)
+return -ENOMEM;
+} else if (variant-type == JSON_VARIANT_ARRAY || variant-type ==
JSON_VARIANT_OBJECT) {
+ret-objects = new0(JsonVariant, variant-size);
+if (!ret-objects)
+return -ENOMEM;
+
+for (unsigned i = 0; i variant-size; ++i) {
+int r;
+r = json_variant_deep_copy(ret-objects[i],
variant-objects[i]);
+if (r 0)
+return r;
+}
+}
+else
+ret-value = variant-value;
+
+return 0;
+}
+
+static JsonVariant *json_object_unref(JsonVariant *variant);
+
+static JsonVariant *json_variant_unref_inner(JsonVariant *variant) {
+if (!variant)
+return NULL;
+
+if (variant-type == JSON_VARIANT_ARRAY || variant-type ==
JSON_VARIANT_OBJECT)
+return json_object_unref(variant);
+
+else if (variant-type == JSON_VARIANT_STRING)
+free(variant-string);
+
+return NULL;
+}
+
+static JsonVariant *json_raw_unref(JsonVariant *variant, size_t size) {
+if (!variant)
+return NULL;
+
+for (size_t i = 0; i size; ++i)
+json_variant_unref_inner(variant[i]);
+
+free(variant);
+return NULL;
+}
+
+static JsonVariant *json_object_unref(JsonVariant *variant) {
+assert(variant);
+if (!variant-objects)
+return NULL;
+
+for (unsigned i = 0; i variant-size; ++i)
+json_variant_unref_inner(variant-objects[i]);
+
+free(variant-objects);
+return NULL;
+}
+
+static JsonVariant **json_variant_array_unref(JsonVariant **variant) {
+size_t i = 0;
+JsonVariant *p = NULL;
+
+if (!variant)
+return NULL;
+
+while((p = (variant[i++])) != NULL) {
+if (p-type == JSON_VARIANT_STRING)
+ free(p-string);
+free(p);
+}
+
+free(variant);
+
+return NULL;
+}
+DEFINE_TRIVIAL_CLEANUP_FUNC(JsonVariant **, json_variant_array_unref);
+
+JsonVariant *json_variant_unref(JsonVariant *variant) {
+if (!variant)
+return NULL;
+
+if (variant-type == JSON_VARIANT_ARRAY || variant-type ==
JSON_VARIANT_OBJECT)
+return json_object_unref(variant);
+
+else if (variant-type == JSON_VARIANT_STRING)
+free(variant-string);
+
+free(variant);
+
+return NULL;
+}
+
+char *json_variant_string(JsonVariant *variant){
+assert(variant);
+assert(variant-type == JSON_VARIANT_STRING);
+
+return variant-string;
+}
+
+bool json_variant_bool(JsonVariant *variant) {
+assert(variant);
+assert(variant-type == JSON_VARIANT_BOOLEAN);
+
+return variant-value.boolean;
+}
+
+intmax_t json_variant_integer(JsonVariant *variant) {
+assert(variant);
+assert(variant-type == JSON_VARIANT_INTEGER);
+
+return variant-value.integer;
+}
+
+double json_variant_real(JsonVariant *variant) {
+assert(variant);
+assert(variant-type == JSON_VARIANT_REAL);
+
+return variant-value.real;
+}
+
+JsonVariant *json_variant_element(JsonVariant *variant, unsigned index) {
+assert(variant);
+assert(variant-type == JSON_VARIANT_ARRAY || variant-type ==
JSON_VARIANT_OBJECT);
+assert(index variant-size);
+assert(variant-objects);
+
+return variant-objects[index];
+}
+
+JsonVariant *json_variant_value(JsonVariant *variant, const
[systemd-devel] [PATCH v2 1/5] shared/import-util: Tag renamed to reference
Added (sha256) digest validation function
---
src/shared/import-util.c | 21 +
src/shared/import-util.h | 2 ++
2 files changed, 23 insertions(+)
diff --git a/src/shared/import-util.c b/src/shared/import-util.c
index 660d92a..001a8a3 100644
--- a/src/shared/import-util.c
+++ b/src/shared/import-util.c
@@ -150,6 +150,27 @@ int raw_strip_suffixes(const char *p, char **ret) {
return 0;
}
+bool dkr_digest_is_valid(const char *digest) {
+/* 7 chars for prefix, 64 chars for the digest itself */
+if (strlen(digest) != 71)
+return false;
+
+return startswith(digest, sha256:) in_charset(digest + 7,
0123456789abcdef);
+}
+
+bool dkr_ref_is_valid(const char *ref) {
+const char *colon;
+
+if (isempty(ref))
+return false;
+
+colon = strchr(ref, ':');
+if (!colon)
+return filename_is_valid(ref);
+
+return dkr_digest_is_valid(ref);
+}
+
bool dkr_name_is_valid(const char *name) {
const char *slash, *p;
diff --git a/src/shared/import-util.h b/src/shared/import-util.h
index ff155b0..7bf7d4c 100644
--- a/src/shared/import-util.h
+++ b/src/shared/import-util.h
@@ -44,4 +44,6 @@ int raw_strip_suffixes(const char *name, char **ret);
bool dkr_name_is_valid(const char *name);
bool dkr_id_is_valid(const char *id);
+bool dkr_ref_is_valid(const char *ref);
+bool dkr_digest_is_valid(const char *digest);
#define dkr_tag_is_valid(tag) filename_is_valid(tag)
--
2.1.0
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] [PATCH v2 3/5] test/test-json: Tests for the tokenizer bugfix and the DOM parser
The DOM parser tests are accompanied with structure and element analysis
---
src/test/test-json.c | 97
1 file changed, 97 insertions(+)
diff --git a/src/test/test-json.c b/src/test/test-json.c
index 24dc700..c4b4a22 100644
--- a/src/test/test-json.c
+++ b/src/test/test-json.c
@@ -72,6 +72,98 @@ static void test_one(const char *data, ...) {
va_end(ap);
}
+typedef void (*Test)(JsonVariant *);
+
+static void test_file(const char *data, Test test) {
+JsonVariant *v = NULL;
+int r = json_parse(data, v);
+
+assert_se(r == 0);
+assert_se(v != NULL);
+assert_se(v-type == JSON_VARIANT_OBJECT);
+
+if (test)
+test(v);
+
+json_variant_unref(v);
+}
+
+static void test_1(JsonVariant *v) {
+JsonVariant *p, *q;
+unsigned i;
+
+/* 3 keys + 3 values */
+assert_se(v-size == 6);
+
+/* has k */
+p = json_variant_value(v, k);
+assert_se(p p-type == JSON_VARIANT_STRING);
+
+/* k equals v */
+assert_se(streq(json_variant_string(p), v));
+
+/* has foo */
+p = json_variant_value(v, foo);
+assert_se(p p-type == JSON_VARIANT_ARRAY p-size == 3);
+
+/* check foo[0] = 1, foo[1] = 2, foo[2] = 3 */
+for (i = 0; i 3; ++i) {
+q = json_variant_element(p, i);
+assert_se(q q-type == JSON_VARIANT_INTEGER
json_variant_integer(q) == (i+1));
+}
+
+/* has bar */
+p = json_variant_value(v, bar);
+assert_se(p p-type == JSON_VARIANT_OBJECT p-size == 2);
+
+/* zap is null */
+q = json_variant_value(p, zap);
+assert_se(q q-type == JSON_VARIANT_NULL);
+}
+
+static void test_2(JsonVariant *v) {
+JsonVariant *p, *q;
+
+/* 2 keys + 2 values */
+assert_se(v-size == 4);
+
+/* has mutant */
+p = json_variant_value(v, mutant);
+assert_se(p p-type == JSON_VARIANT_ARRAY p-size == 4);
+
+/* mutant[0] == 1 */
+q = json_variant_element(p, 0);
+assert_se(q q-type == JSON_VARIANT_INTEGER
json_variant_integer(q) == 1);
+
+/* mutant[1] == null */
+q = json_variant_element(p, 1);
+assert_se(q q-type == JSON_VARIANT_NULL);
+
+/* mutant[2] == 1 */
+q = json_variant_element(p, 2);
+assert_se(q q-type == JSON_VARIANT_STRING
streq(json_variant_string(q), 1));
+
+/* mutant[3] == JSON_VARIANT_OBJECT */
+q = json_variant_element(p, 3);
+assert_se(q q-type == JSON_VARIANT_OBJECT q-size == 2);
+
+/* has 1 */
+p = json_variant_value(q, 1);
+assert_se(p p-type == JSON_VARIANT_ARRAY p-size == 2);
+
+/* 1[0] == 1 */
+q = json_variant_element(p, 0);
+assert_se(q q-type == JSON_VARIANT_INTEGER
json_variant_integer(q) == 1);
+
+/* 1[1] == 1 */
+q = json_variant_element(p, 1);
+assert_se(q q-type == JSON_VARIANT_STRING
streq(json_variant_string(q), 1));
+
+/* has blah */
+p = json_variant_value(v, blah);
+assert_se(p p-type == JSON_VARIANT_REAL
fabs(json_variant_real(p) - 1.27) 0.001);
+}
+
int main(int argc, char *argv[]) {
test_one(x, -EINVAL);
@@ -102,5 +194,10 @@ int main(int argc, char *argv[]) {
test_one(\\\udc00\\udc00\, -EINVAL);
test_one(\\\ud801\\udc37\, JSON_STRING, \xf0\x90\x90\xb7,
JSON_END);
+test_one([1, 2], JSON_ARRAY_OPEN, JSON_INTEGER, 1, JSON_COMMA,
JSON_INTEGER, 2, JSON_ARRAY_CLOSE, JSON_END);
+
+test_file({\k\: \v\, \foo\: [1, 2, 3], \bar\: {\zap\:
null}}, test_1);
+test_file({\mutant\: [1, null, \1\, {\1\: [1, \1\]}],
\blah\: 1.27}, test_2);
+
return 0;
}
--
2.1.0
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
Re: [systemd-devel] [PATCH] util: fix typo
Hi
On Tue, May 19, 2015 at 2:26 PM, jsyna...@redhat.com wrote:
From: Jan Synacek jsyna...@redhat.com
---
src/shared/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Applied!
Thanks
David
diff --git a/src/shared/util.c b/src/shared/util.c
index da6343f..fd837d9 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1697,7 +1697,7 @@ int loop_write(int fd, const void *buf, size_t nbytes,
bool do_poll) {
int parse_size(const char *t, off_t base, off_t *size) {
-/* Soo, sometimes we want to parse IEC binary suffxies, and
+/* Soo, sometimes we want to parse IEC binary suffixes, and
* sometimes SI decimal suffixes. This function can parse
* both. Which one is the right way depends on the
* context. Wikipedia suggests that SI is customary for
--
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
[systemd-devel] [PATCH v2 5/5] import/pull-dkr: V2 image specification and manifest support
The maximum number of layers changed to 127, as in Dkr.
---
src/import/pull-dkr.c | 542 +-
src/import/pull-dkr.h | 3 +-
2 files changed, 491 insertions(+), 54 deletions(-)
diff --git a/src/import/pull-dkr.c b/src/import/pull-dkr.c
index 0eefec5..577bd5a 100644
--- a/src/import/pull-dkr.c
+++ b/src/import/pull-dkr.c
@@ -51,6 +51,9 @@ struct DkrPull {
sd_event *event;
CurlGlue *glue;
+char *index_protocol;
+char *index_address;
+
char *index_url;
char *image_root;
@@ -61,9 +64,10 @@ struct DkrPull {
PullJob *layer_job;
char *name;
-char *tag;
+char *reference;
char *id;
+char *response_digest;
char *response_token;
char **response_registries;
@@ -87,9 +91,9 @@ struct DkrPull {
#define PROTOCOL_PREFIX https://;
#define HEADER_TOKEN X-Do /* the HTTP header for the auth token */
cker-Token:
-#define HEADER_REGISTRY X-Do /*the HTTP header for the registry */
cker-Endpoints:
-
-#define LAYERS_MAX 2048
+#define HEADER_REGISTRY X-Do /* the HTTP header for the registry */
cker-Endpoints:
+#define HEADER_DIGEST Do /* the HTTP header for the manifest digest */
cker-Content-Digest:
+#define LAYERS_MAX 127
static void dkr_pull_job_on_finished(PullJob *j);
@@ -117,12 +121,13 @@ DkrPull* dkr_pull_unref(DkrPull *i) {
}
free(i-name);
-free(i-tag);
+free(i-reference);
free(i-id);
free(i-response_token);
-free(i-response_registries);
strv_free(i-ancestry);
free(i-final_path);
+free(i-index_address);
+free(i-index_protocol);
free(i-index_url);
free(i-image_root);
free(i-local);
@@ -416,10 +421,27 @@ static int dkr_pull_add_token(DkrPull *i, PullJob *j) {
return 0;
}
+static int dkr_pull_add_bearer_token(DkrPull *i, PullJob *j) {
+const char *t = NULL;
+
+assert(i);
+assert(j);
+
+if (i-response_token)
+t = strjoina(Authorization: Bearer , i-response_token);
+else
+return -EINVAL;
+
+j-request_header = curl_slist_new(Accept: application/json, t,
NULL);
+if (!j-request_header)
+return -ENOMEM;
+
+return 0;
+}
+
static bool dkr_pull_is_done(DkrPull *i) {
assert(i);
assert(i-images_job);
-
if (i-images_job-state != PULL_JOB_DONE)
return false;
@@ -429,7 +451,7 @@ static bool dkr_pull_is_done(DkrPull *i) {
if (!i-ancestry_job || i-ancestry_job-state != PULL_JOB_DONE)
return false;
-if (!i-json_job || i-json_job-state != PULL_JOB_DONE)
+if (i-json_job i-json_job-state != PULL_JOB_DONE)
return false;
if (i-layer_job i-layer_job-state != PULL_JOB_DONE)
@@ -441,8 +463,9 @@ static bool dkr_pull_is_done(DkrPull *i) {
return true;
}
-static int dkr_pull_make_local_copy(DkrPull *i) {
+static int dkr_pull_make_local_copy(DkrPull *i, DkrPullVersion version) {
int r;
+_cleanup_free_ char *p = NULL;
assert(i);
@@ -455,10 +478,30 @@ static int dkr_pull_make_local_copy(DkrPull *i) {
return log_oom();
}
-r = pull_make_local_copy(i-final_path, i-image_root, i-local,
i-force_local);
+if (version == DKR_PULL_V2) {
+r = path_get_parent(i-image_root, p);
+if (r 0)
+return r;
+}
+
+r = pull_make_local_copy(i-final_path, p ?: i-image_root, i-local,
i-force_local);
if (r 0)
return r;
+if (version == DKR_PULL_V2) {
+char **k = NULL;
+STRV_FOREACH(k, i-ancestry) {
+_cleanup_free_ char *d = strjoin(i-image_root,
/.dkr-, *k, NULL);
+r = btrfs_subvol_remove(d, false);
+if (r 0)
+ return r;
+}
+
+r = rmdir(i-image_root);
+if (r 0)
+return r;
+}
+
return 0;
}
@@ -516,6 +559,68 @@ static void dkr_pull_job_on_progress(PullJob *j) {
DKR_DOWNLOADING);
}
+static void dkr_pull_job_on_finished_v2(PullJob *j);
+
+static int dkr_pull_pull_layer_v2(DkrPull *i) {
+_cleanup_free_ char *path = NULL;
+const char *url, *layer = NULL;
+int r;
+
+assert(i);
+assert(!i-layer_job);
+assert(!i-temp_path);
+assert(!i-final_path);
+
+for (;;) {
+layer = dkr_pull_current_layer(i);
+if (!layer)
+return 0; /* no more layers */
+
+path = strjoin(i-image_root, /.dkr-, layer, NULL);
+
Re: [systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts
Hey Lennart, Lennart Poettering [2015-05-19 17:23 +0200]: Yes, we need to also record those which were just mounted or changed, in case systemd rereads /proc/self/mountinfo at a time where two mounts where created at once from the same device. OK, as I suspected. I now committed a change to implement that, can you check if this fixes the issue for you? It does, and it looks much more straightforward now. Many thanks for your patience, this was a hairy thing to untangle.. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reduce unit-loading time
Hey cee1, cee1 [2015-05-18 23:52 +0800]: At the first glance, I find ureadahead has some difference compared with the readahead once in systemd, IIRC: Yes, for sure. systemd's was improved quite a bit. ureadahead is mostly unmaintained, but it works well enough so we didn't bother to put work into it until someone actually complains :-) 1. ureadahead.service is in default.target, which means ureadahead starts later than systemd's? That mostly means that it's not started with e. g. emergency or rescue. It still starts early (DefaultDependencies=false). 2. The original systemd readahead has collect and replay two services, and these are done in ureadahead.service? Yes. 3. IIRC, The original systemd readahead uses madvise(); ureadahead uses readahead() 4. The original systemd readahead uses fanotify() to get the list of accessed files; ureadahead use fsnotify I haven't verified these, but this sounds correct. ureadahead is really old, presumably the newer features like fanotify weren't available back then. 5. ureadahead has different readahead strategies for ssd and hhd: Right. These were created by some rather wide-scale measurements back then. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tuesday 2015-05-19 18:38, Tom Gundersen wrote:
# networkctl status --no-pager eth0
??● 3: eth0
Link File: n/a
Network File: n/a
Type: ether
State: off (unmanaged)
Path: pci-:01:00.0
Driver: r8169 [...]
# cat /etc/systemd/network/01-mgmt.link
[Match]
Path=pci-:01:00.0
Type=ether
Type must be the same as what is returned in DEVTYPE=, which I guess
is unset for this device. So drop this and it should work.
I see where the confusion stems from though, as we try to be helpful
and use a heuristic to print a Type in networkctl even when the kernel
does not expose a type. [...]
What precisely is the heuristic?[...]
There are two 'types', the ARP hardware identifier (link type as
exposed over rtnl) and the DEVTYPE (as exposed by libudev). The
matching logic only uses DEVTYPE.
Unlike hwdevtype, arphrd is at least set _all the time_.
The output of networkctl (and the udev naming to a more limited degree) uses
the ARP hardware identifier and then falls back to DEVTYPE in the case of
ethernet devices to distinguish wlan and wwan interfaces from other kinds of
ethernet interfaces.
In an ideal world, we would only use DEVTYPE and the kernel would
assign this reasonably to all devices. In the meantime we could do
some combination of DEVTYPE and ARPHRD, but the danger here is that we
will lock ourselves into some heuristic and make it impossible to
improve the kernel DEVTYPE's in the future as it would change the
behavior of current setups, which is why I have preferred to not
support any matching when DEVTYPE is not set. I'm very open to change
this if anyone has a convincing scheme in mind though.
So, perhaps just making networkd support both DevType={match on DEVTYPE string}
and LinkType={ether,loopback,other ARPHRD_* constants} be the interim solution
for that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, May 19, 2015 at 6:57 PM, Jan Engelhardt jeng...@inai.de wrote:
On Tuesday 2015-05-19 18:38, Tom Gundersen wrote:
# networkctl status --no-pager eth0
??● 3: eth0
Link File: n/a
Network File: n/a
Type: ether
State: off (unmanaged)
Path: pci-:01:00.0
Driver: r8169 [...]
# cat /etc/systemd/network/01-mgmt.link
[Match]
Path=pci-:01:00.0
Type=ether
Type must be the same as what is returned in DEVTYPE=, which I guess
is unset for this device. So drop this and it should work.
I see where the confusion stems from though, as we try to be helpful
and use a heuristic to print a Type in networkctl even when the kernel
does not expose a type. [...]
What precisely is the heuristic?[...]
There are two 'types', the ARP hardware identifier (link type as
exposed over rtnl) and the DEVTYPE (as exposed by libudev). The
matching logic only uses DEVTYPE.
Unlike hwdevtype, arphrd is at least set _all the time_.
True, but not always to something useful (which is why we special case
ARPHRD_ETHER and DEVTYPE==wlan|wwan).
The output of networkctl (and the udev naming to a more limited degree) uses
the ARP hardware identifier and then falls back to DEVTYPE in the case of
ethernet devices to distinguish wlan and wwan interfaces from other kinds of
ethernet interfaces.
In an ideal world, we would only use DEVTYPE and the kernel would
assign this reasonably to all devices. In the meantime we could do
some combination of DEVTYPE and ARPHRD, but the danger here is that we
will lock ourselves into some heuristic and make it impossible to
improve the kernel DEVTYPE's in the future as it would change the
behavior of current setups, which is why I have preferred to not
support any matching when DEVTYPE is not set. I'm very open to change
this if anyone has a convincing scheme in mind though.
So, perhaps just making networkd support both DevType={match on DEVTYPE
string}
and LinkType={ether,loopback,other ARPHRD_* constants} be the interim solution
for that.
I'd rather we just decide on some scheme once and for all. Interim
solutions have a way of becoming permanent...
-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tuesday 2015-05-19 19:03, Tom Gundersen wrote: Unlike hwdevtype, arphrd is at least set _all the time_. True, but not always to something useful (which is why we special case ARPHRD_ETHER and DEVTYPE==wlan|wwan). How so? If ethernet frames is what the OS has to send to the device to make me be able to use that network, then FWIW, it's Ethernet alright. Most people's networks, too, are Ethernet, even though the router might be doing some PPP over ADSL (and deep down, I hear they threw in ATM _as well_). Having link/ppp or link/atm be shown for WWAN seems even less useful than link/ether. :p ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd-218 seems to ignore .link files
On Tue, Apr 21, 2015 at 6:26 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 21.04.15 14:47, Tom Gundersen (t...@jklm.no) wrote: I'm having a similar problem while running systemd version-219. Did you work out what was wrong? My link file is ignored even when I symlink /etc/systemd/network/99-default.link to /dev/null. I don't see anything interesting in 'journalctl'. # udevadm info /sys/class/net/eth0 P: /devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: DEVPATH=/devices/pci:00/:00:04.0/:01:00.0/net/eth0 E: ID_BUS=pci E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Contror E: ID_MODEL_ID=0x8168 E: ID_NET_DRIVER=r8169 E: ID_NET_NAME_MAC=enx000db936008c E: ID_NET_NAME_PATH=enp1s0 E: ID_OUI_FROM_DATABASE=PC Engines GmbH E: ID_PATH=pci-:01:00.0 E: ID_PATH_TAG=pci-_01_00_0 E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Realtek Semiconductor Co., Ltd. E: ID_VENDOR_ID=0x10ec E: IFINDEX=3 E: INTERFACE=eth0 E: SUBSYSTEM=net E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0 E: TAGS=:systemd: E: USEC_INITIALIZED=53326 # networkctl status --no-pager eth0 ��● 3: eth0 Link File: n/a Network File: n/a Type: ether State: off (unmanaged) Path: pci-:01:00.0 Driver: r8169 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller HW Address: 00:0d:b9:36:00:8c (PC Engines GmbH) MTU: 1500 # cat /etc/systemd/network/01-mgmt.link [Match] Path=pci-:01:00.0 Type=ether Type must be the same as what is returned in DEVTYPE=, which I guess is unset for this device. So drop this and it should work. I see where the confusion stems from though, as we try to be helpful and use a heuristic to print a Type in networkctl even when the kernel does not expose a type. We probably should not do that, or allow the same to be used in the .link matching logic (the heuristic is unlikely to be perfect, so I hesitate a bit with the latter). What precisely is the heuristic? To assume that things are ethernet if not otherwise specified? Honestly, I think that's good enough, and probably widely accepted. If this goes wrong I am pretty sure that's something to fix in the driver, by simply exposing the type then... There are two 'types', the ARP hardware identifier (link type as exposed over rtnl) and the DEVTYPE (as exposed by libudev). The matching logic only uses DEVTYPE. The output of networkctl (and the udev naming to a more limited degree) uses the ARP hardware identifier and then falls back to DEVTYPE in the case of ethernet devices to distinguish wlan and wwan interfaces from other kinds of ethernet interfaces. In an ideal world, we would only use DEVTYPE and the kernel would assign this reasonably to all devices. In the meantime we could do some combination of DEVTYPE and ARPHRD, but the danger here is that we will lock ourselves into some heuristic and make it impossible to improve the kernel DEVTYPE's in the future as it would change the behavior of current setups, which is why I have preferred to not support any matching when DEVTYPE is not set. I'm very open to change this if anyone has a convincing scheme in mind though. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cleaning up transient scopes
On Thu, 05.03.15 10:12, Alexander Larsson (al...@redhat.com) wrote: See, even when the sleep command died the scope still exists, and is even ACTIVE. This appears to work fine here on git. There were some fixes to systemd-run made, but it would be cool if you could verify that this works for you. Also, while we're on the topic of scopes. Is there any way to hang some random metadata off a unit during creation, that can be read back? For xdg-app I'd like to put information like the app id, the exact version, the security level, etc into the scope. Then anyone talking to the app could go: getpeercred = cgroup = scope = unfakable (by the app) data about the application. Well, there are cgroup xattrs, but they are not accessible (neiher for read nor write) to unprivileged processes. You can embedd X- fields in unit files and even [X-Sections] in it, to add whatever you like to unit files. These fields will be ignored, and are supposed to be used for extending files with arbitrary fields of your choice. There's a TODO list item to then expose these fields on the bus for each unit, but that's not implemented right now, which means you need to read the unit files manually, and parse them again... So, nope, I have no nice answer for you... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting UseDomains=yes by default DHCP
On Tue, 19.05.15 02:37, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, May 18, 2015 at 07:33:43PM +0200, Lennart Poettering wrote: On Mon, 18.05.15 12:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I now agree with what Lennart proposed too. This is partially implemented now, and with UseDomains=yes, option 15 is used to to set 'search' field. I think we should go a step further, and set UseDomains=yes by default, to have 'search' populated in /etc/resolv.conf. I think the security reservations are overstated: iiuc, the concern was that multi-level domain names (i.e. those with at least one dot) could be spoofed by controlling the search suffix. But for names with at least two levels glibc only uses the search list as a fallback. Well, sure, being able to influence things at the beginning of the search logic is more problematic than influencing things at the end of the search logic, but i still think it's problematic, since it still allows you to insert home.foobar.com into a domain foobar.com that doesn't have home.foobar.com itself but only www.bar.com... Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure, but it I still believe we should default to the safer options, and allow the others. Altering the search paths is inherently something that makes no sense on public networks, it only makes sense if you know your network well, and trust it to some level. Hence opt-in sounds like the better option to me. Ok, this makes a lot of sense... but currently this policy is not very consistent. UseDNS defaults to true, which gives control of *all* names to the dhcp server, not just over the prefix. When we have DNSSEC by default, this will be different though, so that's fine I guess. OTOH, I really don't see why UseHostname default to true. Why trust the server in this regard? Well, we use it to initialize the transient hostname managed by hostnamed with. And the transient hostname is irrelevant if there's a static one defined, since the static hostname overrides the transient one. or in other words: usehostname has only very weak effects: it propagates to the kernel hostname only if you have no manual configuration... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting UseDomains=yes by default DHCP
It seems this thread was already resolved, just wanted to add one comment: On Mon, May 18, 2015 at 2:26 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: So to mount a successful spoof, the attacker needs to a) control the dhcp server domain option to return a domain under attacker control Notice that this is entirely trivial, as the attacker does not need to control _the_ DHCP server, all they have to do is to provide a competing DHCP server on the local link and hope they get picked over the real one. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
В Tue, 19 May 2015 14:07:21 +0200 Lennart Poettering lenn...@poettering.net пишет: On Tue, 19.05.15 14:26, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Tue, May 19, 2015 at 2:15 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: As for Evert's original problem, I think it's that RESTART is propagated to all RequiredBy units unconditionally - even if those are currently stopped! This affects both Requires= and Requisite= in exactly the same way. Exactly. At least I do not see anything obvious in code that would check whether dependent units are running or not. And try-restart is pure forntend option which is not propagated to systemd manager itself. Hmm? We do have JOB_TRY_RESTART while putting together the transaction... What do you mean? I was referring to this comment. May be I misunderstood it. But I do not see TRY_RESTART where dependent units are processed either. /* JOB_TRY_RESTART can never appear in a transaction, because * it always collapses into JOB_RESTART or JOB_NOP before entering. * Thus we never need to merge it with anything. */ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to set primary slave in active-backup mode (bonding)
On Thu, Apr 9, 2015 at 4:29 PM, Mikhail Morfikov mmorfi...@gmail.com wrote: I usually have two network interfaces on my laptops (one eth and one wlan), and when I was using sysvinit I also was configuring the bond interface via the /etc/network/interfaces file so the two interfaces could work in the active-backup mode. But now, they work in balance-rr mode which is set via the .netdev file. The problem with this mode is that when you have, let's say wifi 30mbit/s and wired 100mbit/s, you can get 60mbit/s max, and that's why I wanted to use the active-backup mode which switches from wire to wifi and vice versa depending on whether the ethernet cable is plugged in. Generally speaking, I have to set some additional parameters so this could work well, and that would be: We don't yet fully support all the bonding options. bond-primary eth1 This is not currently supported, I suppose we should add the possibility of marking a slave as 'primary' to the .network file (rather than listing the slave in the .netdev file). bond-primary-reselect always This is PrimaryReselectPolicy=always in the .netdev file. bond-slaves eth1 wlan0 This is achieved by setting Bond= in the .network files applied to eth1 and wlan0. bond-fail-over-mac none This is FailOverMACPolicy=none in the .netdev file, which is also the default, so is redundant. I'm not sure if all of them are necessary, and the question is how to pass these parameters in systemd? I'm asking because in the systemd.netdev manual, in the bond section, these options weren't specified. I hope the above helps, but I suspect you really need the feature to specify the primary slave for this to work as you intended. Happy to take a patch! Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 2015-05-19 at 14:06 +0200, Lennart Poettering wrote: On Tue, 19.05.15 14:15, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: As for Evert's original problem, I think it's that RESTART is propagated to all RequiredBy units unconditionally - even if those are currently stopped! This affects both Requires= and Requisite= in exactly the same Hmm, so basically you are saying that currently RESTART is propagated as RESTART to all depending units, but you suggest that it should be propagated as TRY_RESTART? Did I get this right? Yes, I think that should fix it. I feel that a TRY_RESTART style true restart would be a more natural base operation than the current either start or restart one, with the START_OR_RESTART for systemctl restart semantics collapsing to either START or RESTART. With that terminology, the logic would simply be that RESTART is propagated, START is not. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] udev: Allow detection of udevadm settle timeout
On Sat, May 2, 2015 at 12:21 PM, Nir Soffer nir...@gmail.com wrote: On Tue, Apr 21, 2015 at 12:41 AM, Tom Gundersen t...@jklm.no wrote: On Mon, Apr 13, 2015 at 3:04 PM, Nir Soffer nir...@gmail.com wrote: On Sat, Apr 11, 2015 at 6:58 PM, David Herrmann dh.herrm...@gmail.com wrote: A program running this tool can detect a timeout (expected) or an error (unexpected), and can change the program flow based on this result. Without this, the only way to detect a timeout is to implement the timeout in the program calling udevadm. I cannot really see a use-case here. I mean, yeah, the commit-message says it warns about timeouts but fails loudly on real errors. But again, what's the use-case? Why is a timeout not a real error? Why do you need to handle it differently? Timeout means that the value I chose may be too small, or the machine is overloaded. The administrator may need to configure the system differently. Other errors are not expected, and typically unexpected errors in an underlying tool means getting the developer of the underlying tool involved. Anyway, if it's only about diagnostics this patch seems fine to me. Yes, it is mainly about diagnostics, and making it easier to debug and support. Wouldn't a better solution be to improve the udevadm logging? If we change the exit codes this is basically ABI. Do we really want to make such promises only for diagnostics? Improving logging is orthogonal, as it does allow the program to change the flow based the exit code. Adding a timeout exit code may break code using undocumented behavior, since the return code is not documented. I don't really have a strong argument against this, except that we should not add ABI without a strong usecase. So you mentioned that you want this for diagnostics, to which my suggestion was to improve the logging in udevadm itself. But are there other usecases? What is the case where the external tool actually needs to change its behavior? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem when m-finish_timestamp is set before running manager_loop
On Tue, 19.05.15 14:45, cee1 (fykc...@gmail.com) wrote: Hi all, I found a Startup finished in 155ms (userspace) = 155ms( which is of course incorrect) log on the board at hand, which is caused by something likes: Job cache.mount/stop finished, result=canceled Following the code, I find m-finish_timestamp is set in manager_check_finished(), which is in turn invoked in job_finish_and_invalidate() -- All these happens before the manager_loop running. Hmm, can you provide a backtrace of the call chain when this happens, please? I have now commited a patch to git, that might fix the issue, but I am not entirely sure, given the little information I have: http://cgit.freedesktop.org/systemd/systemd/commit/?id=aad1976ffa25fa6901f72c300b5980ada0ef44c5 Would be cool if you could check if this patch already fixes the issue for you. Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 19.05.15 20:13, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Tue, 19 May 2015 14:07:21 +0200 Lennart Poettering lenn...@poettering.net пишет: On Tue, 19.05.15 14:26, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Tue, May 19, 2015 at 2:15 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: As for Evert's original problem, I think it's that RESTART is propagated to all RequiredBy units unconditionally - even if those are currently stopped! This affects both Requires= and Requisite= in exactly the same way. Exactly. At least I do not see anything obvious in code that would check whether dependent units are running or not. And try-restart is pure forntend option which is not propagated to systemd manager itself. Hmm? We do have JOB_TRY_RESTART while putting together the transaction... What do you mean? I was referring to this comment. May be I misunderstood it. But I do not see TRY_RESTART where dependent units are processed either. /* JOB_TRY_RESTART can never appear in a transaction, because * it always collapses into JOB_RESTART or JOB_NOP before entering. * Thus we never need to merge it with anything. */ True. The code I commited now uses job_type_collapse to fix the job type up as necessary. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit reported as failed despite exit code from SuccessExitStatus
On Thu, 16.04.15 14:21, Nikolaus Rath (nikol...@rath.org) wrote: On Apr 16 2015, Lennart Poettering lenn...@poettering.net wrote: On Wed, 15.04.15 22:45, Nikolaus Rath (nikol...@rath.org) wrote: I don't quite understand this: $ systemctl --user status autocommit-org.service ● autocommit-org.service - Auto-commits changes to orgmode files. Loaded: loaded (/home/nikratio/.config/systemd/user/autocommit-org.service; static) Active: inactive (dead) since Wed 2015-04-15 22:42:13 PDT; 51s ago Main PID: 2820 (code=exited, status=1/FAILURE) Apr 15 22:42:13 vostro systemd[2453]: Starting Auto-commits changes to orgmode fil. Apr 15 22:42:13 vostro hg[2820]: nothing changed Apr 15 22:42:13 vostro systemd[2453]: Started Auto-commits changes to orgmode files.. Hint: Some lines were ellipsized, use -l to show in full. $ cat /home/nikratio/.config/systemd/user/autocommit-org.service [Unit] Description=Auto-commits changes to orgmode files. [Service] Type = oneshot WorkingDirectory = %h/lib/Dropbox/org ExecStart = /usr/bin/hg commit -m Autocommit. SuccessExitStatus = 1 $ systemctl --version systemd 215 +PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR Why is the unit reported as failed? Shouldn't status=1 be interpreted as success? Sounds like a bug, possibly an issue with type=oneshot together with SuccessExitStatus. Actually it seems to be related to the user of a timer unit to start the service. When I just start it manually, it works fine. But if I define a timer: $ cat autocommit-org.timer [Unit] Description = bla [Timer] OnBootSec = 10 OnUnitActiveSec = 30 Unit = autocommit-org.service Then the problem occurs. Any chance you can reduce this to a minimal example I can reproduce here locally? i.e. no hg involved, please, but instead /bin/false or so? and no unnecessary settings? Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reduce unit-loading time
On Mon, May 18, 2015 at 7:24 AM, cee1 fykc...@gmail.com wrote: 2015-05-17 17:45 GMT+08:00 Martin Pitt martin.p...@ubuntu.com: Hello cee, cee1 [2015-05-16 0:46 +0800]: Thanks for the suggestion, it was other processes running in parallel which presumably consuming lots of IO, after sending SIGSTOP at the first (and SIGCONT later), the unit loading time is decreased to ~100ms. You probably want to use some readahead solution. We found that it makes a significant improvement on ARM boards with slow MMC cards. You could also posix_fadvise(fileno(f), 0, 0, POSIX_FADV_SEQUENTIAL); in the bits that load the unit file..the kernel is free to ignore that advice however. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reduce unit-loading time
On Tue, May 19, 2015 at 5:39 PM, Cristian Rodríguez crrodrig...@opensuse.org wrote: On Mon, May 18, 2015 at 7:24 AM, cee1 fykc...@gmail.com wrote: 2015-05-17 17:45 GMT+08:00 Martin Pitt martin.p...@ubuntu.com: Hello cee, cee1 [2015-05-16 0:46 +0800]: Thanks for the suggestion, it was other processes running in parallel which presumably consuming lots of IO, after sending SIGSTOP at the first (and SIGCONT later), the unit loading time is decreased to ~100ms. You probably want to use some readahead solution. We found that it makes a significant improvement on ARM boards with slow MMC cards. You could also posix_fadvise(fileno(f), 0, 0, POSIX_FADV_SEQUENTIAL); in the bits that load the unit file..the kernel is free to ignore that advice however. This however.. won't be of any help, as the default readhead window is 128kb.. which is way bigger than any unit file. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd and systemd-nspawn: missing host-side network
On Mon, Apr 27, 2015 at 6:50 AM, Kai Krakow hurikha...@gmail.com wrote: I've created a container with systemd-nspawn, machinectl enabled it, then added machines.target to my default target (systemctl enable machines.target) so that containers will be autostarted on boot. That works so far. But I discovered that systemd-networkd no longer configures my normal ethernet device during boot (it's configured as dhcp client). It just configures the ve-* device and that's it. After I manually restart networkd, all links are configured. Steps to reproduce: $ cat /etc/systemd/network/80-dhcp.network [Match] Name=en* [Network] DHCP=yes [DHCP] UseDomains=true $ cat /etc/systemd/network/90-veth.network # This was added because otherwise after reboot, ve- is stuck in # mode configuring when looking at networkctl, it changes nothing # for the following behaviour, tho... [Match] Name=ve-* [Network] DHCP=no $ machinectl enable test-machine $ systemctl enable machines.target $ systemctl reboot ...[rebooting]... $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback n/a n/a 2 enp4s0 ether n/a n/a 3 sit0 sitn/a n/a 4 ve- ether routableconfigured $ ifconfig # shows only lo and ve- Hm? ifconfig does not show enp4s0? How about ip link? $ systemctl restart systemd-networkd $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp4s0 ether routableconfigured 3 sit0 sitoff unmanaged 4 ve- ether routableconfigured Which version did you observe this in? Is this reproducible with current git HEAD? If so, could you attach $ networkctl status enp4s0 and the output of journalctl -b -u systemd-networkd (preferably after enabling debug logging in networkd by setting Environment=SYSTEMD_LOG_LEVEL=debug in the networkd service file). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd failing sporadically failing to bring up network device
On Tue, Apr 7, 2015 at 5:46 PM, Richard Maw richard@codethink.co.uk wrote: On Sat, Apr 04, 2015 at 12:08:04PM +0100, Sitsofe Wheeler wrote: Hi, I've noticed that networkd occasionally fails to bring up one of two network interfaces on boot (this happens about once every 70 or so boots). The machine in question is a VMware ESXi 5.5 guest with two VMXNET3 network adaptors. When this issue occurs the message rtnl: received address for a nonexistent link (1), ignoring is present in the journal. Does anyone know if this is a known issue in systemd 216 (I'm using Fedora 21)? I've attached a journal log below: There's been a few post-217 changes related to parsing messages in rtnl, one of which was related to accidentally interpreting change notifications as responses under rare circumstances, so there are some known bugs in 216, but I haven't encountered yours before. Re-testing with the latest systemd snapshot would let us know if it's one of the bugs fixed post 217. If it comes to debugging what netlink is doing, one option is to use the nlmon interface, capture it with tcpdump as described in http://seclists.org/tcpdump/2014/q4/32 and then use wireshark to parse the dump. Seems I missed parts of this thread (I cannot find the original email in my archive), so in case I missed something important: could this be reproduced with current git, or is this seemingly resolved now? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] device: Fix overzealous unmounting of tentative device mounts
On Tue, 19.05.15 17:31, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey Lennart, Lennart Poettering [2015-05-19 17:23 +0200]: Yes, we need to also record those which were just mounted or changed, in case systemd rereads /proc/self/mountinfo at a time where two mounts where created at once from the same device. OK, as I suspected. I now committed a change to implement that, can you check if this fixes the issue for you? It does, and it looks much more straightforward now. Perfect! Thanks for tracking this down and keeping it up even when I was too dumb to understand what the issue was! Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-218 - Requisite implies TriggeredByRestartOf
On Tue, 19.05.15 14:15, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Tue, 2015-05-19 at 01:26 +0200, Lennart Poettering wrote: On Tue, 19.05.15 00:55, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 14.05.15 21:23, Evert (evert.gen...@planet.nl) wrote: According to the systemd documentation, Requisite disallows starting a unit unless the specified unit has been started. This seems to work fine, however, if the specified unit has been restarted, this unit will be started too! This is not what should happen and it doesn't happen with a stop and start of the specified unit, so clearly, restart behaves different than stop followed by start. systemctl stop by the user. Now, as a special shortcut we currently map Requisite= and Required= to a reverse dependency of RequiredBy=, which is problematichere, since we'll hence make no distinction between the two when processing systemctl stop. I figure we need to split up the reverse dep here, and introduce a seperate RequisiteBy= dependency so that we can avoid this problem... Fixed in git. Please verify. I think you're talking about something quite different than the problem described by Evert. The bug report was about a currently stopped depending unit being started by actions on a depended-on unit, which is equally wrong for either Requires= or Requisite=, and is no reason for adding any new distinction between them! And the problem was also about systemctl restart, while systemctl stop worked as expected. Did your change disable propagation of STOP from depended-on unit to the one using Requisite=? If so, I think that's wrong and should be reverted - the documentation says Requisite is similar to Requires=, and gives no reason to expect that propagation in the direction from the depended-on unit to the depending-on unit would be affected. I have now reverted this with a1036fd1b0c195a63c983db67024d4b725f0166c. Please check. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udev causes slow boot and high load
Am 19.05.2015 um 12:37 schrieb Lennart Poettering: On Tue, 19.05.15 12:02, Marco Steinacher (mailingli...@websource.ch) wrote: Hi, After upgrading my system to Debian jessie and switching to systemd I have the following problem: 1. During boot there is the message [**] A start job is running for udev Wait for Complete De...on (11s / 3min) after systemd-fsck[452]: /dev/sda5: clean and it takes about 2 minutes until the boot process continues. systemd-analyze blame shows: 2min 2.945s systemd-udev-settle.service systemd-udev-settle.service just waits for devices to be probed. It will wait for the kernel drivers to initialize and the udev rules to be pliugged in. In fact, there's really no need to have this in the boot process at all, unless you are using some broken software that assumes that there's a point in time where all hardware has been plugged in, but such a point in time does not actually exist, and hasn't existed in a long time (simply because USB and other busses can take any time they want before initialization is complete and the devices have shown up). 2. dmesg also shows: [ 254.305831] INFO: task systemd-udevd:296 blocked for more than 120 seconds. [ 254.305962] Not tainted 3.16.0-4-686-pae #1 [ 254.306069] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 254.306165] systemd-udevd D 0 296234 0x0004 and similar messages for the tasks systemd-udevd:308 and systemd-udevd:307. The messages repeat a couple of times (see full log below). There you go: your kernel is hung, some driver or your xen irq handling is borked and hangs during initialization. This is a kernel problem, please report this to the kernel bugzilla. Thank you for the swift reply and for clarifying the situation. I understand now that this is a kernel issue and not a problem with systemd. I'll try to track down the kernel issue now. Thanks, Marco -- OpenPGP Key ID: 0x62937F7F ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] unaligned write in dhcp_identifier_set_iaid
On Tue, Feb 24, 2015 at 7:22 PM, Michael Olbrich
m.olbr...@pengutronix.de wrote:
there is an unaligned write in dhcp_identifier_set_iaid() and I'm not quite
sure what the correct fix is:
int dhcp_identifier_set_iaid(int ifindex, uint8_t *mac, size_t mac_len,
uint32_t *_id) {
[...]
*_id = (id 0x) ^ (id 32);
[...]
}
And this is called with:
r = dhcp_identifier_set_iaid(client-index, client-mac_addr,
client-mac_addr_len, client-client_id.ns.iaid);
And iaid is not unaligned because of the packing in struct sd_dhcp_client.
I'm not sure why '_packed_' is used there. It this just to save some space,
or is there a reason for this?
Thanks for the report. This seems to have fallen through the cracks.
Should be fixed in git, please verify.
Sorry for the delay.
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 0/5] systemd-importd - support for pulling from V2 Dkr registries
On Tue, 19.05.15 16:29, Pavel Odvody (podv...@redhat.com) wrote: Looks good! Applied all five! Good work! Hey, this is the new patch set with incorporated changes from the review: - stricter digest validation - got rid of the additional http headers/#defines - all data now derived from --dkr-index-url value - json_variant renamed to JsonVariant - JsonVariantType enum is now a typedef - enum PullStrategy now properly typedef'd and named DkrPullVersion - structure of the JSON document is now thoroughly checked in the tests - minor memory allocation/initialization changes - commit messages were made more specific (added clarification for the DOM-like parser) Pavel Odvody (5): shared/import-util: Tag renamed to reference shared/json: Added DOM-like JSON parser test/test-json: Tests for the tokenizer bugfix and the DOM parser import/pull: Tag replaced with reference import/pull-dkr: V2 image specification and manifest support src/import/pull-dkr.c| 542 ++- src/import/pull-dkr.h| 3 +- src/import/pull.c| 28 ++- src/shared/import-util.c | 21 ++ src/shared/import-util.h | 2 + src/shared/json.c| 432 - src/shared/json.h| 37 src/test/test-json.c | 97 + 8 files changed, 1087 insertions(+), 75 deletions(-) -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
