Re: [systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured
On Thu, 2015-02-12 at 18:51 +0100, Lennart Poettering wrote: On Thu, 12.02.15 17:48, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: Ok, I'll try with latest Git first, and if it still fails I'll try reverting the patch Lennart suggested. git already has that patch reverted now. Lennart Ah :) Well using the upstream Git works perfectly :) Thanks for helping resolve this issue. Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: Fix by-path of mmc RPMB partitions and don't blkid them
Lennart Poettering [2015-02-12 18:50 +0100]:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=090d25fe224c0
Looks simple enough. Though I wonder if [0-9] is the right match,
shouldn't it also cover multiple numbers there?
Hm, yes. fnmatch() doesn't support a regexp-like one or more digits;
it's less precise, but as the kernel doesn't generate arbitrary device
names but at most things like mmcblk0p1, extending the glob to
mmcblk[0-9]*rpmb is actually safe.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 23ab7d9cf443653c1a8c54a3ab154fc808a5a0e8 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 11 Feb 2015 15:26:52 +0100
Subject: [PATCH] rules: Fix by-path of mmc RPMB partitions and don't blkid
them
Linux 3.10+ exposes RPMB (Replay Protected Memory Block) partitions of MMC
devices [1] ; trying to read them with blkid or other unspecific means will
cause kernel buffer I/O errors and timeouts. So don't run blkid on these.
Also ensure that /dev/disk/by-path creates proper symlinks and exposes the
-rpmb partition separately, instead of letting the normal partition symlink
point to the rpbm device (this is a race condition).
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=090d25fe224c0
https://launchpad.net/bugs/1333140
---
rules/60-persistent-storage.rules | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/rules/60-persistent-storage.rules b/rules/60-persistent-storage.rules
index 475b151..08ed1cc 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -53,7 +53,8 @@ KERNEL==mspblk[0-9]p[0-9], ENV{ID_NAME}==?*, ENV{ID_SERIAL}==?*, SYMLINK+=
# by-path (parent device path)
ENV{DEVTYPE}==disk, DEVPATH!=*/virtual/*, IMPORT{builtin}=path_id
-ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, SYMLINK+=disk/by-path/$env{ID_PATH}
+ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, KERNEL==mmcblk[0-9]*rpmb, SYMLINK+=disk/by-path/$env{ID_PATH}-rpmb
+ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, KERNEL!=mmcblk[0-9]*rpmb, SYMLINK+=disk/by-path/$env{ID_PATH}
ENV{DEVTYPE}==partition, ENV{ID_PATH}==?*, SYMLINK+=disk/by-path/$env{ID_PATH}-part%n
# skip unpartitioned removable media devices from drivers which do not send change events
@@ -66,6 +67,9 @@ KERNEL==sr*, ENV{DISK_EJECT_REQUEST}!=?*, ENV{ID_CDROM_MEDIA_TRACK_COUNT_DAT
KERNEL==sr*, ENV{DISK_EJECT_REQUEST}!=?*, ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}==?*, ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}==, \
IMPORT{builtin}=blkid --noraid
+# don't try to read Replay Protected Memory Block partitions
+KERNEL==mmcblk[0-9]*rpmb, GOTO=persistent_storage_end
+
# probe filesystem metadata of disks
KERNEL!=sr*, IMPORT{builtin}=blkid
--
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] avahi disconnects from bus with kdbus
Hi On Wed, Feb 11, 2015 at 11:17 AM, Daniel Buch boogiewasth...@gmail.com wrote: Nice, everything works flawlessly with current git now. Good job! Thanks for testing! No idea which commit exactly fixed it, so if you see it again, please let us know. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured
On Thu, Feb 12, 2015 at 7:28 PM, Keller, Jacob E jacob.e.kel...@intel.com wrote: On Thu, 2015-02-12 at 18:51 +0100, Lennart Poettering wrote: On Thu, 12.02.15 17:48, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: Ok, I'll try with latest Git first, and if it still fails I'll try reverting the patch Lennart suggested. git already has that patch reverted now. Lennart Ah :) Well using the upstream Git works perfectly :) Thanks for helping resolve this issue. Thanks for testing! Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured
On Thu, 12.02.15 17:48, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: Ok, I'll try with latest Git first, and if it still fails I'll try reverting the patch Lennart suggested. git already has that patch reverted now. 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] Whitespace in /etc/crypttab
On Thu, 12.02.15 13:12, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Feb 12, 2015 at 09:49:34AM +, John Lane wrote: I see http://cgit.freedesktop.org/systemd/systemd/commit/?id=84cc2abf3472b[1] that PARTLABEL= is supported in /etc/cryptab although it isn't documented[2] http://www.freedesktop.org/software/systemd/man/crypttab.html. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=84cc2abf3472b [2] http://www.freedesktop.org/software/systemd/man/crypttab.html It would be great to have it documented. Placing an entry in /etc/crypttab like cryptvol PARTLABEL=A\040B none results in device units like dev-disk-by\x2dpartlabel-A\x5cx5c040B I also tried A\x20B I get dev-disk-by\x2dpartlabel-A\x5cx5cx20B GPT supports whitespace in partition labels. Is it possible to use whitespace in PARTLABEL in /etc/crypttab? Seems like a call to cunescape() is missing somewhere. Patch welcome ;) Actually I'd prefer if we could rework code like this to use unquote_many_words(), which is much nicer anyway, and should give us this for free... 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] Changing how localed writes keymap for xorg
Hi Colin On Thu, Feb 12, 2015 at 1:27 AM, Colin Guthrie gm...@colin.guthr.ie wrote: at which point we need to ask the question: what makes keyboards so special? and the answer seems to be that your DE doesn't support hotplugged keyboards, per-user keyboard settings, etc. So it feels to me, and correct me if I'm wrong here, that you want to reshape the default handling so you don't have to fix it in your DE (I don't actually know which one you're using, sorry). Yeah, I kinda left that out deliberately as the use case is a bit special. This is basically a pre-DE mini-wizard that kicks in in live mode to ask the user what their locale is, setup the language, timezone and keyboard and then boots into the DE of choice, whether it be GNOME, or KDE or something else (those two being the main ones). In the case of GNOME, setting the keymap and such is respected (assuming there was no 00-keyboard.conf present when X was initialised), but language settings (LANG, LC_* etc.) are not, and thus we are forced to do a X restart there. For KDE, everything works fine, LANG, keymap etc is all fine, and we don't need to restart X for everything to kick in correctly which makes for a slightly nicer user experience. In our case we can simply arrange for there to be no 00-keyboard.conf present at init, so it's not the biggest deal in the world. The keymaps are set manually *and* any new keyboards that happen to be plugged in will be fine too (settings ultimately coming via udev properties in this case, but quite possibly appropriate daemons in the DEs will get involved at this stage now anyway). Essentially I was wanting the DE config stuff to be in addition to the keyboard being correct in the first place as I don't want to have to go around and deal with the same problem on several of the lighter-weight DEs which, frankly, are rubbish! Anyway, that's the background. Longer term, this scheme is pretty nasty anyway. When we move things over to the systemd user session it'll be harder to pause the X session init and we will probably (have to) totally reassess all this. It's pretty nasty to work with as it is, so I personally won't be sorry to rip it all out and just do something a lot nicer. It would also be good to allow for DE-provided first boot type wizards to run should they provide their own, and only use the generic one when the DE is too rubbish to do this :) To summarize: Your wizard uses udev-properties to set keymap-settings, because otherwise you'd have to restart X11 to reload its configuration, right? I agree with Peter here: The udev-feature shouldn't really be used. Xorg only supports static configuration, if you want dynamic configuration, use the Xinput/Xrandr properties provided by the drivers. This is how dynamic configurations are done. Regarding input configuration for non-X11: In systemd-console I use the localed-API for locale configuration. I think we want something similar for input-devices and monitor-configuration. Those daemons could be easily run on the system bus *AND* on the user-bus, to get system-defaults and user-overrides. But I haven't really thought it through, it's just an idea. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] preset-transient
On 11 February 2015 at 20:49, Lennart Poettering lenn...@poettering.net wrote: On Fri, 06.02.15 18:29, Didier Roche (didro...@ubuntu.com) wrote: Le 05/02/2015 17:11, Dimitri John Ledkov a écrit : Some context for this patch. Hey Dimitri, thanks for working on that. I'm just giving a broader context for everyone who followed the past discussion we had in december/january. This is a followup on our discussion and what we discussed on the /usr vs /etc email thread (to give the full context). I would like to support a new preset model, which has the following properties: - distribution shipped defaults are enabled - and are applied to each boot/upgrade - without overriding any user configuration Said differently, the Debian/Ubuntu needs are that distro defaults are migrated. We would prefer an upstream solution for this than the current cache implementation by our install helper tools that Dimitri described below. We should be able to handle defaults per flavors in the ubuntu case (meaning, alternatives are respected, with a priority order based on filename), admins should be able to disable services that are enabled by default on the distro and admins overrides are always respected, even if the distro changed its default policy for a service from disabled to enabled or the contrary. We need for this to work the /dev/null symlink in /etc patch to disable known services that was discussed in the previous thread and agreed on. From the past discussions and during the hackfest, we agreed that presets were the way to go forward, but with slight changes that Dimitri explains below. In many ways it is very similar to existing functionality but not quite possible to achieve all of the above. Thus, I'm introducing a new optional functionality, new unit configuration directory, and new transient-preset configurations. On each boot, if TransientPreset=yes, presets from /usr/lib/systemd/system-preset-transient/*.preset are applied into configuration path /run/systemd/system-preset-transient/. Hum, we told at the sprint that we wanted to be that available for everyone, and not having any conditions. Distros which still desires only the existing behavior would not ship files in *-preset-transient directories. An upgrade tool, sysadmin can repeat that action at appropriate points by also calling: systemctl --runtime preset-all. This command is only for sys admins, on package upgrade/installation/removal (having units file or a new preset file), we would call as a trigger systemctl --daemon-reload, which then, would purge the transient runtime directories and reapply needed changes. If distribution integrates usage of Transient Presets, it gains a few very nice properties. Fresh installations, much upgrades. User/admin modifications are preserved. And there is no additional logic required to maintain separation / diffs between system-defaults and user-modifications. At the moment distributions like Debian (where most things are enabled by default) maintain a complex state in /var/ which tracks which things were distro-enabled before/after the upgrade, as well as whether user/admin has disabled/enabled things before/after the upgrade and try hard to correctly reconcile the correct state for all units. However, with this patch, most of this segregation moves away. We discussed first that this could have gone in /var (this transient layer state is under our control) so that it's not called at every boot, however, /var isn't required at this very early stage to load units from systemd. We would like to not add those in another /etc directory on the broader goal of empty /etc by default. The remaining part, which is not addressed in this patch series, yet, is the ability to override .wants/ symlink from a higher order configuration directory. That is if the following symlinks are present: /etc/systemd/system/foo.service.wants/bar.service - /dev/null /usr/lib/systemd/system/foo.service.wants/bar.service - ../bar.service There is no wants dependency added from foo.service - bar.service. This bit is discussed in details and agreed upon on the mailing list. (Unwants thread has urls to the messages) Regards, Dimitri. Dimitri John Ledkov (1): Add support for transient presets, applied on every boot. man/systemd-system.conf.xml | 1 + src/core/main.c | 30 +++ src/core/system.conf| 1 + src/core/unit.c | 2 +- src/shared/install.c| 59 ++--- src/shared/install.h| 2 +- src/shared/path-lookup.c| 2 ++ 7 files changed, 76 insertions(+), 21 deletions(-) Right now, I think that we shouldn't have a configuration flag for it, this should apply (as stated above) to any setup, and distros can opt in or out just by shipping those transient preset files. It seems to me that this code
Re: [systemd-devel] [PATCH] preset-transient
On 11 February 2015 at 20:51, Lennart Poettering lenn...@poettering.net wrote: On Fri, 06.02.15 20:28, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: Hum, we told at the sprint that we wanted to be that available for everyone, and not having any conditions. Distros which still desires only the existing behavior would not ship files in *-preset-transient directories. Running any presets commands unconditionally, without any preset configuration is harmful. Prime example, if one doesn't ship any .preset (even the one that comes with systemd) shutdown.target gets activated and all that system does on boot is going to shutdown straight away. Hmm, not following? Can you elaborate? With this patch, (as is, without taking all of the above mentioned feedback) AND transient-presets enabled via config option AND no .preset files shipped at all for neither of preset types AND no machine-id one will not be able to boot =) i guess, this only points stronger to distro should be configured sanely and this is not a toggle to play with. (It seems like, after enable * a few things are enabled - e.g. debug-shell.service console-shell.service, the boot reaches multiuser target and one sees maintainance prompt, after which the system goes to poweroff. I'm not quite sure how to debug this better, but my suspicion is that console-shell is stopped, which has ExecStopPost=-/usr/bin/systemctl poweroff. Maybe this is simply a bug in some of the default units. Is enable * alone default policy actually supported?) Right now, I think that we shouldn't have a configuration flag for it, this should apply (as stated above) to any setup, and distros can opt in or out just by shipping those transient preset files. Well, I understood, that we should allow both distros and user to opt-into either or both. Plus to successfully use transient-presets, one needs regular presets configured in concert as otherwise things go haywire as you have noted. Why would this be a user choice at all? This appears to be strictly a distro choice to me... Yeah, I don't have a compeling argument here. User may want to extend or tweak the distro-integration via e.g. /etc/systemd/system-presets | transient-system-presets, but indeed I do not see why they would want to use these functionalities if the distro didn't provide any sane integration for any type of presets. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed units and Unit type .busname is not supported on this system
On Thu, Feb 12, 2015 at 10:23 AM, John Lane syst...@jelmail.com wrote: On 06/02/15 17:12, John Lane wrote: Good afternoon. I have some errors in the boot sequence of a newly built system: I see: systemd[1]: Unit type .busname is not supported on this system. then later on: systemd-networkd[278]: Assertion 'bus' failed at src/libsystemd/sd-bus/bus-util.c:105, function bus_event_loop_with_idle(). Aborting. systemd[1]: Unit systemd-networkd.service entered failed state systemd-networkd.service failed. and systemd-logind[565]: Failed to connect to system bus: No such file or directory systemd-logind[565]: Failed to fully start up daemon: No such file or directory Failed to start Login Service. My systemctl status shows a degraded status with 3 failed units being UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-logind.service loaded failed failed Login Service ● systemd-networkd.service loaded failed failed Network Service ● systemd-networkd.socket loaded failed failed networkd rtnetlink socket However, it gets to the login prompt, I can log in and everything works (as far as I can tell). I assume that the failed units are a result of the busname is not supported on this system but I have no clue about what that means and what to do about it. Searches have turned up nothing. System details: Linux tsodium 3.18.5-1-ARCH #1 SMP PREEMPT Fri Jan 30 07:17:14 CET 2015 i686 GNU/Linux systemd 218 +PAM -AUDIT -SELINUX -IMA -APPARMOR -SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN built today from systemd-git 218.944.g30ae637-1 I am using a git checkout because I am using functionality that isn't in 218. Any suggestions appreciated. John ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Just an update on the above. unit type .busname is not supported on this system isn't the cause of the problem that I was seeing (I still don't know why this appears or if it is significant in other ways but it would appear not to be so). Most probably this was caused by the lack of a conditional in systemd-networkd.busname (which was fixed a few days ago). Either way it is not important (as you don't appear to be using kdbus). The failed units were a consequence of me using the ArchLinux systemd-git AUR package as part of a new system build. It's dependency list had omitted dbus and this caused the above breakages to occur do to the sysem not having dbus. Installing dbus fixed it. Problem solved. Thanks for reporting back. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
On Thu, 12.02.15 11:58, Martin Pitt (martin.p...@ubuntu.com) wrote: Lennart Poettering [2015-02-12 11:22 +0100]: To make systemd robust against this, I fixed mount_load_proc_self_mountinfo() to actually do what it intends to do, instead of loading /etc/mtab (which is still util-linux' default for mnt_table_parse_mtab()). Urks, we never want to read /etc/mtab from PID 1, indeed. I am a bit puzzled by mnt_table_parse_mtab() thiugh. The name suggests it parses /etc/mtab files (which have the same format as /proc/self/mounts). But Can we really just arse /proc/self/mountinfo to it, which has a very different format? Yes, it arses it just fine :-) It supports the mtab, the fstab, and the mountinfo format: https://github.com/karelzak/util-linux/blob/master/libmount/src/tab_parse.c#L1047 If you don't specify a file name, it defaults to /etc/mtab; mnt_has_regular_mtab() checks if /etc/mtab is a regular file, and if so, parses it as mtab format; if it's a symlink, then mnt_has_regular_mtab() is false. (See https://github.com/karelzak/util-linux/blob/master/libmount/src/utils.c#L772) If the passed filename (or /etc/mtab default) is a symlink, it falls back to line 1068 ff. where it ignores filename entirely. It first tries to parse /proc/self/mountinfo as MNT_FMT_MOUNTINFO, and if that fails, it falls back to parsing /proc/mounts (in old _PATH_PROC_MOUNTS format, i. e. mtab). So it doesn't matter that much what filename is, as long as it's not NULL or /etc/mtab, but for readability I still suggest using /proc/self/mountinfo, as that's what it will actually end up reading. FTR, I added a log_debug() to it (not contained in the submitted patch) and tested it with regular /etc/mtab, a symlink to /proc/mounts and a symlink to /proc/self/mountinfo, and it comes out just fine. And the stuff from /run is always merged into it, regardless which file is read? 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] Whitespace in /etc/crypttab
On Thu, Feb 12, 2015 at 09:49:34AM +, John Lane wrote: I see http://cgit.freedesktop.org/systemd/systemd/commit/?id=84cc2abf3472b[1] that PARTLABEL= is supported in /etc/cryptab although it isn't documented[2] http://www.freedesktop.org/software/systemd/man/crypttab.html. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=84cc2abf3472b [2] http://www.freedesktop.org/software/systemd/man/crypttab.html It would be great to have it documented. Placing an entry in /etc/crypttab like cryptvol PARTLABEL=A\040B none results in device units like dev-disk-by\x2dpartlabel-A\x5cx5c040B I also tried A\x20B I get dev-disk-by\x2dpartlabel-A\x5cx5cx20B GPT supports whitespace in partition labels. Is it possible to use whitespace in PARTLABEL in /etc/crypttab? Seems like a call to cunescape() is missing somewhere. Patch welcome ;) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On 02/12/2015 04:38 AM, Michael Biebl wrote: 2015-02-11 20:12 GMT+01:00 Lennart Poettering lenn...@poettering.net: So, I have discussed this with Kay, David, Daniel, and co. And we kinda came to the conclusion that we might as well just drop the configurability where runlevel3-5.target point to. If we drop that, we Do you mean runlevel2-5, or is runlevel2 excluded for a reason? Well we have more targets then there are run levels for example emergency and rescue both of which could be seen as run level 1 Run level 2 arguably should have been mapped to basic.target from the start and is causing confusion since it's mapped to the multi-user.target Run level 3 as in the multi-user.target lacks network support ( even thou now it arguably could be added properly with systemd-networkd ), which is what users expect Run level 4 cant be mapped to users custom boot target ( they have to manually link it themselves and since they have to do that they are simply better of using systemctl set-default my-custom-boot.target reboot and then change it back or isolate to it. etc. The fact is if shit hits the fan at bootup systemd really aught to handle that gracefully and drop users down to rescue.target and or emergency.target and if you switch targets later then you should wind up with only the exact services running as you would have booted directly to the target you isolated to. Forcing users having to add a kernel command line ( 1,2,3 etc ) is archaic in the 21 century from my pov but unfortunately our huge timeout that happens at bootup contributes to users having to manually boot to a specific target ( or runlevel ) due to the fact users dont wait for that time out ( by my observation these years if users are used boot completing in 15s having them wait for more then ca 30s tops reaches their patience threshold and they *will* in all cases hard power off the machine and power it on again which beats the purpose of the time out to begin with ) So arguably the entire concept of run levels ( and backward compatibility and support ) should be put to rest upstream and have downstream maintaining that compatibility support if they so much desire since it never applied to systemd and doing so has and is hindering adoption of the systemd concept of targets, causes confusion for users and arguably hinders us evolve to a better native solution to solve the usecases that inspired the existence of run levels to begin with. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add support for transient presets, applied on every boot.
On 11 February 2015 at 20:43, Lennart Poettering lenn...@poettering.net wrote:
On Thu, 05.02.15 16:11, Dimitri John Ledkov (dimitri.j.led...@intel.com)
wrote:
-static int get_config_path(UnitFileScope scope, bool runtime, const char
*root_dir, char **ret) {
+static int get_config_path(UnitFileScope scope, bool runtime, bool preset,
const char *root_dir, char **ret) {
char *p = NULL;
int r;
@@ -71,7 +71,10 @@ static int get_config_path(UnitFileScope scope, bool
runtime, const char *root_d
case UNIT_FILE_SYSTEM:
if (runtime)
-p = path_join(root_dir, /run/systemd/system,
NULL);
+if (preset)
+p = path_join(root_dir,
/run/systemd/system-preset-transient, NULL);
+else
+p = path_join(root_dir,
/run/systemd/system, NULL);
Hmm, shouldn't we just apply this directly to /run/systemd/system?
There's no real need to keep this separate?
I mean if the user shall be able to undo changes made by these presets
with systemctl --runtime disable it would be good not to introduce a
new dir for all of this...
Yes, we can reuse existing dir for this. But was not entirely sure
about that initially when writting this, would simplify a few things
in this patch.
--
Regards,
Dimitri.
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
Lennart Poettering [2015-02-12 11:22 +0100]: To make systemd robust against this, I fixed mount_load_proc_self_mountinfo() to actually do what it intends to do, instead of loading /etc/mtab (which is still util-linux' default for mnt_table_parse_mtab()). Urks, we never want to read /etc/mtab from PID 1, indeed. I am a bit puzzled by mnt_table_parse_mtab() thiugh. The name suggests it parses /etc/mtab files (which have the same format as /proc/self/mounts). But Can we really just arse /proc/self/mountinfo to it, which has a very different format? Yes, it arses it just fine :-) It supports the mtab, the fstab, and the mountinfo format: https://github.com/karelzak/util-linux/blob/master/libmount/src/tab_parse.c#L1047 If you don't specify a file name, it defaults to /etc/mtab; mnt_has_regular_mtab() checks if /etc/mtab is a regular file, and if so, parses it as mtab format; if it's a symlink, then mnt_has_regular_mtab() is false. (See https://github.com/karelzak/util-linux/blob/master/libmount/src/utils.c#L772) If the passed filename (or /etc/mtab default) is a symlink, it falls back to line 1068 ff. where it ignores filename entirely. It first tries to parse /proc/self/mountinfo as MNT_FMT_MOUNTINFO, and if that fails, it falls back to parsing /proc/mounts (in old _PATH_PROC_MOUNTS format, i. e. mtab). So it doesn't matter that much what filename is, as long as it's not NULL or /etc/mtab, but for readability I still suggest using /proc/self/mountinfo, as that's what it will actually end up reading. FTR, I added a log_debug() to it (not contained in the submitted patch) and tested it with regular /etc/mtab, a symlink to /proc/mounts and a symlink to /proc/self/mountinfo, and it comes out just fine. Thanks, 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] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
On Thu, Feb 12, 2015 at 10:40:15AM +0100, Martin Pitt wrote:
So explicitly specify the file that we actually want to parse.
[1] first boot after a distro upgrade, or a package bug, or administrators
configuring it explicitly for some reason
https://launchpad.net/bugs/1419623
---
src/core/mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index f3977e6..61fd526 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1566,7 +1566,7 @@ static int mount_load_proc_self_mountinfo(Manager *m,
bool set_flags) {
if (!tb || !itr)
return log_oom();
-r = mnt_table_parse_mtab(tb, NULL);
+r = mnt_table_parse_mtab(tb, /proc/self/mountinfo);
This is bad solution. It resolves the issue, but forces libmount to
not read /run/mount/utab.
It would be better to ignore this problem for now, I'll very probably
add a new build-system option to disable libmount mtab parsing at all.
The heuristic which libmount uses to decide between mtab and mountinfo
is unnecessary in mainstream distros.
Karel
--
Karel Zak k...@redhat.com
http://karelzak.blogspot.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
Hey Karel, Karel Zak [2015-02-12 12:25 +0100]: -r = mnt_table_parse_mtab(tb, NULL); +r = mnt_table_parse_mtab(tb, /proc/self/mountinfo); This is bad solution. It resolves the issue, but forces libmount to not read /run/mount/utab. Can you please explain why? As far as I can see, __mnt_table_parse_mtab() only skips reading /run/mount/utab if reading /proc/self/mountinfo fails and it falls back to reading /proc/mounts (as it immediately returns there in all cases, not just in the failure case). This is probably unintended and a bug. But we shouldn't actually hit that here, as we actually do expect /proc/self/mountinfo to exist (systemd references it in a gazillion places). I. e. whether you pass NULL or /proc/self/mountinfo should not make a difference if /etc/mtab is a symlink to /proc (as it should be the case on every systemd installation) -- this patch would simply be a no-op, as it would run the same code paths in libmount with and without the patch. And if /etc/mtab is a file, then without the patch it does mnt_table_parse_file(/etc/mtab) and then parses the utab, and with the patch it parses /proc/self/mountinfo and then the utab. So what goes wrong here? Thanks, 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] preset-transient
On 11 February 2015 at 20:40, Lennart Poettering lenn...@poettering.net wrote: On Thu, 05.02.15 16:11, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: Some context for this patch. I would like to support a new preset model, which has the following properties: - distribution shipped defaults are enabled - and are applied to each boot/upgrade - without overriding any user configuration In many ways it is very similar to existing functionality but not quite possible to achieve all of the above. Thus, I'm introducing a new optional functionality, new unit configuration directory, and new transient-preset configurations. On each boot, if TransientPreset=yes, presets from /usr/lib/systemd/system-preset-transient/*.preset are applied into configuration path /run/systemd/system-preset-transient/. Why do we need an option for this? Can't the logic be to do this unconditionally if the /run/systemd/system-preset-transient/ dir exists and is non-empty? Well /run/systemd/system-preset-transient/ does not exist on boot, but rather created when transient-presets are applied. I guess, it's a typo, and you meant /usr/lib/systemd/system-preset-transient dir exists and is non-empty. That would be good, however, unlike normal presets it would not give the user option to opt-into/opt-out as easily. (With normal presets /etc/machine-id is the flag file, which is accessible to the user to provision/unprovision, together with any desired overrides in /etc/systemd/system-preset/*.preset). Would it be good if I change this portion of the patch logic as follows: * drop all the configure/option flag cruft * if /usr/lib/systemd/system-preset-transient/ or /etc/systemd/system-preset-transient exist and are not empty - run transient presets The logic to apply system-presets remains the same. If a distro chooses not to use system-presets, it should either guarantee pre-generated /etc/machine-id, or ship disable * preset policy. Configuration options are for user/admins, but I am pretty sure this is a distro choice, not something the admin should be able to toggle without change the distro. It is a distro choice to use presets, transient-presets, or both. However, it seemed to me at the time that it should be offered to the user to opt-out of distro choice, or opt-in into things not enabled by distro. Thus I made it very explicit transient-presets config option. I guess autodetecting them is mode of least surprise. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] Always use recvmsg with MSG_CMSG_CLOEXEC
On Tue, 10.02.15 21:26, Lennart Poettering (lenn...@poettering.net) wrote: On Tue, 10.02.15 12:06, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: Well, all but two of these recvmsg() invocations apply to network sockets, which cannot receive fds, hence specifying the flag is kinda pointless... For the other two cases we should probably close all fds we receive... I mean receiving them and not doing anything with them is not any worse or better as doing so and having O_CLOEXEC set for them... That said, I think it probably makes sense to enforce the general rule that recvmsg() must be invoked with MSG_CMSG_CLOEXEC, hence I applied your patch and updated the CODING_STYLE to mention this. And reverted again. It's not OK apparently to pass MSG_CMSG_CLOEXEC for to recvmsg() on raw sockets and suchlike... BTW: It is greatly appreciated to test patches before submitting them. 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] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier
On Thu, Feb 12, 2015 at 08:56:00AM +, Rauta, Alin wrote:
Well, one option could be to keep a set of bound_by and bound_to links
around for each link, and then just update that each time an interface
comes, goes, or changes names.
Yes, but the updates need to be done for all links and I'm not sure adding
this is a good thing.
I'm now having 64 links on the switch and I need the failure detection in
networkd to be quite fast because however even now it's probably slower due
to evaluating dynamically the BindCarrier strings when comparing this with
the previous solution with an UFD group monitoring some interfaces and with
some internal counters knowing exactly when to issue link_down for an
interface. So adding bound_by and bound_to makes the solution even slower.
How many times per second will you be avaluating this?
Besides this, having only one function sd_network_link_get_carrier_bound_to
makes also sense because only the behavior of bond_to links is controlled
by this feature. bound_by means almost nothing for an interface. A tool
like networkctl may take into account to display only the bound_to links
because that's what's relevant. The fact that networkctl displays both
bound_to and bound_by it's a good thing, but it doesn't mean each tool
should do that.
If a link goes down, isn't the bound_by list useful to look at links
which need to be checked and potentiallly brought down?
Zbyszek
/Alin
-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Wednesday, February 11, 2015 6:03 PM
To: Rauta, Alin
Cc: zbys...@in.waw.pl; t...@jklm.no; systemd-devel@lists.freedesktop.org;
Kinsella, Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using
BindCarrier
On Wed, 11.02.15 17:44, Rauta, Alin (alin.ra...@intel.com) wrote:
Hi Lennart,
+_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIERS, ifindex, ret); }
+
I think it would be better to have two calls here:
int sd_network_link_get_carrier_bound_to(int ifindex, int **others);
int sd_network_link_get_carrier_bound_by(int ifindex, int
**others);
In terms of functionality, sd_network_link_get_carriers is
actually sd_network_link_get_carrier_bound_to and is applicable to
bound to links just like BindCarrier= is available only for bound
to links. I wanted to save to systemd run files just minimum info.
If I add sd_network_link_get_carrier_bound_by, then each time
link_save is called for a link I should query BindCarrier=s for
all interfaces to print each link that bounds the current interface.
Then, if I rename a link I should call link_save for all available
links because the BindCarrier= can be interpreted in another way due
to wildcards.
Well, one option could be to keep a set of bound_by and bound_to links around
for each link, and then just update that each time an interface comes, goes,
or changes names. That way you always have direct access to the bound links,
and don't have to resolve the globs each time you need them, but only when
they actually change?
The reason why I figured having two calls for this would be useful is simply
to make it easy to write tools like networkctl, which wants to show this
information in both directions for each interface...
+/* get the links that are bound to this port. */ static int
+get_downlinks(const char *name,
+ sd_rtnl_message *m,
+ LinkInfo **downlinks,
+ int *down_count) {
Regarding get_uplinks and get_downlinks I can rename them to
get_links_bound_to and get_links_bound_by. Would this be fine ?
Sure!
But before you rework any of this, let's see what Tom has to say, he's the
networkd maintainer...
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] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
On Thu, 12.02.15 10:40, Martin Pitt (martin.p...@ubuntu.com) wrote:
So right after we popped out of initramfs (which doesn't have an
fstab, nor /etc/mtab, nor does it do anything else than mouting /
read-only) we see all these mounts which can't possibly happen that
early -- e. g. run-user-115.mount or /home/martin (which is on
ecryptfs). So I finally discovered that a packaging bug in
lxcfs turned /etc/mtab from a /proc/mounts symlink back into a file,
and mount_load_proc_self_mountinfo() parsed that to instantiate all
those mounts from the previous boot into mount unit, causing that
effect.
So of course we'll fix that packaging bug, but there are still times
when /etc/mtab might be a file; e. g. the first time you boot systemd
after an upgrade.
To make systemd robust against this, I fixed
mount_load_proc_self_mountinfo() to actually do what it intends to do,
instead of loading /etc/mtab (which is still util-linux' default for
mnt_table_parse_mtab()).
Urks, we never want to read /etc/mtab from PID 1, indeed. I am a bit
puzzled by mnt_table_parse_mtab() thiugh. The name suggests it parses
/etc/mtab files (which have the same format as /proc/self/mounts). But
Can we really just arse /proc/self/mountinfo to it, which has a very
different format?
Karel, can you elaborate on this?
I raelly want to keep /etc/mtab out of all codepaths in PID 1. What's
the right way to do that with libmnt? We want only the stuff from
/proc/self/mountinfo, plus the stuff from /run, merged into one!
Karel, is this patch by Martin what we should be doing?
From 4d3bcd8cec801d7a2a773388ae281ca692a7f2d5 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Thu, 12 Feb 2015 10:30:00 +0100
Subject: [PATCH] core/mount: ensure that we parse /proc/self/mountinfo
util-linux' mnt_table_parse_mtab() still defaults to parsing /etc/mtab. So if
that is a file [1] , we parse outdated information during boot, leading to
creating
mount units for nonexisting mounts which later have to get cleaned up. The
cleanup races with mounting them from fstab, which sometimes causes fstab
mounts to get unmounted again during boot.
So explicitly specify the file that we actually want to parse.
[1] first boot after a distro upgrade, or a package bug, or administrators
configuring it explicitly for some reason
https://launchpad.net/bugs/1419623
---
src/core/mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index f3977e6..61fd526 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1566,7 +1566,7 @@ static int mount_load_proc_self_mountinfo(Manager *m,
bool set_flags) {
if (!tb || !itr)
return log_oom();
-r = mnt_table_parse_mtab(tb, NULL);
+r = mnt_table_parse_mtab(tb, /proc/self/mountinfo);
if (r 0)
return r;
--
2.1.4
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] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
On Thu, Feb 12, 2015 at 12:25:33PM +0100, Karel Zak wrote:
On Thu, Feb 12, 2015 at 10:40:15AM +0100, Martin Pitt wrote:
So explicitly specify the file that we actually want to parse.
[1] first boot after a distro upgrade, or a package bug, or administrators
configuring it explicitly for some reason
https://launchpad.net/bugs/1419623
---
src/core/mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index f3977e6..61fd526 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1566,7 +1566,7 @@ static int mount_load_proc_self_mountinfo(Manager *m,
bool set_flags) {
if (!tb || !itr)
return log_oom();
-r = mnt_table_parse_mtab(tb, NULL);
+r = mnt_table_parse_mtab(tb, /proc/self/mountinfo);
This is bad solution. It resolves the issue, but forces libmount to
not read /run/mount/utab.
It would be better to ignore this problem for now, I'll very probably
add a new build-system option to disable libmount mtab parsing at all.
The heuristic which libmount uses to decide between mtab and mountinfo
is unnecessary in mainstream distros.
I will also improve mnt_table_parse_mtab() to check if we read the
filesystems from kernel (from /proc) and if yes than it will always
read /run/mount/utab too. The result will be more robust for people
who use libmount with mtab parsing code.
Karel
--
Karel Zak k...@redhat.com
http://karelzak.blogspot.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] preset-transient
On Thu, 12.02.15 11:05, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 11 February 2015 at 20:51, Lennart Poettering lenn...@poettering.net wrote: On Fri, 06.02.15 20:28, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: Hum, we told at the sprint that we wanted to be that available for everyone, and not having any conditions. Distros which still desires only the existing behavior would not ship files in *-preset-transient directories. Running any presets commands unconditionally, without any preset configuration is harmful. Prime example, if one doesn't ship any .preset (even the one that comes with systemd) shutdown.target gets activated and all that system does on boot is going to shutdown straight away. Hmm, not following? Can you elaborate? With this patch, (as is, without taking all of the above mentioned feedback) AND transient-presets enabled via config option AND no .preset files shipped at all for neither of preset types AND no machine-id one will not be able to boot =) i guess, this only points stronger to distro should be configured sanely and this is not a toggle to play with. Actually systemd should be able to boot fine with a disable * policy, i.e. zero services enabled. The really essential services are enabled statically anyway... (It seems like, after enable * a few things are enabled - e.g. debug-shell.service console-shell.service, the boot reaches multiuser target and one sees maintainance prompt, after which the system goes to poweroff. I'm not quite sure how to debug this better, but my suspicion is that console-shell is stopped, which has ExecStopPost=-/usr/bin/systemctl poweroff. Maybe this is simply a bug in some of the default units. Is enable * alone default policy actually supported?) Hmm, we explicitly disable debug-shell and console-shell in 90-systemd.preset to avoid confusion about these services... 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] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
Martin Pitt [2015-02-12 12:40 +0100]: Can you please explain why? Nevermind, I see it now. So what actually would work is to call it with a nonexisting file, a directory, a symlink, or just about anything else which isn't a regular file. Thus mnt_table_parse_mtab(tb, /) would actually work equally well and would read utab again, but it's of course an ugly workaround.. Thanks for the IRC explanation! 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] Failed units and Unit type .busname is not supported on this system
On Thu, Feb 12, 2015 at 10:28:10AM +0100, Tom Gundersen wrote:
Just an update on the above. unit type .busname is not supported on
this system isn't the cause of the problem that I was seeing (I still
don't know why this appears or if it is significant in other ways but it
would appear not to be so).
Most probably this was caused by the lack of a conditional in
systemd-networkd.busname (which was fixed a few days ago). Either way
it is not important (as you don't appear to be using kdbus).
...and it can be fixed by finding all .busname units ('systemctl
list-unit-files -t busname') and deleting them.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] avahi disconnects from bus with kdbus
No problem, i will try do some extensive testing the next couple of days. kdbus is now added to kernel entry cmdline :) 2015-02-12 19:12 GMT+01:00 David Herrmann dh.herrm...@gmail.com: Hi On Wed, Feb 11, 2015 at 11:17 AM, Daniel Buch boogiewasth...@gmail.com wrote: Nice, everything works flawlessly with current git now. Good job! Thanks for testing! No idea which commit exactly fixed it, so if you see it again, please let us know. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd mysteriously shutting down after launch
On Thu, 2015-02-12 at 20:15 +0100, Tom Gundersen wrote: On Thu, Feb 12, 2015 at 7:28 PM, Keller, Jacob E Now I'm having an interesting issue with the current git of systemd-networkd... It works just fine on load, and I get an ip address and everything is happy. After some amount of time, systemd-networkd goes into shutting down.. and I lose my ip address.. There is nothing obvious in the log to indicate that it was turned off. Any suggestions? I'm capturing a clean boot with the issue with SYSTEMD_LOG_LEVEL=debug enabled for more information now. Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd mysteriously shutting down after launch
On Thu, 2015-02-12 at 22:30 +, Keller, Jacob E wrote: On Thu, 2015-02-12 at 20:15 +0100, Tom Gundersen wrote: On Thu, Feb 12, 2015 at 7:28 PM, Keller, Jacob E Now I'm having an interesting issue with the current git of systemd-networkd... It works just fine on load, and I get an ip address and everything is happy. After some amount of time, systemd-networkd goes into shutting down.. and I lose my ip address.. There is nothing obvious in the log to indicate that it was turned off. Any suggestions? I'm capturing a clean boot with the issue with SYSTEMD_LOG_LEVEL=debug enabled for more information now. Regards, Jake Here's the output... of systemctl status and journalctl after a boot up.. My suspicion is that these lines are somehow related to the shutdown: Feb 12 14:31:02 jekeller-copperpass systemd-networkd[1012]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=26 reply_cookie=0 error=n/a Feb 12 14:31:02 jekeller-copperpass systemd-networkd[1012]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=ReleaseName cookie=27 reply_cookie=0 error=n/a Feb 12 14:31:02 jekeller-copperpass systemd-networkd[1012]: Got message type=signal sender=org.freedesktop.DBus destination=:1.3 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameLost cookie=7 reply_cookie=0 error=n/a Feb 12 14:31:02 jekeller-copperpass systemd-networkd[1012]: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=11 reply_cookie=0 error=n/a Feb 12 14:31:02 jekeller-copperpass systemd-networkd[1012]: DHCP CLIENT (0x926441b5): FREE I'm unsure what this is, -- Logs begin at Mon 2012-12-31 20:02:09 PST, end at Thu 2015-02-12 14:32:54 PST. -- Feb 12 14:30:17 jekeller-copperpass systemd[1]: Starting Network Service... Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=2 reply_cookie=0 error=n/a Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=3 reply_cookie=0 error=n/a Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: timestamp of '/etc/systemd/network' changed Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: timestamp of '/usr/lib/systemd/network' changed Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: ens9: flags change: +MULTICAST +BROADCAST Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: ens9: link 7 added Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: device 0x7fd996e0 has devpath '/devices/pci:00/:00:02.0/:06:00.0/:07:09.0/:09:00.0/net/ens9' Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: device 0x7fd996e0 filled with db file data Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: ens9: udev initialized link Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: ens9: saved original MTU: 1500 Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: ens8: flags change: +MULTICAST +BROADCAST Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: ens8: link 6 added Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: device 0x7fd991112df0 has devpath '/devices/pci:00/:00:02.0/:06:00.0/:07:08.0/:08:00.0/net/ens8' Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: device 0x7fd991112df0 filled with db file data Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: ens8: udev initialized link Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: ens8: saved original MTU: 1500 Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: enp4s0f3: flags change: +MULTICAST +BROADCAST Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: enp4s0f3: link 5 added Feb 12 14:30:18 jekeller-copperpass systemd-networkd[1012]: device 0x7fd991114470 has devpath '/devices/pci:00/:00:01.1/:04:00.3/net/enp4s0f3' Feb 12
Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?
On 11/02/15 20:03, Lennart Poettering wrote: Well, no. It would add Wants= and After=, instead of Requires= and After=. But I figure what you wrote was just a typo? yes what you say is what I meant. I think we should switch over to use WantsMountsFor for this unconditionally. After all we can always query the user as fallback... that sounds sensible. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Changing how localed writes keymap for xorg
Hi, [You can skip the middle hunk of this reply if you're not too interested in use-case; it just gives some background. There are more important questions towards the end tho' which I'd really appreciate feedback on! Thanks!] Peter Hutterer wrote on 11/02/15 22:30: On Wed, Feb 11, 2015 at 02:18:12PM +, Colin Guthrie wrote: CC'ing Peter Hutterer as the xorg input guy for his thoughts :) Lennart Poettering wrote on 11/02/15 11:46: On Wed, 11.02.15 10:43, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, I've recently run into an annoying problem with the localed xorg.conf snippet. As it writes an xorg.conf.d snippet, this seems ot take priority over udev properties (xkblayout) etc. which Xorg has supported for some time. If x starts with this snippet in place and it has a layout of e.g us, but then, later a keyboard with a udev property of xkblayout fr is plugged in (don't worry about where that property comes from, this is a supported feature of the config/udev.c in xserver), it will still get the us keymap. This sucks! udev is not a place for configuration really. I mean, in a few cases (like seat assignments) it is what we do, but in general: no it's not the place for end-user configuration. I am pretty sure that people want to assign keymaps with udev rules, are smart enough to remove the config snippet localed has written. Yeah, I'm sure they are smart enough... until localed kicks in and writes it again just because the user has logged into some other DE for a while IMO, this is because you're using it the wrong way around. The decision we made when introducing xorg.conf.d snippets ~6 years ago was that configuration overrides any system stuff. I was never a big fan of udev setting xkb layouts directly but it was needed for Debian at the time (iirc) and it's been there ever since. We don't support any other option being set in udev directly. Thanks for sharing the background. I quite liked the idea generally, but it's interesting to note both yourself and Lennart aren't big fans! The correct approach to configuration like you want it is to write an xorg.conf.d snippet. localed uses the 00 prefix for a reason, so it can be overwritten by anything that sorts higher. you can easily emulate the static defaults by having a udev PROGRAM rule that drops a 01-... xorg.conf.d snippet. Yeah, I'm not really complaining about the snippet existing with 00, or the ability to override that snippet (I specifically *don't* want to override that snippet with another snippet in fact - I just don't like the fact that udev properties (which are easier to change dynamically and are read on hotplug events) override this init-time static config. I get why it's done that way round and will not push to change it. It's just annoying in this use case (see below for further explanation if you're curious). Also, anything plugged in to Xorg after running localectl (thus updating 00-keyboard.conf) will also get the us keymap (as that was what was in place at Xorg init time). Wouldn't it be better to do the following: 1. deprecate the 00-keyboard.conf xorg.conf.d file 2. Instead apply the locale settings in udev via xkb* properties No, certainly not. The Xorg fragment is actual configuration. Configuration should beat the rulesets really, which carry device metadata. Well, I don't disagree, but it would be nice to have a way such that inserting a new USB keyboard after configuring the global default, that it *actually* takes effect. Currently, without some other layer on top (as in GNOME), localed does not achieve this, but the udev approach does. To summarise: currently localed requires an Xorg restart for the defaults to be used which is not very dynamic and hotpluggy which is the usual systemd mantra! Using udev rules would allow this to be dynamically supported out of the box - but it is arguably the wrong place to store configuration. It would also be inconsistent. X only reads config files on startup. You may want to configure other things at runtime like tapping, scrolling, or even what devices are to be ignored. All of this only takes effect on server restart. Fair point. at which point we need to ask the question: what makes keyboards so special? and the answer seems to be that your DE doesn't support hotplugged keyboards, per-user keyboard settings, etc. So it feels to me, and correct me if I'm wrong here, that you want to reshape the default handling so you don't have to fix it in your DE (I don't actually know which one you're using, sorry). Yeah, I kinda left that out deliberately as the use case is a bit special. This is basically a pre-DE mini-wizard that kicks in in live mode to ask the user what their locale is, setup the language, timezone and keyboard and then boots into the DE of choice, whether it be GNOME, or KDE or something else (those two being the main ones). In the case of GNOME, setting the keymap and such is
Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier
Well, one option could be to keep a set of bound_by and bound_to links
around for each link, and then just update that each time an interface
comes, goes, or changes names.
Yes, but the updates need to be done for all links and I'm not sure adding this
is a good thing.
I'm now having 64 links on the switch and I need the failure detection in
networkd to be quite fast because however even now it's probably slower due to
evaluating dynamically the BindCarrier strings when comparing this with the
previous solution with an UFD group monitoring some interfaces and with some
internal counters knowing exactly when to issue link_down for an interface.
So adding bound_by and bound_to makes the solution even slower.
Besides this, having only one function sd_network_link_get_carrier_bound_to
makes also sense because only the behavior of bond_to links is controlled by
this feature. bound_by means almost nothing for an interface. A tool like
networkctl may take into account to display only the bound_to links because
that's what's relevant. The fact that networkctl displays both bound_to and
bound_by it's a good thing, but it doesn't mean each tool should do that.
/Alin
-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Wednesday, February 11, 2015 6:03 PM
To: Rauta, Alin
Cc: zbys...@in.waw.pl; t...@jklm.no; systemd-devel@lists.freedesktop.org;
Kinsella, Ray
Subject: Re: [PATCH v3] Added support for Uplink Failure Detection using
BindCarrier
On Wed, 11.02.15 17:44, Rauta, Alin (alin.ra...@intel.com) wrote:
Hi Lennart,
+_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIERS, ifindex, ret); }
+
I think it would be better to have two calls here:
int sd_network_link_get_carrier_bound_to(int ifindex, int **others);
int sd_network_link_get_carrier_bound_by(int ifindex, int
**others);
In terms of functionality, sd_network_link_get_carriers is
actually sd_network_link_get_carrier_bound_to and is applicable to
bound to links just like BindCarrier= is available only for bound
to links. I wanted to save to systemd run files just minimum info.
If I add sd_network_link_get_carrier_bound_by, then each time
link_save is called for a link I should query BindCarrier=s for
all interfaces to print each link that bounds the current interface.
Then, if I rename a link I should call link_save for all available
links because the BindCarrier= can be interpreted in another way due
to wildcards.
Well, one option could be to keep a set of bound_by and bound_to links around
for each link, and then just update that each time an interface comes, goes, or
changes names. That way you always have direct access to the bound links, and
don't have to resolve the globs each time you need them, but only when they
actually change?
The reason why I figured having two calls for this would be useful is simply to
make it easy to write tools like networkctl, which wants to show this
information in both directions for each interface...
+/* get the links that are bound to this port. */ static int
+get_downlinks(const char *name,
+ sd_rtnl_message *m,
+ LinkInfo **downlinks,
+ int *down_count) {
Regarding get_uplinks and get_downlinks I can rename them to
get_links_bound_to and get_links_bound_by. Would this be fine ?
Sure!
But before you rework any of this, let's see what Tom has to say, he's the
networkd maintainer...
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] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
Hello again,
Martin Pitt [2015-02-11 23:42 +0100]:
Lennart Poettering [2015-02-11 17:05 +0100]:
Actually, the fact that the unit changes directly from dead to
mounted is interesting. The unit does not go through mounting,
which means that it's not the unit that is invoking the /bin/mount
command for this but something else.. Do you see anything about this
in the logs?
Thanks for that hint, that's really useful.
So it was! I looked again at the debug output, and this looked really
fishy:
[5.627882] donald systemd[1]: Successfully created private D-Bus server.
[5.627887] donald systemd[1]: var-tmp.mount changed dead - mounted
[5.628023] donald systemd[1]: run-user-115.mount changed dead - mounted
[5.628120] donald systemd[1]: home-martin.mount changed dead - mounted
[5.628202] donald systemd[1]: dev-mqueue.mount changed dead - mounted
[5.628285] donald systemd[1]: dev-hugepages.mount changed dead - mounted
[5.628367] donald systemd[1]: sys-fs-fuse-connections.mount changed dead -
mounted
[5.628448] donald systemd[1]: -.mount changed dead - mounted
[5.628528] donald systemd[1]: srv.mount changed dead - mounted
[5.628609] donald systemd[1]: Unit srv.mount is bound to inactive service.
Stopping, too.
So right after we popped out of initramfs (which doesn't have an
fstab, nor /etc/mtab, nor does it do anything else than mouting /
read-only) we see all these mounts which can't possibly happen that
early -- e. g. run-user-115.mount or /home/martin (which is on
ecryptfs). So I finally discovered that a packaging bug in
lxcfs turned /etc/mtab from a /proc/mounts symlink back into a file,
and mount_load_proc_self_mountinfo() parsed that to instantiate all
those mounts from the previous boot into mount unit, causing that
effect.
So of course we'll fix that packaging bug, but there are still times
when /etc/mtab might be a file; e. g. the first time you boot systemd
after an upgrade.
To make systemd robust against this, I fixed
mount_load_proc_self_mountinfo() to actually do what it intends to do,
instead of loading /etc/mtab (which is still util-linux' default for
mnt_table_parse_mtab()).
Et voilà, boot now always works again!
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 4d3bcd8cec801d7a2a773388ae281ca692a7f2d5 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Thu, 12 Feb 2015 10:30:00 +0100
Subject: [PATCH] core/mount: ensure that we parse /proc/self/mountinfo
util-linux' mnt_table_parse_mtab() still defaults to parsing /etc/mtab. So if
that is a file [1] , we parse outdated information during boot, leading to creating
mount units for nonexisting mounts which later have to get cleaned up. The
cleanup races with mounting them from fstab, which sometimes causes fstab
mounts to get unmounted again during boot.
So explicitly specify the file that we actually want to parse.
[1] first boot after a distro upgrade, or a package bug, or administrators
configuring it explicitly for some reason
https://launchpad.net/bugs/1419623
---
src/core/mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index f3977e6..61fd526 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1566,7 +1566,7 @@ static int mount_load_proc_self_mountinfo(Manager *m, bool set_flags) {
if (!tb || !itr)
return log_oom();
-r = mnt_table_parse_mtab(tb, NULL);
+r = mnt_table_parse_mtab(tb, /proc/self/mountinfo);
if (r 0)
return r;
--
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] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
On Thu, 12.02.15 05:38, Michael Biebl (mbi...@gmail.com) wrote: 2015-02-11 20:12 GMT+01:00 Lennart Poettering lenn...@poettering.net: So, I have discussed this with Kay, David, Daniel, and co. And we kinda came to the conclusion that we might as well just drop the configurability where runlevel3-5.target point to. If we drop that, we Do you mean runlevel2-5, or is runlevel2 excluded for a reason? No, that was just a typo... Happy to take a patch for this... 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] Removing unnecessary includes
On Wed, 11.02.15 23:46, Thomas H.P. Andersen (pho...@gmail.com) wrote: On Wed, Feb 11, 2015 at 12:39 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 11.02.15 01:40, Thomas H.P. Andersen (pho...@gmail.com) wrote: Yep. Makes sense. Here is a status on what I have done so far. include-what-you-want does the following: 1) sorts the includes 2) adds missing headers for any symbols used 3) adds forward declarations 4) removes any unused headers (after step 2+3) 5) changes some headers. (only saw sys/poll.h to poll.h for now) The diff we get out of that is too big a mess to locate what we want: the currently unused headers. To break it up I first did the sorting in separate step. (I have a patch to commit after 219 for some minor issues that came up from that). I then started to look at all the removals and one by one see if they make sense today, or was due to step 2/3/5, or was something we want to keep like missing.h. It is slow manual work but I will get there. It would be helpful to know if we might want 2, 3, and 5 done? What precisely do you mean by 3? E.g. for src/journal/mmap-cache.h it replaces #include sys/stat.h by struct stat; since we only use the struct but none of the functions. Saves time including that header and anything it brings in with it. Oh, no, that sounds like an awful idea... We want readable, minimal sources, but certainly don't want to fine-tune compilation times with concepts like this... 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] Failed units and Unit type .busname is not supported on this system
On 06/02/15 17:12, John Lane wrote: Good afternoon. I have some errors in the boot sequence of a newly built system: I see: systemd[1]: Unit type .busname is not supported on this system. then later on: systemd-networkd[278]: Assertion 'bus' failed at src/libsystemd/sd-bus/bus-util.c:105, function bus_event_loop_with_idle(). Aborting. systemd[1]: Unit systemd-networkd.service entered failed state systemd-networkd.service failed. and systemd-logind[565]: Failed to connect to system bus: No such file or directory systemd-logind[565]: Failed to fully start up daemon: No such file or directory Failed to start Login Service. My systemctl status shows a degraded status with 3 failed units being UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-logind.service loaded failed failed Login Service ● systemd-networkd.service loaded failed failed Network Service ● systemd-networkd.socket loaded failed failed networkd rtnetlink socket However, it gets to the login prompt, I can log in and everything works (as far as I can tell). I assume that the failed units are a result of the busname is not supported on this system but I have no clue about what that means and what to do about it. Searches have turned up nothing. System details: Linux tsodium 3.18.5-1-ARCH #1 SMP PREEMPT Fri Jan 30 07:17:14 CET 2015 i686 GNU/Linux systemd 218 +PAM -AUDIT -SELINUX -IMA -APPARMOR -SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN built today from systemd-git 218.944.g30ae637-1 I am using a git checkout because I am using functionality that isn't in 218. Any suggestions appreciated. John ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Just an update on the above. unit type .busname is not supported on this system isn't the cause of the problem that I was seeing (I still don't know why this appears or if it is significant in other ways but it would appear not to be so). The failed units were a consequence of me using the ArchLinux systemd-git AUR package as part of a new system build. It's dependency list had omitted dbus and this caused the above breakages to occur do to the sysem not having dbus. Installing dbus fixed it. Problem solved. Unit type .busname is not supported on this system ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed units and Unit type .busname is not supported on this system
On Thu, 12.02.15 09:23, John Lane (syst...@jelmail.com) wrote: Just an update on the above. unit type .busname is not supported on this system isn't the cause of the problem that I was seeing (I still don't know why this appears or if it is significant in other ways but it would appear not to be so). To quote myself from an earlier mail: This may be ignored. .busname units are only supported on kdbus systems. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Whitespace in /etc/crypttab
Good morning, This just something I noticed recently: It doesn't seem to be possble to use whitespace in /etc/cryptab, for example in partition labels. Contrast with the similar /etc/fstab file which supports octal escape (\040). I see http://cgit.freedesktop.org/systemd/systemd/commit/?id=84cc2abf3472b[1] that PARTLABEL= is supported in /etc/cryptab although it isn't documented[2] http://www.freedesktop.org/software/systemd/man/crypttab.html. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=84cc2abf3472b [2] http://www.freedesktop.org/software/systemd/man/crypttab.html Take a label A B. This would have device symlink like /dev/disk/by-partlabel/A\x20B where A\x20B is the output of systemd-escape A B Placing an entry in /etc/crypttab like cryptvol PARTLABEL=A\040B none results in device units like dev-disk-by\x2dpartlabel-A\x5cx5c040B I also tried A\x20B I get dev-disk-by\x2dpartlabel-A\x5cx5cx20B GPT supports whitespace in partition labels. Is it possible to use whitespace in PARTLABEL in /etc/crypttab? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Suspend from wireless keyboard not working
Hello.
I'm trying to make my notebook (Lenovo Thinkpad X230) suspend when pressing
the sleep extra key on a wireless keyboard (Logitech K270 using the
Logitech unifying receiver).
I've been able to map the sleep key to the 'pauseplay' action in a
'/etc/udev/hwdb.d/70-keyboard.hwdb' file, for testing, and it works (as
pause/play, of course), but when I map it to 'suspend', nothing happens.
Pressing the suspend key on the notebook's own keyboard works as expected
(out of the box, no messing from my part).
I'm running Arch Linux, systemd-218-1, no desktop environment, just
WindowMaker. /etc/logind.conf has HandleSuspendKey on default
('#HandleSuspendKey=suspend').
I also just learned from /usr/share/doc/systemd/NEWS that since v210 logind
won't suspend when the notebook has the lid closed and is on a docking
station, which is my case. But even testing with lid open and out of the
dock, it won't suspend from the wireless keyboard.
What else would be needed? Where/what should I look for?
Thanks.
t'
--
(nil)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] kdbus in d-bus project
Hi all, Is anyone maintaining a patch series against upstream d-bus for kdbus integration? I checked the kdbus-dev branch linked to by the kdbus Google Code page: https://review.tizen.org/git/?p=platform/upstream/dbus.git;a=shortlog;h=refs/heads/kdbus-dev But it hasn't been updated in over a year, and in that time kdbus has changed almost completely (i.e. now is kdbusfs...). - Steven ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecStop IPC over same socket used for activation?
On Wed, Feb 11, 2015 at 09:29:29PM +0100, Lennart Poettering wrote: Ineed, analysis seems correct. I now made this change: http://lists.freedesktop.org/archives/systemd-devel/2015-February/028058.html Didn't test it though, please test if this fixes things for you! Thanks Lennart, I ran a test script that usually reproduced the issue in less than a minute for the past few hours without any issues. Looks good to me. - Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bootchart: display each CPU utilization/wait
---
src/bootchart/bootchart.c| 38 +-
src/bootchart/bootchart.conf | 1 +
src/bootchart/bootchart.h| 1 +
src/bootchart/svg.c | 65 +---
4 files changed, 70 insertions(+), 35 deletions(-)
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index b49e2c9..2c2b329 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -87,6 +87,7 @@ bool arg_filter = true;
bool arg_show_cmdline = false;
bool arg_show_cgroup = false;
bool arg_pss = false;
+bool arg_percpu = false;
int samples;
int arg_samples_len = DEFAULT_SAMPLES_LEN; /* we record len+1 (1 start sample)
*/
double arg_hz = DEFAULT_HZ;
@@ -122,6 +123,7 @@ static void parse_conf(void) {
{ Bootchart, ScaleX, config_parse_double, 0,
arg_scale_x },
{ Bootchart, ScaleY, config_parse_double, 0,
arg_scale_y },
{ Bootchart, ControlGroup, config_parse_bool, 0,
arg_show_cgroup },
+{ Bootchart, PerCPU, config_parse_bool, 0,
arg_percpu },
{ NULL, NULL, NULL, 0, NULL }
};
@@ -151,6 +153,7 @@ static void help(void) {
-F, --no-filter Disable filtering of unimportant or
ephemeral processes\n
-C, --cmdline Display full command lines with
arguments\n
-c, --control-group Display process control group\n
+ --per-cpu Draw each CPU utilization and wait
bar also\n
-h, --helpDisplay this message\n\n
See bootchart.conf for more information.\n,
program_invocation_short_name,
@@ -163,20 +166,26 @@ static void help(void) {
}
static int parse_argv(int argc, char *argv[]) {
+
+enum {
+ARG_PERCPU,
+};
+
static const struct option options[] = {
-{rel, no_argument,NULL, 'r'},
-{freq, required_argument, NULL, 'f'},
-{samples, required_argument, NULL, 'n'},
-{pss, no_argument,NULL, 'p'},
-{output,required_argument, NULL, 'o'},
-{init, required_argument, NULL, 'i'},
-{no-filter, no_argument,NULL, 'F'},
-{cmdline, no_argument,NULL, 'C'},
-{control-group, no_argument,NULL, 'c'},
-{help, no_argument,NULL, 'h'},
-{scale-x, required_argument, NULL, 'x'},
-{scale-y, required_argument, NULL, 'y'},
-{entropy, no_argument,NULL, 'e'},
+{rel, no_argument,NULL, 'r' },
+{freq, required_argument, NULL, 'f' },
+{samples, required_argument, NULL, 'n' },
+{pss, no_argument,NULL, 'p' },
+{output,required_argument, NULL, 'o' },
+{init, required_argument, NULL, 'i' },
+{no-filter, no_argument,NULL, 'F' },
+{cmdline, no_argument,NULL, 'C' },
+{control-group, no_argument,NULL, 'c' },
+{help, no_argument,NULL, 'h' },
+{scale-x, required_argument, NULL, 'x' },
+{scale-y, required_argument, NULL, 'y' },
+{entropy, no_argument,NULL, 'e' },
+{per-cpu, no_argument,NULL, ARG_PERCPU},
{}
};
int c, r;
@@ -237,6 +246,9 @@ static int parse_argv(int argc, char *argv[]) {
case 'e':
arg_entropy = true;
break;
+case ARG_PERCPU:
+arg_percpu = true;
+break;
case 'h':
help();
return 0;
diff --git a/src/bootchart/bootchart.conf b/src/bootchart/bootchart.conf
index c73328f..2d7cb61 100644
--- a/src/bootchart/bootchart.conf
+++ b/src/bootchart/bootchart.conf
@@ -22,3 +22,4 @@
#ScaleX=100
#ScaleY=20
#ControlGroup=no
+#PerCPU=no
diff --git a/src/bootchart/bootchart.h b/src/bootchart/bootchart.h
index 2c37835..26de0dd 100644
--- a/src/bootchart/bootchart.h
+++ b/src/bootchart/bootchart.h
@@ -118,6 +118,7 @@ extern bool arg_show_cmdline;
extern bool arg_show_cgroup;
extern bool arg_pss;
extern bool arg_entropy;
+extern bool arg_percpu;
extern bool initcall;
extern int samples;
extern int cpus;
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index e5569e1..e770625 100644
---
Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'
В Wed, 11 Feb 2015 21:19:16 +0100 Lennart Poettering lenn...@poettering.net пишет: But the problem is not limited to legacy initscripts. It makes it generally unsafe to have aliases via symlinks. Aliases were always meant for compatibility but this problems exactly means that compatibility is broken here - when you replace unit A with compatibility link to unit B things may be broken unless you always refer to A when you refer to B. At which point why have alias at all? I think it's completely Ok that dependencies on aliases only work as long as they are referenced at least once by them. This isn't really that surprising a behaviour I think. Sorry if I was not clear. User had WantedBy=A.target in the past and other places had Want/Require=A.target. Now A.target - B.target and all other places were adjusted to Want/Require=B.target. As was demonstrated all user units that were using WantedBy=A.target are now effectively broken. Aliases imply that they are interchangeable. If they are not that must be at least quite clear and explicitly stated so in manual. If aliases are not interchangeable than the only use case I can see is for one way migration from old to new name but exactly this use case is broken. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] Added support for Uplink Failure Detection using BindCarrier
В Thu, 12 Feb 2015 15:25:08 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Feb 12, 2015 at 12:52:00PM +, Rauta, Alin wrote: Yes, but the updates need to be done for all links and I'm not sure adding this is a good thing. I'm now having 64 links on the switch and I need the failure detection in networkd to be quite fast because however even now it's probably slower due to evaluating dynamically the BindCarrier strings when comparing this with the previous solution with an UFD group monitoring some interfaces and with some internal counters knowing exactly when to issue link_down for an interface. So adding bound_by and bound_to makes the solution even slower. How many times per second will you be avaluating this? Each time an event happens: a link appears, disappears, changes flags or names. Yes, I know the causes. I'm asking how often they can realisticly occur. You misunderstand. It is not how often they occur but how fast reaction is. When (final) uplink goes down we want to bring dependent interfaces down as soon as possible. Besides this, having only one function sd_network_link_get_carrier_bound_to makes also sense because only the behavior of bond_to links is controlled by this feature. bound_by means almost nothing for an interface. A tool like networkctl may take into account to display only the bound_to links because that's what's relevant. The fact that networkctl displays both bound_to and bound_by it's a good thing, but it doesn't mean each tool should do that. If a link goes down, isn't the bound_by list useful to look at links which need to be checked and potentiallly brought down? It can be useful, that's why networkctl has the updates, but are talking about the showing functionality or about the run-time up-down game between interfaces ? The latter. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] avahi disconnects from bus with kdbus
Hi again, I found another problem, again with avahi-daemon but in combination with Telepathy haze. feb 13 08:26:39 dbuch-laptop systemd-coredump[1211]: Process 1167 (telepathy-haze) of user 1000 dumped core. Stack trace of thread 1167: #0 0x7fe0c9557ae0 g_logv (libglib-2.0.so.0) #1 0x7fe0c9557d1f g_log (libglib-2.0.so.0) #2 0x0041261c n/a (telepathy-haze) #3 0x7fe0c955091d g_main_context_dispatch (libglib-2.0.so.0) #4 0x7fe0c9550cf8 n/a (libglib-2.0.so.0) #5 0x7fe0c9551022 g_main_loop_run (libglib-2.0.so.0) #6 0x7fe0c9214631 tp_run_connection_manager (libtelepathy-glib.so.0) #7 0x0040e73b n/a (telepathy-haze) #8 0x7fe0c8b1e800 __libc_start_main (libc.so.6) #9 0x0040e7ad n/a (telepathy-haze) feb 13 08:26:42 dbuch-laptop systemd[642]: Starting DBUS1: org.freedesktop.Telepathy.ConnectionManager.haze... feb 13 08:26:42 dbuch-laptop systemd[642]: Started DBUS1: org.freedesktop.Telepathy.ConnectionManager.haze. feb 13 08:26:42 dbuch-laptop systemd[1]: Starting Avahi mDNS/DNS-SD Stack... feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Found user 'avahi' (UID 84) and group 'avahi' (GID 84). feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Successfully dropped root privileges. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: avahi-daemon 0.6.31 starting up. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Successfully called chroot(). feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Successfully dropped remaining capabilities. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Loading service file /services/sftp-ssh.service. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Process 313 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid) feb 13 08:26:42 dbuch-laptop systemd[1]: Started Avahi mDNS/DNS-SD Stack. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Loading service file /services/ssh.service. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Joining mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.1.2. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: New relevant interface wlp3s0.IPv4 for mDNS. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Network interface enumeration completed. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Registering new address record for fe80::eab1:fcff:fec4:eae1 on wlp3s0.*. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Registering new address record for 192.168.1.2 on wlp3s0.IPv4. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Registering HINFO record with values 'X86_64'/'LINUX'. feb 13 08:26:42 dbuch-laptop systemd-bus-proxyd[329]: Failed to send message to bus: Operation not permitted feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Disconnected from D-Bus, exiting. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Got SIGTERM, quitting. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: Leaving mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.1.2. feb 13 08:26:42 dbuch-laptop avahi-daemon[1217]: avahi-daemon 0.6.31 exiting. This happens when you try to log on empathy, more specifically Peoples Nearby. Let me know if you want additional logs or anything. Cheers, Daniel 2015-02-12 23:46 GMT+01:00 Daniel Buch boogiewasth...@gmail.com: No problem, i will try do some extensive testing the next couple of days. kdbus is now added to kernel entry cmdline :) 2015-02-12 19:12 GMT+01:00 David Herrmann dh.herrm...@gmail.com: Hi On Wed, Feb 11, 2015 at 11:17 AM, Daniel Buch boogiewasth...@gmail.com wrote: Nice, everything works flawlessly with current git now. Good job! Thanks for testing! No idea which commit exactly fixed it, so if you see it again, please let us know. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: Fix by-path of mmc RPMB partitions and don't blkid them
Martin Pitt [2015-02-12 19:52 +0100]: Lennart Poettering [2015-02-12 18:50 +0100]: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=090d25fe224c0 Looks simple enough. Though I wonder if [0-9] is the right match, shouldn't it also cover multiple numbers there? Hm, yes. fnmatch() doesn't support a regexp-like one or more digits; it's less precise, but as the kernel doesn't generate arbitrary device names but at most things like mmcblk0p1, extending the glob to mmcblk[0-9]*rpmb is actually safe. Pushed now with this change: http://cgit.freedesktop.org/systemd/systemd/commit/?id=b87b01c 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] Added support for Uplink Failure Detection using BindCarrier
On Thu, Feb 12, 2015 at 12:52:00PM +, Rauta, Alin wrote: Yes, but the updates need to be done for all links and I'm not sure adding this is a good thing. I'm now having 64 links on the switch and I need the failure detection in networkd to be quite fast because however even now it's probably slower due to evaluating dynamically the BindCarrier strings when comparing this with the previous solution with an UFD group monitoring some interfaces and with some internal counters knowing exactly when to issue link_down for an interface. So adding bound_by and bound_to makes the solution even slower. How many times per second will you be avaluating this? Each time an event happens: a link appears, disappears, changes flags or names. Yes, I know the causes. I'm asking how often they can realisticly occur. Besides this, having only one function sd_network_link_get_carrier_bound_to makes also sense because only the behavior of bond_to links is controlled by this feature. bound_by means almost nothing for an interface. A tool like networkctl may take into account to display only the bound_to links because that's what's relevant. The fact that networkctl displays both bound_to and bound_by it's a good thing, but it doesn't mean each tool should do that. If a link goes down, isn't the bound_by list useful to look at links which need to be checked and potentiallly brought down? It can be useful, that's why networkctl has the updates, but are talking about the showing functionality or about the run-time up-down game between interfaces ? The latter. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured
On Wed, Feb 11, 2015 at 09:32:00PM +0100, Lennart Poettering wrote: On Wed, 11.02.15 20:22, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: I actually see the same behavior now again, so the removal of biosdevname does not solve this problem! :( Is there any more information I can provide? Hmm, it appears as if networkd completely misses the netlink messages describing your em0 link. Yes. I believe that possibly the netlink messages are occurring too early before networkd has started. Thus, when I restart the service after startup it works fine. Well, the first thing after subscribing to links coming/going that networkd does is query the kernel for the list of devices it has. This means that it should always get all links, regardless when it is started. To debug this it might be worse adding debug log messages to manager_rtnl_process_link() to see if any rtnl messages announcing the interface are received by networkd. If no such message arrives there, then this indicates a kernel issue, otherwise a bug in networkd. Lennart How would I go about doing that? I am guessing that means modifying the source of networkd? Correct. I'm also somewhat unfamiliar with the best practice for installing a local copy of systemd from source rather than from the Fedora RPMs.. Most of us tend to run git versions of systemd, and simply build them with ./autogen.sh c sudo make install. But of course, you should know what you do then, and there's no easy path back to the FEdora version... For the case of trying to install a specific utility from git, full installation is overkill. It's enough to do git clone ./autogen.sh c make install ./systemd-networkd /usr/lib/systemd/ Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
On Thu, 12.02.15 13:27, Karel Zak (k...@redhat.com) wrote: On Thu, Feb 12, 2015 at 12:01:13PM +0100, Lennart Poettering wrote: And the stuff from /run is always merged into it, regardless which file is read? No, if you specify any filename and the file exists than it does not read from /run, I have fixed this mistake https://github.com/karelzak/util-linux/commit/60d29f827b94097fb718dcb02fad6ccb571bdb2b so don't use Martin's patch on systems with util-linux 2.26 (now -rc2, stable next week). I will not apply it to systemd git. If I am right then as soon as you fixed libmount so that the whole handling of /etc/mtab can be turned off, then you will make that the default in Fedora, and no changes to systemd will be necessary at all, correct? 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] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
On Thu, Feb 12, 2015 at 03:38:13PM +0100, Lennart Poettering wrote: If I am right then as soon as you fixed libmount so that the whole handling of /etc/mtab can be turned off, then you will make that the default in Fedora, and no changes to systemd will be necessary at all, correct? Correct. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
On Thu, Feb 12, 2015 at 12:01:13PM +0100, Lennart Poettering wrote: And the stuff from /run is always merged into it, regardless which file is read? No, if you specify any filename and the file exists than it does not read from /run, I have fixed this mistake https://github.com/karelzak/util-linux/commit/60d29f827b94097fb718dcb02fad6ccb571bdb2b so don't use Martin's patch on systems with util-linux 2.26 (now -rc2, stable next week). Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured
On Thu, Feb 12, 2015 at 11:45 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 11.02.15 22:28, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: On Wed, 2015-02-11 at 21:46 +0100, Lennart Poettering wrote: On Wed, 11.02.15 20:36, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: Yes. I believe that possibly the netlink messages are occurring too early before networkd has started. Thus, when I restart the service after startup it works fine. Well, the first thing after subscribing to links coming/going that networkd does is query the kernel for the list of devices it has. This means that it should always get all links, regardless when it is started. What about network device renames? Devices are renamed after they appear. Is it also possible that networkd is started too early and thus the devices haven't actually appeared yet? But.. then it should get the message once it does appear? (assuming here that it continues listening to rtnl messages about links) networkd should get all netlink msgs about all of this just fine, and be able to track renames and everything. How difficult would it be to create an RPM? Well, you can get the spec file from fedpkg and then use it on a tarball from systemd git made with make dist. But you probably need to make a number of updates to the .spec file. Unless you are an RPM guru I wouldn't bother. Lennart Ok. I got the upstream systemd installed. Now I get a very different behavior, which I am unsure of. I cut off the last message as it repeated some odd ten thousand times or so... Presumably retry/failing... At any rate, it appears possible that some configuration is wrong, or similar? Any suggestions/thoughts now? Feb 11 14:21:47 jekeller-copperpass systemd-networkd[1068]: enp4s0f0 : flags change: +UP Feb 11 14:21:47 jekeller-copperpass systemd-networkd[1068]: enp4s0f0 : enp4s0f0: could not bring up interface: Invalid argument OK so this is already weird. This should now be fixed in git (5c3072eab6d2e11d89452987b017541d4654ac05). Feb 11 14:21:52 jekeller-copperpass systemd-networkd[1068]: DHCP CLIENT (0xc7096673): could not receive message from raw socket: Invalid argument Hmm, this one might actually be caused by d6d810fbf8071f8510450dbacd1d083f37603656. WIll revert that, please retest then! Lennart -- 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
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile.am man/systemd-networkd-wait-online.service.xml src/libsystemd src/network src/systemd TODO units/systemd-networkd.service.in units/systemd-n
On Mon, Feb 2, 2015 at 8:59 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 02.02.15 03:00, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
+static int systemd_netlink_fd(int *ret) {
+int n, fd, rtnl_fd = -1;
+
+n = sd_listen_fds(true);
+if (n = 0)
+return -EINVAL;
+
+for (fd = SD_LISTEN_FDS_START; fd SD_LISTEN_FDS_START + n; fd ++)
{
+if (sd_is_socket(fd, AF_NETLINK, SOCK_RAW, -1) 0) {
+if (rtnl_fd = 0)
+return -EINVAL;
+
+rtnl_fd = fd;
+}
+}
+
+if (rtnl_fd 0)
+return -EINVAL;
+
+*ret = rtnl_fd;
+
+return 0;
+}
BTW, if a function that returns an fd, can just do so as return value,
rather than as call-by-ref argument, since fds are = 0 and errors are
0, and hence we can use the full int range then.
+int sd_rtnl_new_from_netlink(sd_rtnl **ret, int fd) {
Can't his one be folded into sd_rtnl_open_fd()? It does one more step,
invoking bind() on the fd, but if we handling double binding
correctly, then I think that would be the cleaner API?
FTR: these suggestions have now been implemented in git.
Thanks!
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] rules: Fix by-path of mmc RPMB partitions and don't blkid them
Linux 3.10+ exposes RPMB (Replay Protected Memory Block) partitions of MMC
devices [1] ; trying to read them with blkid or other unspecific means will
cause kernel buffer I/O errors and timeouts. So don't run blkid on these.
Also ensure that /dev/disk/by-path creates proper symlinks and exposes the
-rpmb partition separately, instead of letting the normal partition symlink
point to the rpbm device (this is a race condition).
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=090d25fe224c0
https://launchpad.net/bugs/1333140
---
rules/60-persistent-storage.rules | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/rules/60-persistent-storage.rules
b/rules/60-persistent-storage.rules
index 475b151..19fc4dc 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -53,7 +53,8 @@ KERNEL==mspblk[0-9]p[0-9], ENV{ID_NAME}==?*,
ENV{ID_SERIAL}==?*, SYMLINK+=
# by-path (parent device path)
ENV{DEVTYPE}==disk, DEVPATH!=*/virtual/*, IMPORT{builtin}=path_id
-ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, SYMLINK+=disk/by-path/$env{ID_PATH}
+ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, KERNEL==mmcblk[0-9]rpmb,
SYMLINK+=disk/by-path/$env{ID_PATH}-rpmb
+ENV{DEVTYPE}==disk, ENV{ID_PATH}==?*, KERNEL!=mmcblk[0-9]rpmb,
SYMLINK+=disk/by-path/$env{ID_PATH}
ENV{DEVTYPE}==partition, ENV{ID_PATH}==?*,
SYMLINK+=disk/by-path/$env{ID_PATH}-part%n
# skip unpartitioned removable media devices from drivers which do not send
change events
@@ -66,6 +67,9 @@ KERNEL==sr*, ENV{DISK_EJECT_REQUEST}!=?*,
ENV{ID_CDROM_MEDIA_TRACK_COUNT_DAT
KERNEL==sr*, ENV{DISK_EJECT_REQUEST}!=?*,
ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}==?*,
ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}==, \
IMPORT{builtin}=blkid --noraid
+# don't try to read Replay Protected Memory Block partitions
+KERNEL==mmcblk[0-9]rpmb, GOTO=persistent_storage_end
+
# probe filesystem metadata of disks
KERNEL!=sr*, IMPORT{builtin}=blkid
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Re: fstab mounts get unmounted during boot (.device unit bouncing?) -- solution
Hey Lennart and Karel, Lennart Poettering [2015-02-12 15:38 +0100]: I will not apply it to systemd git. Ack. I put a hacked version into the Debian package for now, as we'll have to live with util-linux 2.25 for the impending release: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=999fb5e2b0a0 (This will read /run/mount/utab, but it's certainly not upstream material). If I am right then as soon as you fixed libmount so that the whole handling of /etc/mtab can be turned off, then you will make that the default in Fedora, and no changes to systemd will be necessary at all, correct? \o/ looking forward to let /etc/mtab die a bit more :-) Thanks, 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] systemd-networkd not discovering all devices at bootup, and thus no network is configured
On Thu, 2015-02-12 at 14:23 +0100, Tom Gundersen wrote: On Thu, Feb 12, 2015 at 11:45 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 11.02.15 22:28, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: On Wed, 2015-02-11 at 21:46 +0100, Lennart Poettering wrote: On Wed, 11.02.15 20:36, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: Yes. I believe that possibly the netlink messages are occurring too early before networkd has started. Thus, when I restart the service after startup it works fine. Well, the first thing after subscribing to links coming/going that networkd does is query the kernel for the list of devices it has. This means that it should always get all links, regardless when it is started. What about network device renames? Devices are renamed after they appear. Is it also possible that networkd is started too early and thus the devices haven't actually appeared yet? But.. then it should get the message once it does appear? (assuming here that it continues listening to rtnl messages about links) networkd should get all netlink msgs about all of this just fine, and be able to track renames and everything. How difficult would it be to create an RPM? Well, you can get the spec file from fedpkg and then use it on a tarball from systemd git made with make dist. But you probably need to make a number of updates to the .spec file. Unless you are an RPM guru I wouldn't bother. Lennart Ok. I got the upstream systemd installed. Now I get a very different behavior, which I am unsure of. I cut off the last message as it repeated some odd ten thousand times or so... Presumably retry/failing... At any rate, it appears possible that some configuration is wrong, or similar? Any suggestions/thoughts now? Feb 11 14:21:47 jekeller-copperpass systemd-networkd[1068]: enp4s0f0 : flags change: +UP Feb 11 14:21:47 jekeller-copperpass systemd-networkd[1068]: enp4s0f0 : enp4s0f0: could not bring up interface: Invalid argument OK so this is already weird. This should now be fixed in git (5c3072eab6d2e11d89452987b017541d4654ac05). Feb 11 14:21:52 jekeller-copperpass systemd-networkd[1068]: DHCP CLIENT (0xc7096673): could not receive message from raw socket: Invalid argument Hmm, this one might actually be caused by d6d810fbf8071f8510450dbacd1d083f37603656. WIll revert that, please retest then! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Ok, I'll try with latest Git first, and if it still fails I'll try reverting the patch Lennart suggested. Thanks for the help! Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
