Re: [systemd-devel] Reduce unit-loading time
2015-05-20 1:01 GMT+08:00 Martin Pitt : > Hey cee1, > > cee1 [2015-05-18 23:52 +0800]: >> At the first glance, I find ureadahead has some difference compared >> with the readahead once in systemd, IIRC: > > Yes, for sure. systemd's was improved quite a bit. ureadahead is > mostly unmaintained, but it works well enough so we didn't bother to > put work into it until someone actually complains :-) > >> 1. ureadahead.service is in default.target, which means ureadahead >> starts later than systemd's? > > That mostly means that it's not started with e. g. emergency or > rescue. It still starts early (DefaultDependencies=false). > >> 2. The original systemd readahead has "collect" and "replay" two >> services, and these are done in ureadahead.service? > > Yes. > >> 3. IIRC, The original systemd readahead uses madvise(); ureadahead >> uses readahead() >> 4. The original systemd readahead uses fanotify() to get the list of >> accessed files; ureadahead use fsnotify > > I haven't verified these, but this sounds correct. ureadahead is > really old, presumably the newer features like fanotify weren't > available back then. I tried ureadahead, but got following error: """write(2, "ureadahead: Error while tracing:"..., 59ureadahead: Error while tracing: No such file or directory""" Needs an out-of-tree kernel patch? -- Regards, - cee1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Correct path to systemd-fsck in generated systemd-fsck-root.service
On Sun, May 24, 2015 at 10:33 PM, Mike Gilbert wrote:
> ---
> Makefile.am| 1 +
> src/shared/generator.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index f84a28d..70d4dc0 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -188,6 +188,7 @@ AM_CPPFLAGS = \
> -DCATALOG_DATABASE=\"$(catalogstatedir)/database\" \
>
> -DSYSTEMD_CGROUP_AGENT_PATH=\"$(rootlibexecdir)/systemd-cgroups-agent\" \
> -DSYSTEMD_BINARY_PATH=\"$(rootlibexecdir)/systemd\" \
> + -DSYSTEMD_FSCK_PATH=\"$(rootlibexecdir)/systemd-fsck\" \
> -DSYSTEMD_SHUTDOWN_BINARY_PATH=\"$(rootlibexecdir)/systemd-shutdown\"
> \
> -DSYSTEMD_SLEEP_BINARY_PATH=\"$(rootlibexecdir)/systemd-sleep\" \
> -DSYSTEMCTL_BINARY_PATH=\"$(rootbindir)/systemctl\" \
> diff --git a/src/shared/generator.c b/src/shared/generator.c
> index 8128499..807569a 100644
> --- a/src/shared/generator.c
> +++ b/src/shared/generator.c
> @@ -61,7 +61,7 @@ static int write_fsck_sysroot_service(const char *dir,
> const char *what) {
> "[Service]\n"
> "Type=oneshot\n"
> "RemainAfterExit=yes\n"
> -"ExecStart=/usr/lib/systemd/systemd-fsck %2$s\n"
> +"ExecStart=" SYSTEMD_FSCK_PATH " %2$s\n"
> "TimeoutSec=0\n",
> program_invocation_short_name,
> what,
> --
> 2.4.1
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Applied. Thanks!
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: if PR_SET_CHILD_SUBREAPER fails, log_error instead of warning
On Sat, May 23, 2015 at 6:04 PM, Cristian Rodríguez
wrote:
> It was a warning when we still supported kernel < 3.4. current
> minimum version is 3.7.
Hm, we don't actually fail out here, but we still try to continue.
Isn't 'warning' more appropriate in that case?
Cheers,
Tom
> src/core/main.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/src/core/main.c b/src/core/main.c
> index c39815b..3bebc98 100644
> --- a/src/core/main.c
> +++ b/src/core/main.c
> @@ -1608,9 +1608,7 @@ int main(int argc, char *argv[]) {
> if (arg_running_as == MANAGER_USER) {
> /* Become reaper of our children */
> if (prctl(PR_SET_CHILD_SUBREAPER, 1) < 0) {
> -log_warning_errno(errno, "Failed to make us a
> subreaper: %m");
> -if (errno == EINVAL)
> -log_info("Perhaps the kernel version is too
> old (< 3.4?)");
> +log_error_errno(errno, "Failed to make us a
> subreaper: %m");
> }
> }
>
> --
> 2.4.1
>
> ___
> 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] [PATCH] nspawn: be verbose about interface names
On Fri, May 22, 2015 at 4:02 PM, Umut Tezduyar Lindskog
wrote:
> Allowed interface name is relatively small. Lets not make
> users go in to the source code to figure out what happened.
>
> --machine=debian-tree conflicts with
> --machine=debian-tree2
>
> ex: Failed to add new veth \
> interfaces (host0, vb-debian-tree): File exists
> ---
> src/nspawn/nspawn.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
> index 5009363..646edea 100644
> --- a/src/nspawn/nspawn.c
> +++ b/src/nspawn/nspawn.c
> @@ -2627,7 +2627,7 @@ static int setup_veth(pid_t pid, char
> iface_name[IFNAMSIZ], int *ifi) {
>
> r = sd_rtnl_call(rtnl, m, 0, NULL);
> if (r < 0)
> -return log_error_errno(r, "Failed to add new veth
> interfaces: %m");
> +return log_error_errno(r, "Failed to add new veth interfaces
> (host0, %s): %m", iface_name);
>
> i = (int) if_nametoindex(iface_name);
> if (i <= 0)
> --
> 2.1.4
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Applied. Thansk!
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Correct path to systemd-fsck in generated systemd-fsck-root.service
This should also be flagged for backports since the hard-coded /usr/lib/systemd path will break any initramfs if rootprefix != /usr. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Correct path to systemd-fsck in generated systemd-fsck-root.service
---
Makefile.am| 1 +
src/shared/generator.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index f84a28d..70d4dc0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -188,6 +188,7 @@ AM_CPPFLAGS = \
-DCATALOG_DATABASE=\"$(catalogstatedir)/database\" \
-DSYSTEMD_CGROUP_AGENT_PATH=\"$(rootlibexecdir)/systemd-cgroups-agent\"
\
-DSYSTEMD_BINARY_PATH=\"$(rootlibexecdir)/systemd\" \
+ -DSYSTEMD_FSCK_PATH=\"$(rootlibexecdir)/systemd-fsck\" \
-DSYSTEMD_SHUTDOWN_BINARY_PATH=\"$(rootlibexecdir)/systemd-shutdown\" \
-DSYSTEMD_SLEEP_BINARY_PATH=\"$(rootlibexecdir)/systemd-sleep\" \
-DSYSTEMCTL_BINARY_PATH=\"$(rootbindir)/systemctl\" \
diff --git a/src/shared/generator.c b/src/shared/generator.c
index 8128499..807569a 100644
--- a/src/shared/generator.c
+++ b/src/shared/generator.c
@@ -61,7 +61,7 @@ static int write_fsck_sysroot_service(const char *dir, const
char *what) {
"[Service]\n"
"Type=oneshot\n"
"RemainAfterExit=yes\n"
-"ExecStart=/usr/lib/systemd/systemd-fsck %2$s\n"
+"ExecStart=" SYSTEMD_FSCK_PATH " %2$s\n"
"TimeoutSec=0\n",
program_invocation_short_name,
what,
--
2.4.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev now crashes in daemon mode
Hi Mantas, On Sun, May 24, 2015 at 11:40 AM, Mantas Mikulėnas wrote: > So, udev v220 crashes in my initramfs with the following message: > >> starting version v220 >> Assertion 'manager->pid == getpid()' failed at src/udev/udevd.c:568, >> function ev >> Aborting. > > It seems main calls manager_new() before forking, so the parent PID is > stored instead of child PID. > > (I'm using Arch Linux with the traditional mkinitcpio-based initramfs, which > starts udev using "systemd-udevd --daemon --resolve-names=never".) Thanks for the report. This should be fixed now in git, please let me know if that is not the case. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] What kdbus Version for systemd 220 ?
Dear group, Since a while I am experimenting with systemd and kdbus, till now with excellent results. Recently I tried to bump all versions to LATEST/HEAD, and ran into some issues. My short question: Is there a recommendation what kdbus version fits to the current systemd V220? Till now I was using kdbus from https://github.com/gregkh/kdbus, but the latest commit there is from Mar 6th ? And with this version kdbus seems not working properly with V220 here ( is_kdbus_available() in bus-util.c fails with ioctl KDBUS_CMD_BUS_MAKE). Thanks for any comments. Thomas Ritter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev now crashes in daemon mode
So, udev v220 crashes in my initramfs with the following message: > starting version v220 > Assertion 'manager->pid == getpid()' failed at src/udev/udevd.c:568, function ev > Aborting. It seems main calls manager_new() before forking, so the parent PID is stored instead of child PID. (I'm using Arch Linux with the traditional mkinitcpio-based initramfs, which starts udev using "systemd-udevd --daemon --resolve-names=never".) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] 219/Fedora22: NFS mounts do not set SELINUX label to nfs_t: errno=-22
Hi, On Fedora 22, systemd 219, NFS mounts no longer acquire a default label nfs_t. mount 192.168.1.6:/var/exports/1 1 -orootcontext=system_u:object_r:nfs_t mount.nfs: an incorrect mount option was specified [ 8316.276744] SELinux: security_context_to_sid(system_u:object_r:nfs_t) failed for (dev 0:51, type nfs4) errno=-22 To my surprise, it seems to acquire labels from the NFS server (Fedora 22/nfs4) - how is this possible? But..it breaks libvirtd/kvm: it sees the "right" label if this were a local filesystem but audit2allow complains: ls -lZ guestfs/centos7.img -rw-r--r--. 1 qemu qemu system_u:object_r:virt_image_t:s0 22987538432 May 24 14:56 guestfs/centos7.img ## for a image in /var/lib/libvirt this is the correct label. ## I do not know how it figured that from the NFS server SELinux is preventing qemu-system-x86 from read access on the file centos7.img (on NFS share). On Fedora 21, the files acquire the label nfs_t and setsebool -P virt_use_nfs=on Any ideas, Anthony ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
