Re: [systemd-devel] [PATCH] mount: don't run quotaon only for network filesystems
Lennart Poettering píše v Út 31. 03. 2015 v 19:30 +0200:
On Mon, 30.03.15 14:42, Lukas Nykryn (lnyk...@redhat.com) wrote:
If you havei for example ext4 on iscsi devices it is possible to setup
qoutas there. Unfortunatelly because such fstab entry contains _netdev,
systemd will not add dependency to quotaon.service.
I think this really needs a comment next to this in the sources,
otherwise this is likely to be changed back again the next time
somebody reworks the code, because he doesn't realize this...
Can you add a comment, please? Otherwise looks fine!
Added and pushed.
Thanks
Lukas
---
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 1251c94..f7633b7 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -102,7 +102,7 @@ static bool mount_is_auto(const MountParameters *p) {
static bool needs_quota(const MountParameters *p) {
assert(p);
-if (mount_is_network(p))
+if (p-fstype fstype_is_network(p-fstype))
return false;
if (mount_is_bind(p))
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Drop systemd-ui
On 03/31/2015 05:32 PM, Lennart Poettering wrote: On Mon, 30.03.15 20:35, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Heyja Should this not be dropped and *DE write,integrate/implement an graphical frontend to systemd for themselves? It's not like this is receiving the love it needs, hence I'm pretty sure nobody is using this. It's already dropped: we split it out of the main git repo for a while. Now it is its own repo, slowly bitrotting away. I wouldn't package it the way it is right now, but this is really up to the packagers. I mean, it's incomplete, out of date and really buggy, but I don't care too much if people use it anyway... Then you should not care too much if we properly take it out of it's misery and deliver it's final notice since it's always better to delete and or archive with a notice that relevant bits are unmaintained and they exists only for historic and or educational purposes than to simply split it out of the main git repo for it to die it's slow and miserably bit rotting death and somehow expect people to magically figure that out. The former sends a clear cut messages that those bits should not be in circulation and exist only for historic or education purposes and it can be forked and maintained elsewhere while the latter leaves it open to interpretation with an end result of wasting peoples contributed time ( package reviewers,releng, qa, reporters and eventually upstream community when that circle completes ) and reflect badly on the bits upstream community ( end user frustration, bad reviews, bad rep on set maintainers etc ) since someone will always get the bright idea of packaging the bit rotters and ship it in their distribution which leads to the previous mentioned end result. So even if you dont care, you should remember ifplugd and it's longevity in Fedora with the relevant TCE for the project after you had effectively seized to maintain it. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: list-units -r should not fail with older systemd in container
Lennart Poettering píše v Út 31. 03. 2015 v 19:28 +0200: On Tue, 31.03.15 16:10, Lukas Nykryn (lnyk...@redhat.com) wrote: Older version of systemd does not have d-bus method ListUnitsFiltered, so systemctl -r will fail just with: I think I'd really prefer if we'd simply fall back to ListUnits() in this case, and do the filtering client side only. In fact that's probably what we should have done in the first place anyway. I figure the patch to make this happen shouldn't be too complex, especially given that the original code did just that? Lennart I am not sure if I understand your suggestion correctly, fall back in the case that the machine does not haveListUnitsFiltered or basically revert the original patch, which changed that (but leave the new dbus method)? Lukas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH 1/2] libsystemd: add sd-device library
This provides equivalent functionality to libudev-device, but in the
systemd style. The public API only caters to creating sd_device objects
from for devices that already exist in /sys, there is no support for
listening for monitoring uevents or creating devices received over
the udev netlink protocol.
The private API contains the necessary functionality to make sd-device
a drop-in replacement for libudev-device, but which we will not export
publicly.
---
Hi guys,
This is another step on the way of ripping out the bits of libudev that will
still be useful once the udev netlink transport has been replaced by kdbus.
Feedback welcome.
Cheers,
Tom
Makefile.am|9 +-
src/libsystemd/sd-device/device-internal.h | 125 ++
src/libsystemd/sd-device/device-private.c | 1101 +
src/libsystemd/sd-device/device-private.h | 63 +
src/libsystemd/sd-device/device-util.h | 48 +
src/libsystemd/sd-device/sd-device.c | 1812
src/systemd/sd-device.h| 77 ++
7 files changed, 3234 insertions(+), 1 deletion(-)
create mode 100644 src/libsystemd/sd-device/device-internal.h
create mode 100644 src/libsystemd/sd-device/device-private.c
create mode 100644 src/libsystemd/sd-device/device-private.h
create mode 100644 src/libsystemd/sd-device/device-util.h
create mode 100644 src/libsystemd/sd-device/sd-device.c
create mode 100644 src/systemd/sd-device.h
diff --git a/Makefile.am b/Makefile.am
index 93fdbc2..9509247 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -231,6 +231,7 @@ AM_CPPFLAGS = \
-I $(top_srcdir)/src/libsystemd/sd-rtnl \
-I $(top_srcdir)/src/libsystemd/sd-network \
-I $(top_srcdir)/src/libsystemd/sd-hwdb \
+ -I $(top_srcdir)/src/libsystemd/sd-device \
-I $(top_srcdir)/src/libsystemd-network \
-I $(top_srcdir)/src/libsystemd-terminal \
$(OUR_CPPFLAGS)
@@ -2918,6 +2919,7 @@ libsystemd_internal_la_SOURCES = \
src/systemd/sd-path.h \
src/systemd/sd-network.h \
src/systemd/sd-hwdb.h \
+ src/systemd/sd-device.h \
src/libsystemd/sd-bus/sd-bus.c \
src/libsystemd/sd-bus/bus-control.c \
src/libsystemd/sd-bus/bus-control.h \
@@ -2981,7 +2983,12 @@ libsystemd_internal_la_SOURCES = \
src/libsystemd/sd-network/network-util.c \
src/libsystemd/sd-hwdb/sd-hwdb.c \
src/libsystemd/sd-hwdb/hwdb-util.h \
- src/libsystemd/sd-hwdb/hwdb-internal.h
+ src/libsystemd/sd-hwdb/hwdb-intenal.h \
+ src/libsystemd/sd-device/device-internal.h \
+ src/libsystemd/sd-device/device-util.h \
+ src/libsystemd/sd-device/sd-device.c \
+ src/libsystemd/sd-device/device-private.c \
+ src/libsystemd/sd-device/device-private.h
nodist_libsystemd_internal_la_SOURCES = \
src/libsystemd/libsystemd.sym
diff --git a/src/libsystemd/sd-device/device-internal.h
b/src/libsystemd/sd-device/device-internal.h
new file mode 100644
index 000..59ec1a6
--- /dev/null
+++ b/src/libsystemd/sd-device/device-internal.h
@@ -0,0 +1,125 @@
+/***
+ This file is part of systemd.
+
+ Copyright 2008-2012 Kay Sievers k...@vrfy.org
+ Copyright 2014 Tom Gundersen t...@jklm.no
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#pragma once
+
+#include hashmap.h
+#include set.h
+
+struct sd_device {
+uint64_t n_ref;
+
+sd_device *parent;
+bool parent_set; /* no need to try to reload parent */
+
+OrderedHashmap *properties;
+Iterator properties_iterator;
+uint64_t properties_generation; /* changes whenever the properties are
changed */
+uint64_t properties_iterator_generation; /* generation when iteration
was started */
+
+/* the subset of the properties that should be written to the db*/
+OrderedHashmap *properties_db;
+
+Hashmap *sysattr_values; /* cached sysattr values */
+
+Set *sysattrs; /* names of sysattrs */
+Iterator sysattrs_iterator;
+bool sysattrs_read; /* don't try to re-read sysattrs once read */
+
+Set *tags;
+Iterator tags_iterator;
+uint64_t tags_generation; /* changes whenever the tags are changed */
+uint64_t tags_iterator_generation; /* generation when iteration was
started */
+bool property_tags_outdated; /* need to update
[systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
Creating subvolumes in chrooted environments makes them undeletable and breaks mock. https://bugzilla.redhat.com/show_bug.cgi?id=1205564 Jan Synacek (1): tmpfiles: don't create subvolumes in chroot src/tmpfiles/tmpfiles.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
---
src/tmpfiles/tmpfiles.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1099,9 +1099,15 @@ static int create_item(Item *i) {
break;
+case CREATE_SUBVOLUME:
+
+/* Don't create subvolumes in chrooted environments. */
+if (running_in_chroot())
+break;
+/* FALLTHROUGH */
+
case CREATE_DIRECTORY:
case TRUNCATE_DIRECTORY:
-case CREATE_SUBVOLUME:
RUN_WITH_UMASK()
mkdir_parents_label(i-path, 0755);
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 04/01/2015 12:33 PM, Jan Synacek wrote:
---
src/tmpfiles/tmpfiles.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1099,9 +1099,15 @@ static int create_item(Item *i) {
break;
+case CREATE_SUBVOLUME:
+
+/* Don't create subvolumes in chrooted environments. */
+if (running_in_chroot())
+break;
+/* FALLTHROUGH */
+
case CREATE_DIRECTORY:
case TRUNCATE_DIRECTORY:
-case CREATE_SUBVOLUME:
RUN_WITH_UMASK()
mkdir_parents_label(i-path, 0755);
This breakage is not limited to chroot, subvolumes should not be created
et all.
Just file a patch that replace v for d for the /var/lib/machines entry
in /usr/lib/tmpfiles.d/var.conf which you are undoubtedly trying to fix
here since it breaks among other things mock.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH 2/2] libudev: device - replace by a thin wrapper around sd-device
--- Makefile.am | 33 +- src/libudev/libudev-device-internal.h | 62 ++ src/libudev/libudev-device-private.c | 511 +++--- src/libudev/libudev-device.c | 1808 ++--- 4 files changed, 779 insertions(+), 1635 deletions(-) create mode 100644 src/libudev/libudev-device-internal.h diff --git a/Makefile.am b/Makefile.am index 9509247..1b64b62 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2144,6 +2144,7 @@ systemd_shutdown_SOURCES = \ systemd_shutdown_LDADD = \ libsystemd-label.la \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la # -- @@ -2345,6 +2346,7 @@ systemd_fsck_SOURCES = \ systemd_fsck_LDADD = \ libsystemd-internal.la \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la # -- @@ -2380,6 +2382,7 @@ systemd_ac_power_SOURCES = \ systemd_ac_power_LDADD = \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la # -- @@ -2651,8 +2654,8 @@ systemd_gpt_auto_generator_SOURCES = \ systemd_gpt_auto_generator_LDADD = \ libsystemd-label.la \ - libsystemd-internal.la \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la \ $(BLKID_LIBS) @@ -2804,8 +2807,8 @@ systemd_nspawn_CFLAGS = \ systemd_nspawn_LDADD = \ libsystemd-label.la \ - libsystemd-internal.la \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la \ $(BLKID_LIBS) @@ -3618,10 +3621,12 @@ lib_LTLIBRARIES += \ libudev_la_SOURCES =\ src/libudev/libudev.sym \ src/libudev/libudev-private.h \ + src/libudev/libudev-device-internal.h \ src/libudev/libudev.c \ src/libudev/libudev-list.c \ src/libudev/libudev-util.c \ src/libudev/libudev-device.c \ + src/libudev/libudev-device-private.c \ src/libudev/libudev-enumerate.c \ src/libudev/libudev-monitor.c \ src/libudev/libudev-queue.c \ @@ -3673,8 +3678,7 @@ noinst_LTLIBRARIES += \ libudev-internal.la libudev_internal_la_SOURCES =\ - $(libudev_la_SOURCES) \ - src/libudev/libudev-device-private.c + $(libudev_la_SOURCES) libudev_internal_la_CFLAGS = \ $(AM_CFLAGS) \ @@ -3859,9 +3863,9 @@ systemd_hwdb_SOURCES = \ src/hwdb/hwdb.c systemd_hwdb_LDADD = \ + libudev-internal.la \ libsystemd-shared.la \ - libsystemd-internal.la \ - libudev-internal.la + libsystemd-internal.la rootbin_PROGRAMS += \ systemd-hwdb @@ -3971,6 +3975,7 @@ ata_id_SOURCES = \ ata_id_LDADD = \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la udevlibexec_PROGRAMS += \ @@ -3982,6 +3987,7 @@ cdrom_id_SOURCES = \ cdrom_id_LDADD = \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la udevlibexec_PROGRAMS += \ @@ -3996,6 +4002,7 @@ collect_SOURCES = \ collect_LDADD = \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la udevlibexec_PROGRAMS += \ @@ -4010,6 +4017,7 @@ scsi_id_SOURCES =\ scsi_id_LDADD = \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la udevlibexec_PROGRAMS += \ @@ -4024,6 +4032,7 @@ v4l_id_SOURCES = \ v4l_id_LDADD = \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la udevlibexec_PROGRAMS += \ @@ -4038,6 +4047,7 @@ accelerometer_SOURCES = \ accelerometer_LDADD = \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la udevlibexec_PROGRAMS += \ @@ -4937,6 +4947,7 @@ systemd_backlight_SOURCES = \ systemd_backlight_LDADD = \ libsystemd-label.la \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la endif @@ -4957,6 +4968,7 @@ systemd_rfkill_SOURCES = \ systemd_rfkill_LDADD = \ libsystemd-label.la \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la endif @@ -4985,6 +4997,7 @@ systemd_cryptsetup_CFLAGS = \ systemd_cryptsetup_LDADD = \ libsystemd-label.la \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la \ $(LIBCRYPTSETUP_LIBS) @@ -5280,8 +5293,8 @@ libsystemd_machine_core_la_SOURCES = \ libsystemd_machine_core_la_LIBADD = \ libsystemd-label.la \ - libsystemd-internal.la \ libudev-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la noinst_LTLIBRARIES += \ @@ -5797,8 +5810,8 @@ networkctl_SOURCES = \
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 12:40, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1099,9 +1099,15 @@ static int create_item(Item *i) {
break;
+case CREATE_SUBVOLUME:
+
+/* Don't create subvolumes in chrooted environments. */
+if (running_in_chroot())
+break;
+/* FALLTHROUGH */
+
case CREATE_DIRECTORY:
case TRUNCATE_DIRECTORY:
-case CREATE_SUBVOLUME:
RUN_WITH_UMASK()
mkdir_parents_label(i-path, 0755);
This breakage is not limited to chroot, subvolumes should not be created et
all.
Why not?
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] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 14:33, Jan Synacek (jsyna...@redhat.com) wrote: Creating subvolumes in chrooted environments makes them undeletable and breaks mock. Humm, I am not convinced that this is a good idea. The chroot environments are hardly undeletable, they just require you to delete them explicitly. There's work going on to tech btrfs-progs recursive deleting of subvolumes. I am pretty sure that's the right fix and mock should really be updated to deal with that... I am also against this since chrooting is an implementation detail of mock, nothing more, and the fact that mock's recursive deletion logic cannot handle removal of subvolumes is not directly connected to the fact that mock uses chroot. Sorry, but we need to find a different solution for this. Maybe mock should use seccomp to make the subvolume creation ioctls unavailable, or it should be updated to deal with subvolumes properly. 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] tmpfiles: don't create subvolumes in chroot
On 04/01/2015 01:04 PM, Lennart Poettering wrote:
On Wed, 01.04.15 12:40, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 494fd1a..9280fd7 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1099,9 +1099,15 @@ static int create_item(Item *i) {
break;
+case CREATE_SUBVOLUME:
+
+/* Don't create subvolumes in chrooted environments. */
+if (running_in_chroot())
+break;
+/* FALLTHROUGH */
+
case CREATE_DIRECTORY:
case TRUNCATE_DIRECTORY:
-case CREATE_SUBVOLUME:
RUN_WITH_UMASK()
mkdir_parents_label(i-path, 0755);
This breakage is not limited to chroot, subvolumes should not be created et
all.
Why not?
Because you break factory,stateless,reproducible,verifiable, mock and
variety of servers setups with enterprise storage of any kind that uses
btrfs ( and whatever else 'v' switch might support in the future ).
( Prime example that covers a lot of usecase where this breaks on btrfs
/var/lib/machines )
Let's leave it up to vendor and downstream distributions to make an
enlighten choice of turning the 'v' feature on after careful
consideration and creating relevant documentation instead of breaking
for them and have every distributions patching this feature out for
example because they suddenly found themselves in a pile of bug reports
because users could not delete those directories in the traditional
manner they had expected ( rm ) but had to magically discover they will
have to use the relevant subvolume removal command for the file system
in question on those directories that it had been enabled on .
Bottom line upstream default should always be 'd' as in create a
directory if it does not exist yet, never v as in create a subvolume if
the path does not exist yet and the file system supports it.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 204 to 215 (Debian version) fails to recognize that LVM2 device nodes are already present and accessible
On Sun, 29.03.15 20:42, Dominik Brodowski (li...@dominikbrodowski.net) wrote: Dear systemd developers, In my custom initramfs, lvm vgmknodes successfully creates the device nodes for /dev/vg0/home and /dev/vg0/swap . On current sytemd/udev systems device nodes are created via devtmpfs by the kernel, userspace does not create them. A command like lvm vgmknodes creates device nodes, right? It is hence obsolete. In general, please direct LVM questions to the LVM project, it's not our area of expertise. However, /home is left unmounted and swap is still off. Then, after handing business over to systemd (with /dev re-mounted), and after some services are activated successfully, systemd enters an emergency shell: The (autogenerated) systemd-cryptsetup@home.service and systemd-cryptsetup@swap.service want dev-vg0-home.device and dev-vg0-swap.device to be ready, but $ systemctl status dev-vg0-home.device and $ systemctl status dev-vg0-swap.device show they are inactive -- even though the device nodes at /dev/vg0/home and /dev/vg0/swap actually exists and are working! Well, if you create device nodes on your own, without involvement of the kernel, and without them being announced via the kernel/udev, then systemd will not know about them. Either way, I figure you need to ask Debian downstream and LVM for help about 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] [PATCH] systemctl: list-units -r should not fail with older systemd in container
On 1 April 2015 at 13:44, Lukáš Nykrýn lnyk...@redhat.com wrote: Lennart Poettering píše v Út 31. 03. 2015 v 19:28 +0200: On Tue, 31.03.15 16:10, Lukas Nykryn (lnyk...@redhat.com) wrote: Older version of systemd does not have d-bus method ListUnitsFiltered, so systemctl -r will fail just with: I think I'd really prefer if we'd simply fall back to ListUnits() in this case, and do the filtering client side only. In fact that's probably what we should have done in the first place anyway. I figure the patch to make this happen shouldn't be too complex, especially given that the original code did just that? Lennart I am not sure if I understand your suggestion correctly, fall back in the case that the machine does not haveListUnitsFiltered or basically revert the original patch, which changed that (but leave the new dbus method)? Keep current code path as default, if ListUnitsFiltered is available. Revert old code path, but make it a fallback code path when ListUnitsFiltered is not available. -- Regards, Dimitri. https://clearlinux.org Open Source Technology Center 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] systemctl: list-units -r should not fail with older systemd in container
On Wed, 01.04.15 14:44, Lukáš Nykrýn (lnyk...@redhat.com) wrote: Lennart Poettering píše v Út 31. 03. 2015 v 19:28 +0200: On Tue, 31.03.15 16:10, Lukas Nykryn (lnyk...@redhat.com) wrote: Older version of systemd does not have d-bus method ListUnitsFiltered, so systemctl -r will fail just with: I think I'd really prefer if we'd simply fall back to ListUnits() in this case, and do the filtering client side only. In fact that's probably what we should have done in the first place anyway. I figure the patch to make this happen shouldn't be too complex, especially given that the original code did just that? Lennart I am not sure if I understand your suggestion correctly, fall back in the case that the machine does not haveListUnitsFiltered or basically revert the original patch, which changed that (but leave the new dbus method)? A runtime fallback from ListUnitsFiltered() to old ListUnits() should the former result in an error that the method call is unavailable. 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] macro: allow assert_se() assertions to also be optimized when NDEBUG is set
On Tue, 31.03.15 11:09, Shawn Landden (sh...@churchofgit.com) wrote: On Mon, Mar 30, 2015 at 8:24 PM, Shawn Landden sh...@churchofgit.com wrote: replaces log with abort() to remove strings. saves 3kB from text section of systemd. and 7kB from rodata. The saving in text is probably because abort() is no_return. I am sorry, but we don't really optimize 10K 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] systemd not in a steady state, although system is fine.
On Tue, 31.03.15 00:46, kenneth topp (to...@bllue.org) wrote: Ð Mon, 30 Mar 2015 19:35:21 -0400 kenneth topp to...@bllue.org пиÑеÑ: Hi, My system appears healthy, but for some reason systemd not in a good state. From the commands and their output, I have two concerns. 1) why is the state starting and not finished? 2) what are these jobs that are running? systemctl list-jobs Hi, Thanks, I see these jobs, I just don't know why the jobs are running. They don't seem to be doing anything, and the unit doesn't offer any clue, and the block device is up. ken [root@static ~]# systemctl list-jobs JOB UNIT TYPE STATE 208 dev-mapper-hp22.cfs.device start running 205 dev-mapper-hp27.cfs.device start running 199 dev-mapper-hp29.cfs.device start running 196 dev-mapper-hp30.cfs.device start running Most likely those devices never show up properly? Most likely an LVM/DM problem. Please check with udevadm info /dev/mapper/hp22.cfs if the device showed up properly in kernel/udev and carries the systemd udev tag. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-run and waiting for initialization
On Mon, 30.03.15 09:48, Igor Bukanov (i...@mir2.org) wrote: As I understand, the systemd-run utility returns immediately even with --service-type=forking. What is the proper way then to wait using a shell until the main service process forks the child and exists signaling initialization? THis is currently not supported, but it certainly would make sense to support this. Added to the TODO list. 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] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 15:45, Jan Synacek (jsyna...@redhat.com) wrote: I am also against this since chrooting is an implementation detail of mock, nothing more, and the fact that mock's recursive deletion logic cannot handle removal of subvolumes is not directly connected to the fact that mock uses chroot. Sorry, but we need to find a different solution for this. Maybe mock should use seccomp to make the subvolume creation ioctls unavailable, or it should be updated to deal with subvolumes properly. I agree that mock should be enhanced to cope with subvolumes, but I also think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? But why do you say when it doesn't make sense? Why do you think this doesn't make sense... 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] tmpfiles: don't create subvolumes in chroot
Lennart Poettering lenn...@poettering.net writes: On Wed, 01.04.15 14:33, Jan Synacek (jsyna...@redhat.com) wrote: Creating subvolumes in chrooted environments makes them undeletable and breaks mock. Humm, I am not convinced that this is a good idea. The chroot environments are hardly undeletable, they just require you to delete them explicitly. There's work going on to tech btrfs-progs recursive deleting of subvolumes. I am pretty sure that's the right fix and mock should really be updated to deal with that... undeletable was a bad wording from my side, sorry for that. What I really meant is that mock simply couldn't deal with it... I am also against this since chrooting is an implementation detail of mock, nothing more, and the fact that mock's recursive deletion logic cannot handle removal of subvolumes is not directly connected to the fact that mock uses chroot. Sorry, but we need to find a different solution for this. Maybe mock should use seccomp to make the subvolume creation ioctls unavailable, or it should be updated to deal with subvolumes properly. I agree that mock should be enhanced to cope with subvolumes, but I also think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
Lennart Poettering [2015-04-01 15:48 +0200]:
But why do you say when it doesn't make sense? Why do you think this
doesn't make sense...
As someone who has added hideous workarounds like
| # old rootfs might contain btrfs subvolumes, remove them
| subvols=$(btrfs subvolume list -o $LXCDIR/${NAME}/rootfs.old 2/dev/null |
awk /\/rootfs.old/ {print \$(NF)}) || true
| for vol in $subvols; do
| btrfs subvolume delete /${vol#@}
| done
| rm -rf $LXCDIR/${NAME}/rootfs.old
several times to a project of mine (autopkgtest), and keeps finding
more in e. g. LXC, I must say I agree that creating subvolumes in
things like chroots or LXC containers etc. makes very little sense to
me too. I vaguely see how it's useful for the host's
/var/lib/machines/, but for temporary/guest systemd instances like
chroot or LXC it's nothing but a nuisance.
IMHO subvolumes, like hard disk partitions, are something that the
administrator of a host should create deliberately only. Automatically
created ones just create confusion about why the heck can't I remove
that directory.. It's roughly equivalent of some random package
messing with your partitions and/or fstab.
So if we could somehow make this conditional on running on real
iron, that would be a good compromise IMHO.
(I don't have a strong enough opinion to start a real fight here, but
at least chalking up my vote)
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 16:02, Martin Pitt (martin.p...@ubuntu.com) wrote:
Lennart Poettering [2015-04-01 15:48 +0200]:
But why do you say when it doesn't make sense? Why do you think this
doesn't make sense...
As someone who has added hideous workarounds like
| # old rootfs might contain btrfs subvolumes, remove them
| subvols=$(btrfs subvolume list -o $LXCDIR/${NAME}/rootfs.old 2/dev/null |
awk /\/rootfs.old/ {print \$(NF)}) || true
| for vol in $subvols; do
| btrfs subvolume delete /${vol#@}
| done
| rm -rf $LXCDIR/${NAME}/rootfs.old
several times to a project of mine (autopkgtest), and keeps finding
more in e. g. LXC, I must say I agree that creating subvolumes in
things like chroots or LXC containers etc. makes very little sense to
me too. I vaguely see how it's useful for the host's
/var/lib/machines/, but for temporary/guest systemd instances like
chroot or LXC it's nothing but a nuisance.
Again, this is being worked on on the btrfs side:
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg42476.html
IMHO subvolumes, like hard disk partitions, are something that the
administrator of a host should create deliberately only. Automatically
created ones just create confusion about why the heck can't I remove
that directory.. It's roughly equivalent of some random package
messing with your partitions and/or fstab.
Well, it's a full OS container you ran there, not some arbitrary
thing.
btrfs subvolumes are going to become more common in the future, not
less common. If you put together a container manager you need to deal
with it sooner or later, and systemd is not going to be the only user
of this.
I will add recursive btrfs subvolume removal to machined, and I am
very sure LXC should do the same.
Note that I intend to add more subvolume lines to tmpfiles even. For
example, I am pretty sure /home should be created as subvolume if it
doesn't exist already, and similar.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH] udev: net_id - support multi-function, multi-port enpo* device names
I'd argue that having firmware labels for such devices makes no sense, but they
exist, so make sure
we handle them as best as we can.
---
src/udev/udev-builtin-net_id.c | 64 --
1 file changed, 43 insertions(+), 21 deletions(-)
diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index 71f3a59..1a72190 100644
--- a/src/udev/udev-builtin-net_id.c
+++ b/src/udev/udev-builtin-net_id.c
@@ -35,7 +35,7 @@
* Type of names:
* bnumber -- BCMA bus core number
* ccwname -- CCW bus group name
- * oindex -- on-board device index number
+ * oindex[ffunction][ddev_port]-- on-board device index number
* sslot[ffunction][ddev_port] -- hotplug slot index number
* xMAC-- MAC address
* [Pdomain]pbussslot[ffunction][ddev_port]
@@ -126,11 +126,38 @@ struct netnames {
char ccw_group[IFNAMSIZ];
};
+/* read the 256 bytes PCI configuration space to check the multi-function bit
*/
+static bool is_pci_multifunction(struct udev_device *dev) {
+_cleanup_fclose_ FILE *f = NULL;
+const char *filename;
+uint8_t config[64];
+
+filename = strjoina(udev_device_get_syspath(dev), /config);
+f = fopen(filename, re);
+if (!f)
+return false;
+if (fread(config, sizeof(config), 1, f) != 1)
+return false;
+
+/* bit 0-6 header type, bit 7 multi/single function device */
+if ((config[PCI_HEADER_TYPE] 0x80) != 0)
+return true;
+
+return false;
+}
+
/* retrieve on-board index number and label from firmware */
static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) {
+unsigned func, dev_port = 0;
+size_t l;
+char *s;
+const char *attr;
const char *index;
int idx;
+if (sscanf(udev_device_get_sysname(names-pcidev), %*x:%*x:%*x.%u,
func) != 1)
+return -ENOENT;
+
/* ACPI _DSM -- device specific method for naming a PCI or PCI
Express device */
index = udev_device_get_sysattr_value(names-pcidev, acpi_index);
/* SMBIOS type 41 -- Onboard Devices Extended Information */
@@ -141,30 +168,25 @@ static int dev_pci_onboard(struct udev_device *dev,
struct netnames *names) {
idx = strtoul(index, NULL, 0);
if (idx = 0)
return -EINVAL;
-snprintf(names-pci_onboard, sizeof(names-pci_onboard), o%d, idx);
-names-pci_onboard_label =
udev_device_get_sysattr_value(names-pcidev, label);
-return 0;
-}
-
-/* read the 256 bytes PCI configuration space to check the multi-function bit
*/
-static bool is_pci_multifunction(struct udev_device *dev) {
-_cleanup_fclose_ FILE *f = NULL;
-const char *filename;
-uint8_t config[64];
+/* kernel provided multi-device index */
+attr = udev_device_get_sysattr_value(dev, dev_port);
+if (attr)
+dev_port = strtol(attr, NULL, 10);
-filename = strjoina(udev_device_get_syspath(dev), /config);
-f = fopen(filename, re);
-if (!f)
-return false;
-if (fread(config, sizeof(config), 1, f) != 1)
-return false;
+s = names-pci_onboard;
+l = sizeof(names-pci_onboard);
+l = strpcpyf(s, l, o%d, idx);
+if (func 0 || is_pci_multifunction(names-pcidev))
+l = strpcpyf(s, l, f%d, func);
+if (dev_port 0)
+l = strpcpyf(s, l, d%d, dev_port);
+if (l == 0)
+names-pci_onboard[0] = '\0';
-/* bit 0-6 header type, bit 7 multi/single function device */
-if ((config[PCI_HEADER_TYPE] 0x80) != 0)
-return true;
+names-pci_onboard_label =
udev_device_get_sysattr_value(names-pcidev, label);
-return false;
+return 0;
}
static int dev_pci_slot(struct udev_device *dev, struct netnames *names) {
--
2.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH 1/2] libsystemd: add sd-device library
After discussing this with Kay, I went ahead and pushed this. Feedback
still welcome of course.
Cheers,
Tom
On Wed, Apr 1, 2015 at 3:00 PM, Tom Gundersen t...@jklm.no wrote:
This provides equivalent functionality to libudev-device, but in the
systemd style. The public API only caters to creating sd_device objects
from for devices that already exist in /sys, there is no support for
listening for monitoring uevents or creating devices received over
the udev netlink protocol.
The private API contains the necessary functionality to make sd-device
a drop-in replacement for libudev-device, but which we will not export
publicly.
---
Hi guys,
This is another step on the way of ripping out the bits of libudev that will
still be useful once the udev netlink transport has been replaced by kdbus.
Feedback welcome.
Cheers,
Tom
Makefile.am|9 +-
src/libsystemd/sd-device/device-internal.h | 125 ++
src/libsystemd/sd-device/device-private.c | 1101 +
src/libsystemd/sd-device/device-private.h | 63 +
src/libsystemd/sd-device/device-util.h | 48 +
src/libsystemd/sd-device/sd-device.c | 1812
src/systemd/sd-device.h| 77 ++
7 files changed, 3234 insertions(+), 1 deletion(-)
create mode 100644 src/libsystemd/sd-device/device-internal.h
create mode 100644 src/libsystemd/sd-device/device-private.c
create mode 100644 src/libsystemd/sd-device/device-private.h
create mode 100644 src/libsystemd/sd-device/device-util.h
create mode 100644 src/libsystemd/sd-device/sd-device.c
create mode 100644 src/systemd/sd-device.h
diff --git a/Makefile.am b/Makefile.am
index 93fdbc2..9509247 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -231,6 +231,7 @@ AM_CPPFLAGS = \
-I $(top_srcdir)/src/libsystemd/sd-rtnl \
-I $(top_srcdir)/src/libsystemd/sd-network \
-I $(top_srcdir)/src/libsystemd/sd-hwdb \
+ -I $(top_srcdir)/src/libsystemd/sd-device \
-I $(top_srcdir)/src/libsystemd-network \
-I $(top_srcdir)/src/libsystemd-terminal \
$(OUR_CPPFLAGS)
@@ -2918,6 +2919,7 @@ libsystemd_internal_la_SOURCES = \
src/systemd/sd-path.h \
src/systemd/sd-network.h \
src/systemd/sd-hwdb.h \
+ src/systemd/sd-device.h \
src/libsystemd/sd-bus/sd-bus.c \
src/libsystemd/sd-bus/bus-control.c \
src/libsystemd/sd-bus/bus-control.h \
@@ -2981,7 +2983,12 @@ libsystemd_internal_la_SOURCES = \
src/libsystemd/sd-network/network-util.c \
src/libsystemd/sd-hwdb/sd-hwdb.c \
src/libsystemd/sd-hwdb/hwdb-util.h \
- src/libsystemd/sd-hwdb/hwdb-internal.h
+ src/libsystemd/sd-hwdb/hwdb-intenal.h \
+ src/libsystemd/sd-device/device-internal.h \
+ src/libsystemd/sd-device/device-util.h \
+ src/libsystemd/sd-device/sd-device.c \
+ src/libsystemd/sd-device/device-private.c \
+ src/libsystemd/sd-device/device-private.h
nodist_libsystemd_internal_la_SOURCES = \
src/libsystemd/libsystemd.sym
diff --git a/src/libsystemd/sd-device/device-internal.h
b/src/libsystemd/sd-device/device-internal.h
new file mode 100644
index 000..59ec1a6
--- /dev/null
+++ b/src/libsystemd/sd-device/device-internal.h
@@ -0,0 +1,125 @@
+/***
+ This file is part of systemd.
+
+ Copyright 2008-2012 Kay Sievers k...@vrfy.org
+ Copyright 2014 Tom Gundersen t...@jklm.no
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#pragma once
+
+#include hashmap.h
+#include set.h
+
+struct sd_device {
+uint64_t n_ref;
+
+sd_device *parent;
+bool parent_set; /* no need to try to reload parent */
+
+OrderedHashmap *properties;
+Iterator properties_iterator;
+uint64_t properties_generation; /* changes whenever the properties
are changed */
+uint64_t properties_iterator_generation; /* generation when
iteration was started */
+
+/* the subset of the properties that should be written to the db*/
+OrderedHashmap *properties_db;
+
+Hashmap *sysattr_values; /* cached sysattr values */
+
+Set *sysattrs; /* names of sysattrs */
+Iterator sysattrs_iterator;
+bool sysattrs_read; /* don't try to re-read sysattrs
[systemd-devel] Synchronization Between Services at Shutdown
Hello folks, I am trying to ensure that my system DBus service has time to handle a DBus method call before it shuts down. My DBus service is implemented as a system systemd service; let's call it service A. It runs a single-threaded, synchronous event loop that listens for DBus method calls and handles them appropriately. This event loop also listens for SIGTERM. When SIGTERM is received, service A currently terminates the event loop, performs any necessary writes to disk, and releases its resources. I am assuming that when the system is shut down cleanly, systemd initially sends SIGTERM to systemd services and only sends SIGKILL to abort it abruptly if it takes too long to shut down when asked nicely. I have another system systemd service, call it service B, that runs an event loop listening for SIGTERM. When service B receives a SIGTERM, it makes the aforementioned DBus method call and then flushes the system bus. Service B specifies Requires= http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=Service A and After= http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=Service A. Service A makes no mention of service B in its unit configuration file. Does systemd make any sort of guarantee that service A will get a chance to handle the DBus method call before receiving SIGTERM, or does my code as written have a race condition? Be well, Kurt -- Kurt von Laven | Endless Mobile | 732.784.7356 | EndlessM.com http://endlessm.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Synchronization Between Services at Shutdown
В Wed, 1 Apr 2015 18:22:50 -0700 Kurt von Laven k...@endlessm.com пишет: Hello folks, I am trying to ensure that my system DBus service has time to handle a DBus method call before it shuts down. My DBus service is implemented as a system systemd service; let's call it service A. It runs a single-threaded, synchronous event loop that listens for DBus method calls and handles them appropriately. This event loop also listens for SIGTERM. When SIGTERM is received, service A currently terminates the event loop, performs any necessary writes to disk, and releases its resources. I am assuming that when the system is shut down cleanly, systemd initially sends SIGTERM to systemd services and only sends SIGKILL to abort it abruptly if it takes too long to shut down when asked nicely. I have another system systemd service, call it service B, that runs an event loop listening for SIGTERM. When service B receives a SIGTERM, it makes the aforementioned DBus method call and then flushes the system bus. Service B specifies Requires= http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=Service A and After= http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=Service A. Service A makes no mention of service B in its unit configuration file. Does systemd make any sort of guarantee that service A will get a chance to handle the DBus method call before receiving SIGTERM, or does my code as written have a race condition? systemd will not initiate stopping of A before B has stopped. If it does, this should be considered a bug. So it is up to service B to handle termination correctly. Note that systemd will send SIGKILL after timeout if service has not terminated. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote:
Hi all-
When running virtme (a simple vm gadget) on Fedora 21, the slowest
part of bootup by far appears to be systemd-vconsole-setup:
# time /usr/lib/systemd/systemd-vconsole-setup
putfont: PIO_FONT trying ...
...
setfont: putfont: 512,8x16: failed: -1
putfont: PIO_FONT: Invalid argument
/usr/bin/setfont failed with error code 71.
setfont is not part of systemd, we just invoke it. If that fails, this
is a problem somewhere between the VM, the kernel and console-tools.
Aha -- I missed that systemd-vconsole-setup calls setfont. I can
trigger the same problem by just typing setfont. For whatever reason,
my other Fedora 21 computer only has this problem if I type setfont
and not if I run systemd-vconcole-setup.
My uneducated guess is that your virtual machine boots up with a
non-graphical console, and the tool thus tries to upload the fonts
into the good old VGA hw text mode glyph tables, and qemu is very slow
at that... Or something like that.
setfont is doing this:
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
This thing has only a serial console:
# cat /proc/consoles
ttyS0-W- (EC a)4:64
setfont does this:
/* we allow ourselves to hang here for ca 5 seconds, xdm may
be playing tricks on us. */
while ((loop++ 20) (i = ioctl(fd, PIO_FONT, buf)))
{
if (loop = 1)
fprintf(stderr, putfont: PIO_FONT trying ...\n);
else
fprintf(stderr, .);
usleep(25);
}
fprintf(stderr, \n);
Alexey, would it make sense to remove this loop or to add a way to turn it
off?
Ping, everyone?
This issue still exists. AFAICT systemd is relying on a really old
tool, that that really old tool (setfont) is sometimes delaying boot
by a very large amount. Can we either fix the tool (Alexey) or stop
using it (systemd people)?
--Andy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote:
Hi all-
When running virtme (a simple vm gadget) on Fedora 21, the slowest
part of bootup by far appears to be systemd-vconsole-setup:
# time /usr/lib/systemd/systemd-vconsole-setup
putfont: PIO_FONT trying ...
...
setfont: putfont: 512,8x16: failed: -1
putfont: PIO_FONT: Invalid argument
/usr/bin/setfont failed with error code 71.
setfont is not part of systemd, we just invoke it. If that fails, this
is a problem somewhere between the VM, the kernel and console-tools.
Aha -- I missed that systemd-vconsole-setup calls setfont. I can
trigger the same problem by just typing setfont. For whatever reason,
my other Fedora 21 computer only has this problem if I type setfont
and not if I run systemd-vconcole-setup.
My uneducated guess is that your virtual machine boots up with a
non-graphical console, and the tool thus tries to upload the fonts
into the good old VGA hw text mode glyph tables, and qemu is very slow
at that... Or something like that.
setfont is doing this:
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
This thing has only a serial console:
# cat /proc/consoles
ttyS0-W- (EC a)4:64
setfont does this:
/* we allow ourselves to hang here for ca 5 seconds, xdm may
be playing tricks on us. */
while ((loop++ 20) (i = ioctl(fd, PIO_FONT, buf)))
{
if (loop = 1)
fprintf(stderr, putfont: PIO_FONT trying ...\n);
else
fprintf(stderr, .);
usleep(25);
}
fprintf(stderr, \n);
Alexey, would it make sense to remove this loop or to add a way to turn it
off?
Ping, everyone?
This issue still exists. AFAICT systemd is relying on a really old
tool, that that really old tool (setfont) is sometimes delaying boot
by a very large amount. Can we either fix the tool (Alexey) or stop
using it (systemd people)?
Hmm, why is the vm gadget you run configuring a custom console font
at all? If there is no custom font specified in t he config, systemd
will not run setfont.
Or did you mean to have vconsole-setup detect that it should not even
try to run setfont? Not sure how to find that out.
I don't really see how vconsole-setup could get rid of calling setfont
from systemd, it is needed in many setups.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers k...@vrfy.org wrote:
On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote:
Hi all-
When running virtme (a simple vm gadget) on Fedora 21, the slowest
part of bootup by far appears to be systemd-vconsole-setup:
# time /usr/lib/systemd/systemd-vconsole-setup
putfont: PIO_FONT trying ...
...
setfont: putfont: 512,8x16: failed: -1
putfont: PIO_FONT: Invalid argument
/usr/bin/setfont failed with error code 71.
setfont is not part of systemd, we just invoke it. If that fails, this
is a problem somewhere between the VM, the kernel and console-tools.
Aha -- I missed that systemd-vconsole-setup calls setfont. I can
trigger the same problem by just typing setfont. For whatever reason,
my other Fedora 21 computer only has this problem if I type setfont
and not if I run systemd-vconcole-setup.
My uneducated guess is that your virtual machine boots up with a
non-graphical console, and the tool thus tries to upload the fonts
into the good old VGA hw text mode glyph tables, and qemu is very slow
at that... Or something like that.
setfont is doing this:
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
This thing has only a serial console:
# cat /proc/consoles
ttyS0-W- (EC a)4:64
setfont does this:
/* we allow ourselves to hang here for ca 5 seconds, xdm may
be playing tricks on us. */
while ((loop++ 20) (i = ioctl(fd, PIO_FONT, buf)))
{
if (loop = 1)
fprintf(stderr, putfont: PIO_FONT trying ...\n);
else
fprintf(stderr, .);
usleep(25);
}
fprintf(stderr, \n);
Alexey, would it make sense to remove this loop or to add a way to turn it
off?
Ping, everyone?
This issue still exists. AFAICT systemd is relying on a really old
tool, that that really old tool (setfont) is sometimes delaying boot
by a very large amount. Can we either fix the tool (Alexey) or stop
using it (systemd people)?
Hmm, why is the vm gadget you run configuring a custom console font
at all? If there is no custom font specified in t he config, systemd
will not run setfont.
It's not intentionally configuring a custom font, but it might be
inheriting Fedora's settings.
Or did you mean to have vconsole-setup detect that it should not even
try to run setfont? Not sure how to find that out.
I don't really see how vconsole-setup could get rid of calling setfont
from systemd, it is needed in many setups.
vconsole-setup could set the font itself instead of using setfont if
setfont can't be configured or fixed not to keep retrying for five
seconds (!).
Ideally, I think that setfont would just stop retrying on failure. Or
perhaps all of this could go through udev or some other mechanism that
doesn't try to set the font until the device actually exists. But the
console system is weird and may be that's hard.
--Andy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC/PATCH] journalctl: Improve boot ID lookup
This method shouldn't provide any noticeable speedup for the --list-boots
case, but any offset based lookup should be greatly improved.
We now don't have to aggregate the full boot listing just so we can jump
to specific position, which can be a real pain on big journals just for
a mere -b -1 case.
--list-boots might get a little slower, but not by much. And keeping
--boot and --list-boots' idea of boots consistent should justify the slight
increase.
Note that there can be a change in boot order in this --list-boots version
because it will use the order of boots in journals, not the realtime stamp
stored in them. That's arguably better, though.
https://bugs.freedesktop.org/show_bug.cgi?id=72601
---
Hi,
I can't believe I didn't come up with this one sooner. The details how it works
are in the comments, but I could use some testing by people who have tons of
boots in their journal. I only have 58, which doesn't make --boot -1 that big a
pain, but I still do get an improvement: ~2s without and ~0s lookup with this
patch
applied (using /proc/sys/vm/drop_caches of course).
The patch could use some testing/timing with huge journals, and *especially*
with
some corrupted journals in the mix, since I have none right now (fresh
computer, yay).
Jan
src/journal/journalctl.c | 301 +++
1 file changed, 200 insertions(+), 101 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index b4f88bc..bdfa0b0 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -128,6 +128,7 @@ typedef struct boot_id_t {
sd_id128_t id;
uint64_t first;
uint64_t last;
+LIST_FIELDS(struct boot_id_t, boot_list);
} boot_id_t;
static void pager_open_if_enabled(void) {
@@ -851,111 +852,234 @@ static int add_matches(sd_journal *j, char **args) {
return 0;
}
-static int boot_id_cmp(const void *a, const void *b) {
-uint64_t _a, _b;
+static int discover_next_boot(sd_journal *j,
+ boot_id_t **boot,
+ char **cursor,
+ bool advance_left,
+ bool read_realtime) {
+int r;
+char match[9+32+1] = _BOOT_ID=;
+_cleanup_free_ boot_id_t *next_boot = NULL;
-_a = ((const boot_id_t *)a)-first;
-_b = ((const boot_id_t *)b)-first;
+assert(j);
+assert(boot);
+assert(cursor);
-return _a _b ? -1 : (_a _b ? 1 : 0);
-}
+/* We expect the cursor to point us to the last position
+ * of a boot, so that the next invocation of sd_j_next would be
+ * from a different boot. We collect any information we desire
+ * and then jump to the last location of the new boot by using
+ * a _BOOT_ID match and coming from the other journal direction
+ * (the tail). Since we wouldn't then be able to advance to the
+ * next boot using sd_j_next, we take a cursor and rinse and repeat. */
-static int get_boots(sd_journal *j,
- boot_id_t **boots,
- unsigned int *count,
- boot_id_t *query_ref_boot) {
-int r;
-const void *data;
-size_t length, allocated = 0;
+sd_journal_flush_matches(j);
-assert(j);
-assert(boots);
-assert(count);
+if (*cursor) {
+r = sd_journal_seek_cursor(j, *cursor);
+if (r 0)
+return r;
+
+if (advance_left)
+r = sd_journal_previous(j);
+else
+r = sd_journal_next(j);
+if (r 0)
+return r;
+else if (r == 0)
+return -ENODATA; /* We were here last time, odd. */
+} else {
+if (advance_left)
+r = sd_journal_seek_tail(j);
+else
+r = sd_journal_seek_head(j);
+if (r 0)
+return r;
+}
-r = sd_journal_query_unique(j, _BOOT_ID);
+/* Advance to next boot. */
+if (advance_left)
+r = sd_journal_previous(j);
+else
+r = sd_journal_next(j);
if (r 0)
return r;
+else if (r == 0) {
+/* End of journal, yay. */
+*boot = NULL;
+return 0;
+}
-*count = 0;
-SD_JOURNAL_FOREACH_UNIQUE(j, data, length) {
-boot_id_t *id;
+next_boot = new0(boot_id_t, 1);
+if (!next_boot)
+return log_oom();
-assert(startswith(data, _BOOT_ID=));
+r = sd_journal_get_monotonic_usec(j, NULL, next_boot-id);
+if (r 0)
+return r;
-if (!GREEDY_REALLOC(*boots, allocated, *count + 1))
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 11:19 PM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 1, 2015 at 1:53 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski l...@amacapital.net wrote: On Apr 1, 2015 12:56 PM, Kay Sievers k...@vrfy.org wrote: Do you have an idea why the VM does not accept the custom font? If that is something obvious, and we can detect it, we could make vconsole-setup check for it. But then again, fixing setfont seems like the obvious fix here. I assume it's because the VM has no graphical console at all. We check the existence of the corresponding /dev/vcs%i, to check if the tty is allocated where we want to apply the font to. Do these devices exist on the running machine? Yes: # ls /dev/vcs* /dev/vcs /dev/vcs2 /dev/vcs4 /dev/vcsa1 /dev/vcsa3 /dev/vcs1 /dev/vcs3 /dev/vcsa /dev/vcsa2 /dev/vcsa4 Looking at the code, the vc_screen.c code seems to create those devices unconditionally. They should only get created when something accesses the corresponding tty. deallocvt(1) can kill unused ones and the device nodes should disappear. And what does this say? grep . /sys/class/tty/tty0/active /sys/class/tty/console/active # grep . /sys/class/tty/tty0/active /sys/class/tty/console/active /sys/class/tty/tty0/active:tty1 /sys/class/tty/console/active:ttyS0 vcs1 has, roughly: early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel. Now I'm wondering how that buffer came to be. In any event, some tracing of the code suggests that I have vga_video_type == VIDEO_TYPE_CGA, and that fails if (vga_video_type VIDEO_TYPE_EGAM) in vgacon_font_set. Indeed, /proc/ioports has: 03d4-03d5 : cga and dmesg says: [0.00] Console: colour *CGA 80x25 I don't see this information in sysfs anywhere. Perhaps checking for an active console and detecting -EINVAL from vgacon_font_get would work. Hmm, yeah, maybe we could try one of the font-related ioctls to find out if the driver supports that before we spawn setfont. /proc/fb is empty on this VM, so maybe that would help. Grr, this stuff is really old and crufty. The offending qemu command line args appear to be -vga none -display none. I assume I have CGA because it's the fallback case in vgacon.c if nothing matches. Hehe, blast from the past. :) If you give kvm a VGA device, it all works fine? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 11:19 PM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 1, 2015 at 1:53 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski l...@amacapital.net wrote: On Apr 1, 2015 12:56 PM, Kay Sievers k...@vrfy.org wrote: Do you have an idea why the VM does not accept the custom font? If that is something obvious, and we can detect it, we could make vconsole-setup check for it. But then again, fixing setfont seems like the obvious fix here. I assume it's because the VM has no graphical console at all. We check the existence of the corresponding /dev/vcs%i, to check if the tty is allocated where we want to apply the font to. Do these devices exist on the running machine? Yes: # ls /dev/vcs* /dev/vcs /dev/vcs2 /dev/vcs4 /dev/vcsa1 /dev/vcsa3 /dev/vcs1 /dev/vcs3 /dev/vcsa /dev/vcsa2 /dev/vcsa4 Looking at the code, the vc_screen.c code seems to create those devices unconditionally. They should only get created when something accesses the corresponding tty. deallocvt(1) can kill unused ones and the device nodes should disappear. deallocvt doesn't seem to kill those device nodes for me. And what does this say? grep . /sys/class/tty/tty0/active /sys/class/tty/console/active # grep . /sys/class/tty/tty0/active /sys/class/tty/console/active /sys/class/tty/tty0/active:tty1 /sys/class/tty/console/active:ttyS0 vcs1 has, roughly: early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel. Now I'm wondering how that buffer came to be. In any event, some tracing of the code suggests that I have vga_video_type == VIDEO_TYPE_CGA, and that fails if (vga_video_type VIDEO_TYPE_EGAM) in vgacon_font_set. Indeed, /proc/ioports has: 03d4-03d5 : cga and dmesg says: [0.00] Console: colour *CGA 80x25 I don't see this information in sysfs anywhere. Perhaps checking for an active console and detecting -EINVAL from vgacon_font_get would work. Hmm, yeah, maybe we could try one of the font-related ioctls to find out if the driver supports that before we spawn setfont. /proc/fb is empty on this VM, so maybe that would help. Grr, this stuff is really old and crufty. The offending qemu command line args appear to be -vga none -display none. I assume I have CGA because it's the fallback case in vgacon.c if nothing matches. Hehe, blast from the past. :) If you give kvm a VGA device, it all works fine? I just tried it. setfont succeeds, and the VGA device matches /dev/vcs's contents. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 11:38 PM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers k...@vrfy.org wrote: They should only get created when something accesses the corresponding tty. deallocvt(1) can kill unused ones and the device nodes should disappear. deallocvt doesn't seem to kill those device nodes for me. Seems to work here: # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 # cat /dev/tty7 ^C # cat /dev/tty9 ^C # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 crw-rw 1 root tty 7, 7 Apr 1 23:42 /dev/vcs7 crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 # deallocvt 7 # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 # deallocvt 9 # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 The offending qemu command line args appear to be -vga none -display none. I assume I have CGA because it's the fallback case in vgacon.c if nothing matches. Hehe, blast from the past. :) If you give kvm a VGA device, it all works fine? I just tried it. setfont succeeds, and the VGA device matches /dev/vcs's contents. Ah, nice. If we figure out some dummy font-related call to check if the kernel supports font handling at all, we could just add that to vconsole-setup, I guess. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 2:47 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 11:38 PM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers k...@vrfy.org wrote: They should only get created when something accesses the corresponding tty. deallocvt(1) can kill unused ones and the device nodes should disappear. deallocvt doesn't seem to kill those device nodes for me. Seems to work here: # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 # cat /dev/tty7 ^C # cat /dev/tty9 ^C # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 crw-rw 1 root tty 7, 7 Apr 1 23:42 /dev/vcs7 crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 # deallocvt 7 # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 # deallocvt 9 # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 Aha. It seems that I have something holding tty1-tty4 open. I'll fix that on my end. Will that make vconsole-setup stop calling setfont? If so, that will indirectly solve my problem. (Although... I don't see why the presence or absence of in-use vts should affect font loading. Also, it seems like vcs1 shows up no matter what I do.) The offending qemu command line args appear to be -vga none -display none. I assume I have CGA because it's the fallback case in vgacon.c if nothing matches. Hehe, blast from the past. :) If you give kvm a VGA device, it all works fine? I just tried it. setfont succeeds, and the VGA device matches /dev/vcs's contents. Ah, nice. If we figure out some dummy font-related call to check if the kernel supports font handling at all, we could just add that to vconsole-setup, I guess. Kay -- Andy Lutomirski AMA Capital Management, LLC ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 1:53 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski l...@amacapital.net wrote: On Apr 1, 2015 12:56 PM, Kay Sievers k...@vrfy.org wrote: Do you have an idea why the VM does not accept the custom font? If that is something obvious, and we can detect it, we could make vconsole-setup check for it. But then again, fixing setfont seems like the obvious fix here. I assume it's because the VM has no graphical console at all. We check the existence of the corresponding /dev/vcs%i, to check if the tty is allocated where we want to apply the font to. Do these devices exist on the running machine? Yes: # ls /dev/vcs* /dev/vcs /dev/vcs2 /dev/vcs4 /dev/vcsa1 /dev/vcsa3 /dev/vcs1 /dev/vcs3 /dev/vcsa /dev/vcsa2 /dev/vcsa4 Looking at the code, the vc_screen.c code seems to create those devices unconditionally. And what does this say? grep . /sys/class/tty/tty0/active /sys/class/tty/console/active # grep . /sys/class/tty/tty0/active /sys/class/tty/console/active /sys/class/tty/tty0/active:tty1 /sys/class/tty/console/active:ttyS0 vcs1 has, roughly: early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel. Now I'm wondering how that buffer came to be. In any event, some tracing of the code suggests that I have vga_video_type == VIDEO_TYPE_CGA, and that fails if (vga_video_type VIDEO_TYPE_EGAM) in vgacon_font_set. Indeed, /proc/ioports has: 03d4-03d5 : cga and dmesg says: [0.00] Console: colour *CGA 80x25 I don't see this information in sysfs anywhere. Perhaps checking for an active console and detecting -EINVAL from vgacon_font_get would work. /proc/fb is empty on this VM, so maybe that would help. Grr, this stuff is really old and crufty. The offending qemu command line args appear to be -vga none -display none. I assume I have CGA because it's the fallback case in vgacon.c if nothing matches. --Andy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] efi-boot-generator: Continue if /boot does not exist
/boot does not exist on a stateless system, so do not get
confused by that.
---
src/efi-boot-generator/efi-boot-generator.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/src/efi-boot-generator/efi-boot-generator.c
b/src/efi-boot-generator/efi-boot-generator.c
index 58c4cc2..938bbe2 100644
--- a/src/efi-boot-generator/efi-boot-generator.c
+++ b/src/efi-boot-generator/efi-boot-generator.c
@@ -35,6 +35,7 @@ static const char *arg_dest = /tmp;
int main(int argc, char *argv[]) {
_cleanup_free_ char *what = NULL;
_cleanup_fclose_ FILE *f = NULL;
+struct stat boot_stat;
int r = EXIT_SUCCESS;
sd_id128_t id;
char *name;
@@ -68,10 +69,24 @@ int main(int argc, char *argv[]) {
return EXIT_SUCCESS;
}
-if (path_is_mount_point(/boot, true) = 0
-dir_is_empty(/boot) = 0) {
-log_debug(/boot already populated, exiting.);
-return EXIT_SUCCESS;
+r = stat(/boot, boot_stat);
+if (r 0) {
+if (errno == ENOENT)
+log_debug(/boot does not exist, continuing.);
+else {
+log_debug(Failed to stat /boot, exiting.);
+return EXIT_FAILURE;
+}
+} else {
+if (!S_ISDIR(boot_stat.st_mode)
!S_ISLNK(boot_stat.st_mode)) {
+log_debug(/boot is not a directory or link,
exiting.);
+return EXIT_FAILURE;
+}
+if (path_is_mount_point(/boot, true) = 0
+dir_is_empty(/boot) = 0) {
+log_debug(/boot already populated, exiting.);
+return EXIT_SUCCESS;
+}
}
r = efi_loader_get_device_part_uuid(id);
--
2.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 10:45 PM, Andy Lutomirski l...@amacapital.net wrote: On Apr 1, 2015 12:56 PM, Kay Sievers k...@vrfy.org wrote: Do you have an idea why the VM does not accept the custom font? If that is something obvious, and we can detect it, we could make vconsole-setup check for it. But then again, fixing setfont seems like the obvious fix here. I assume it's because the VM has no graphical console at all. We check the existence of the corresponding /dev/vcs%i, to check if the tty is allocated where we want to apply the font to. Do these devices exist on the running machine? And what does this say? grep . /sys/class/tty/tty0/active /sys/class/tty/console/active Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH 1/2] libsystemd: add sd-device library
On Wed, Apr 1, 2015 at 3:00 PM, Tom Gundersen t...@jklm.no wrote:
This provides equivalent functionality to libudev-device, but in the
systemd style. The public API only caters to creating sd_device objects
from for devices that already exist in /sys, there is no support for
listening for monitoring uevents or creating devices received over
the udev netlink protocol.
The private API contains the necessary functionality to make sd-device
a drop-in replacement for libudev-device, but which we will not export
publicly.
---
Hi guys,
This is another step on the way of ripping out the bits of libudev that will
still be useful once the udev netlink transport has been replaced by kdbus.
Feedback welcome.
Not a real review. Just a few nitpicks.
Makefile.am|9 +-
src/libsystemd/sd-device/device-internal.h | 125 ++
src/libsystemd/sd-device/device-private.c | 1101 +
src/libsystemd/sd-device/device-private.h | 63 +
src/libsystemd/sd-device/device-util.h | 48 +
src/libsystemd/sd-device/sd-device.c | 1812
src/systemd/sd-device.h| 77 ++
7 files changed, 3234 insertions(+), 1 deletion(-)
create mode 100644 src/libsystemd/sd-device/device-internal.h
create mode 100644 src/libsystemd/sd-device/device-private.c
create mode 100644 src/libsystemd/sd-device/device-private.h
create mode 100644 src/libsystemd/sd-device/device-util.h
create mode 100644 src/libsystemd/sd-device/sd-device.c
create mode 100644 src/systemd/sd-device.h
diff --git a/Makefile.am b/Makefile.am
index 93fdbc2..9509247 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -231,6 +231,7 @@ AM_CPPFLAGS = \
-I $(top_srcdir)/src/libsystemd/sd-rtnl \
-I $(top_srcdir)/src/libsystemd/sd-network \
-I $(top_srcdir)/src/libsystemd/sd-hwdb \
+ -I $(top_srcdir)/src/libsystemd/sd-device \
-I $(top_srcdir)/src/libsystemd-network \
-I $(top_srcdir)/src/libsystemd-terminal \
$(OUR_CPPFLAGS)
@@ -2918,6 +2919,7 @@ libsystemd_internal_la_SOURCES = \
src/systemd/sd-path.h \
src/systemd/sd-network.h \
src/systemd/sd-hwdb.h \
+ src/systemd/sd-device.h \
src/libsystemd/sd-bus/sd-bus.c \
src/libsystemd/sd-bus/bus-control.c \
src/libsystemd/sd-bus/bus-control.h \
@@ -2981,7 +2983,12 @@ libsystemd_internal_la_SOURCES = \
src/libsystemd/sd-network/network-util.c \
src/libsystemd/sd-hwdb/sd-hwdb.c \
src/libsystemd/sd-hwdb/hwdb-util.h \
- src/libsystemd/sd-hwdb/hwdb-internal.h
+ src/libsystemd/sd-hwdb/hwdb-intenal.h \
+ src/libsystemd/sd-device/device-internal.h \
+ src/libsystemd/sd-device/device-util.h \
+ src/libsystemd/sd-device/sd-device.c \
+ src/libsystemd/sd-device/device-private.c \
+ src/libsystemd/sd-device/device-private.h
nodist_libsystemd_internal_la_SOURCES = \
src/libsystemd/libsystemd.sym
diff --git a/src/libsystemd/sd-device/device-internal.h
b/src/libsystemd/sd-device/device-internal.h
new file mode 100644
index 000..59ec1a6
--- /dev/null
+++ b/src/libsystemd/sd-device/device-internal.h
@@ -0,0 +1,125 @@
+/***
+ This file is part of systemd.
+
+ Copyright 2008-2012 Kay Sievers k...@vrfy.org
+ Copyright 2014 Tom Gundersen t...@jklm.no
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#pragma once
+
+#include hashmap.h
+#include set.h
+
+struct sd_device {
+uint64_t n_ref;
+
+sd_device *parent;
+bool parent_set; /* no need to try to reload parent */
+
+OrderedHashmap *properties;
+Iterator properties_iterator;
+uint64_t properties_generation; /* changes whenever the properties
are changed */
+uint64_t properties_iterator_generation; /* generation when
iteration was started */
+
+/* the subset of the properties that should be written to the db*/
+OrderedHashmap *properties_db;
+
+Hashmap *sysattr_values; /* cached sysattr values */
+
+Set *sysattrs; /* names of sysattrs */
+Iterator sysattrs_iterator;
+bool sysattrs_read; /* don't try to re-read sysattrs once read */
+
+Set *tags;
+Iterator tags_iterator;
+
Re: [systemd-devel] [RFC][PATCH] udev: net_id - support multi-function, multi-port enpo* device names
I pushed a version of this only handling the multi-port devices. We
can deal with multi-function if and when they appear in the wild.
-t
On Wed, Apr 1, 2015 at 4:52 PM, Tom Gundersen t...@jklm.no wrote:
I'd argue that having firmware labels for such devices makes no sense, but
they exist, so make sure
we handle them as best as we can.
---
src/udev/udev-builtin-net_id.c | 64
--
1 file changed, 43 insertions(+), 21 deletions(-)
diff --git a/src/udev/udev-builtin-net_id.c b/src/udev/udev-builtin-net_id.c
index 71f3a59..1a72190 100644
--- a/src/udev/udev-builtin-net_id.c
+++ b/src/udev/udev-builtin-net_id.c
@@ -35,7 +35,7 @@
* Type of names:
* bnumber -- BCMA bus core number
* ccwname -- CCW bus group name
- * oindex -- on-board device index number
+ * oindex[ffunction][ddev_port]-- on-board device index number
* sslot[ffunction][ddev_port] -- hotplug slot index number
* xMAC-- MAC address
* [Pdomain]pbussslot[ffunction][ddev_port]
@@ -126,11 +126,38 @@ struct netnames {
char ccw_group[IFNAMSIZ];
};
+/* read the 256 bytes PCI configuration space to check the multi-function
bit */
+static bool is_pci_multifunction(struct udev_device *dev) {
+_cleanup_fclose_ FILE *f = NULL;
+const char *filename;
+uint8_t config[64];
+
+filename = strjoina(udev_device_get_syspath(dev), /config);
+f = fopen(filename, re);
+if (!f)
+return false;
+if (fread(config, sizeof(config), 1, f) != 1)
+return false;
+
+/* bit 0-6 header type, bit 7 multi/single function device */
+if ((config[PCI_HEADER_TYPE] 0x80) != 0)
+return true;
+
+return false;
+}
+
/* retrieve on-board index number and label from firmware */
static int dev_pci_onboard(struct udev_device *dev, struct netnames *names) {
+unsigned func, dev_port = 0;
+size_t l;
+char *s;
+const char *attr;
const char *index;
int idx;
+if (sscanf(udev_device_get_sysname(names-pcidev), %*x:%*x:%*x.%u,
func) != 1)
+return -ENOENT;
+
/* ACPI _DSM -- device specific method for naming a PCI or PCI
Express device */
index = udev_device_get_sysattr_value(names-pcidev, acpi_index);
/* SMBIOS type 41 -- Onboard Devices Extended Information */
@@ -141,30 +168,25 @@ static int dev_pci_onboard(struct udev_device *dev,
struct netnames *names) {
idx = strtoul(index, NULL, 0);
if (idx = 0)
return -EINVAL;
-snprintf(names-pci_onboard, sizeof(names-pci_onboard), o%d, idx);
-names-pci_onboard_label =
udev_device_get_sysattr_value(names-pcidev, label);
-return 0;
-}
-
-/* read the 256 bytes PCI configuration space to check the multi-function
bit */
-static bool is_pci_multifunction(struct udev_device *dev) {
-_cleanup_fclose_ FILE *f = NULL;
-const char *filename;
-uint8_t config[64];
+/* kernel provided multi-device index */
+attr = udev_device_get_sysattr_value(dev, dev_port);
+if (attr)
+dev_port = strtol(attr, NULL, 10);
-filename = strjoina(udev_device_get_syspath(dev), /config);
-f = fopen(filename, re);
-if (!f)
-return false;
-if (fread(config, sizeof(config), 1, f) != 1)
-return false;
+s = names-pci_onboard;
+l = sizeof(names-pci_onboard);
+l = strpcpyf(s, l, o%d, idx);
+if (func 0 || is_pci_multifunction(names-pcidev))
+l = strpcpyf(s, l, f%d, func);
+if (dev_port 0)
+l = strpcpyf(s, l, d%d, dev_port);
+if (l == 0)
+names-pci_onboard[0] = '\0';
-/* bit 0-6 header type, bit 7 multi/single function device */
-if ((config[PCI_HEADER_TYPE] 0x80) != 0)
-return true;
+names-pci_onboard_label =
udev_device_get_sysattr_value(names-pcidev, label);
-return false;
+return 0;
}
static int dev_pci_slot(struct udev_device *dev, struct netnames *names) {
--
2.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 04/01/2015 02:37 PM, Lennart Poettering wrote: Note that I intend to add more subvolume lines to tmpfiles even. For example, I am pretty sure /home should be created as subvolume if it doesn't exist already, and similar. I'm afraid that will still only work on a single host setup ( laptop/desktop ) and I'm pretty sure if the intent from you is to default to more subvolume creation i'm afraid you will start conflicting with installers on top of everything else as well. If and when the time comes and btrfs has become the default filesystem in all the major distribution using systemd and the knowledge and the experience of it's usage has become widespread enough, the decision to default to subvolume creation if on btrfs can be re-visited but until that time arrives sticking with directory creation is the right way to go because you are creating more problems for everybody than you are thinking you are solving. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Wed, Apr 1, 2015 at 9:36 PM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers k...@vrfy.org wrote:
On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski l...@amacapital.net
wrote:
On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote:
Hi all-
When running virtme (a simple vm gadget) on Fedora 21, the slowest
part of bootup by far appears to be systemd-vconsole-setup:
# time /usr/lib/systemd/systemd-vconsole-setup
putfont: PIO_FONT trying ...
...
setfont: putfont: 512,8x16: failed: -1
putfont: PIO_FONT: Invalid argument
/usr/bin/setfont failed with error code 71.
setfont is not part of systemd, we just invoke it. If that fails, this
is a problem somewhere between the VM, the kernel and console-tools.
Aha -- I missed that systemd-vconsole-setup calls setfont. I can
trigger the same problem by just typing setfont. For whatever reason,
my other Fedora 21 computer only has this problem if I type setfont
and not if I run systemd-vconcole-setup.
My uneducated guess is that your virtual machine boots up with a
non-graphical console, and the tool thus tries to upload the fonts
into the good old VGA hw text mode glyph tables, and qemu is very slow
at that... Or something like that.
setfont is doing this:
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
This thing has only a serial console:
# cat /proc/consoles
ttyS0-W- (EC a)4:64
setfont does this:
/* we allow ourselves to hang here for ca 5 seconds, xdm may
be playing tricks on us. */
while ((loop++ 20) (i = ioctl(fd, PIO_FONT, buf)))
{
if (loop = 1)
fprintf(stderr, putfont: PIO_FONT trying ...\n);
else
fprintf(stderr, .);
usleep(25);
}
fprintf(stderr, \n);
Alexey, would it make sense to remove this loop or to add a way to turn it
off?
Ping, everyone?
This issue still exists. AFAICT systemd is relying on a really old
tool, that that really old tool (setfont) is sometimes delaying boot
by a very large amount. Can we either fix the tool (Alexey) or stop
using it (systemd people)?
Hmm, why is the vm gadget you run configuring a custom console font
at all? If there is no custom font specified in t he config, systemd
will not run setfont.
It's not intentionally configuring a custom font, but it might be
inheriting Fedora's settings.
Ideally, /etc/vconsole.conf does not even exist in a default setup. It
is only needed for foreign language keyboard support or more exotic
font requirements.
Or did you mean to have vconsole-setup detect that it should not even
try to run setfont? Not sure how to find that out.
I don't really see how vconsole-setup could get rid of calling setfont
from systemd, it is needed in many setups.
vconsole-setup could set the font itself instead of using setfont if
setfont can't be configured or fixed not to keep retrying for five
seconds (!).
It is a rather complex logic which would need to be duplicated in
systemd. We so far have avoided it, because the kernel VC font and
keymaps are so conceptually limited, that it does not really make
sense to build a modern system on top of it.
If systemd gets advanvced console support with systemd-consoled,
we need full unicode support, high-dpi display support, display hotplug,
..., all things the kernel's vc stuff will never give us. That is why we rely
on setfont and loadkeys for now.
Ideally, I think that setfont would just stop retrying on failure.
Right, that sounds like a simple and sensible fix.
Or
perhaps all of this could go through udev or some other mechanism that
doesn't try to set the font until the device actually exists. But the
console system is weird and may be that's hard.
The devices should be always there, /dev/tty1-15. It looks like the
driver behind the ttys seems not to accept the font and return EINVAL.
Not sure if udev could make a difference here.
Do you have an idea why the VM does not
[systemd-devel] [PATCH] gpt-generator: Find device on a stateless system
A stateless system has a tmpfs as root file system. That obviously
does not have any block device associated with it. So try falling back
to the device of the /usr filesystem if the root filesystem fails.
---
src/gpt-auto-generator/gpt-auto-generator.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gpt-auto-generator/gpt-auto-generator.c
b/src/gpt-auto-generator/gpt-auto-generator.c
index 99dc50f..f543c58 100644
--- a/src/gpt-auto-generator/gpt-auto-generator.c
+++ b/src/gpt-auto-generator/gpt-auto-generator.c
@@ -658,8 +658,13 @@ static int add_mounts(void) {
if (r 0)
return log_error_errno(r, Failed to determine block device of
root file system: %m);
else if (r == 0) {
-log_debug(Root file system not on a (single) block device.);
-return 0;
+r = get_block_device(/usr, devno);
+if (r 0)
+return log_error_errno(r, Failed to determine block
device of /usr file system: %m);
+else if (r == 0) {
+log_debug(Neither root nor /usr file system are on a
(single) block device.);
+return 0;
+}
}
return enumerate_partitions(devno);
--
2.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Apr 1, 2015 12:56 PM, Kay Sievers k...@vrfy.org wrote:
On Wed, Apr 1, 2015 at 9:36 PM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Apr 1, 2015 at 12:32 PM, Kay Sievers k...@vrfy.org wrote:
On Wed, Apr 1, 2015 at 8:56 PM, Andy Lutomirski l...@amacapital.net
wrote:
On Thu, Jan 22, 2015 at 6:29 PM, Andy Lutomirski l...@amacapital.net
wrote:
On Thu, Jan 22, 2015 at 6:13 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 21.01.15 19:15, Andy Lutomirski (l...@amacapital.net) wrote:
Hi all-
When running virtme (a simple vm gadget) on Fedora 21, the slowest
part of bootup by far appears to be systemd-vconsole-setup:
# time /usr/lib/systemd/systemd-vconsole-setup
putfont: PIO_FONT trying ...
...
setfont: putfont: 512,8x16: failed: -1
putfont: PIO_FONT: Invalid argument
/usr/bin/setfont failed with error code 71.
setfont is not part of systemd, we just invoke it. If that fails, this
is a problem somewhere between the VM, the kernel and console-tools.
Aha -- I missed that systemd-vconsole-setup calls setfont. I can
trigger the same problem by just typing setfont. For whatever reason,
my other Fedora 21 computer only has this problem if I type setfont
and not if I run systemd-vconcole-setup.
My uneducated guess is that your virtual machine boots up with a
non-graphical console, and the tool thus tries to upload the fonts
into the good old VGA hw text mode glyph tables, and qemu is very slow
at that... Or something like that.
setfont is doing this:
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
nanosleep({0, 25000}, NULL) = 0
ioctl(3, PIO_FONT, 0xfbc010)= -1 EINVAL (Invalid argument)
write(2, ., 1.)= 1
This thing has only a serial console:
# cat /proc/consoles
ttyS0-W- (EC a)4:64
setfont does this:
/* we allow ourselves to hang here for ca 5 seconds, xdm may
be playing tricks on us. */
while ((loop++ 20) (i = ioctl(fd, PIO_FONT, buf)))
{
if (loop = 1)
fprintf(stderr, putfont: PIO_FONT trying ...\n);
else
fprintf(stderr, .);
usleep(25);
}
fprintf(stderr, \n);
Alexey, would it make sense to remove this loop or to add a way to turn
it off?
Ping, everyone?
This issue still exists. AFAICT systemd is relying on a really old
tool, that that really old tool (setfont) is sometimes delaying boot
by a very large amount. Can we either fix the tool (Alexey) or stop
using it (systemd people)?
Hmm, why is the vm gadget you run configuring a custom console font
at all? If there is no custom font specified in t he config, systemd
will not run setfont.
It's not intentionally configuring a custom font, but it might be
inheriting Fedora's settings.
Ideally, /etc/vconsole.conf does not even exist in a default setup. It
is only needed for foreign language keyboard support or more exotic
font requirements.
Or did you mean to have vconsole-setup detect that it should not even
try to run setfont? Not sure how to find that out.
I don't really see how vconsole-setup could get rid of calling setfont
from systemd, it is needed in many setups.
vconsole-setup could set the font itself instead of using setfont if
setfont can't be configured or fixed not to keep retrying for five
seconds (!).
It is a rather complex logic which would need to be duplicated in
systemd. We so far have avoided it, because the kernel VC font and
keymaps are so conceptually limited, that it does not really make
sense to build a modern system on top of it.
If systemd gets advanvced console support with systemd-consoled,
we need full unicode support, high-dpi display support, display hotplug,
..., all things the kernel's vc stuff will never give us. That is why we rely
on setfont and loadkeys for now.
Ideally, I think that setfont would just stop retrying on failure.
Right, that sounds like a simple and sensible fix.
Too bad no one from the kbd list has replied :(
Or
perhaps all of this could go through udev or some other mechanism that
doesn't try to set the font until the device actually exists. But the
console system is weird and may be that's hard.
Re: [systemd-devel] systemd-vconsole-setup fails very slowly
On Thu, Apr 2, 2015 at 12:00 AM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 1, 2015 at 2:47 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Apr 1, 2015 at 11:38 PM, Andy Lutomirski l...@amacapital.net wrote: On Wed, Apr 1, 2015 at 2:36 PM, Kay Sievers k...@vrfy.org wrote: They should only get created when something accesses the corresponding tty. deallocvt(1) can kill unused ones and the device nodes should disappear. deallocvt doesn't seem to kill those device nodes for me. Seems to work here: # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 # cat /dev/tty7 ^C # cat /dev/tty9 ^C # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 crw-rw 1 root tty 7, 7 Apr 1 23:42 /dev/vcs7 crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 # deallocvt 7 # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 crw-rw 1 root tty 7, 9 Apr 1 23:42 /dev/vcs9 # deallocvt 9 # ls -l /dev/vcs[6789] crw-rw 1 root tty 7, 6 Apr 1 22:21 /dev/vcs6 Aha. It seems that I have something holding tty1-tty4 open. I'll fix that on my end. Will that make vconsole-setup stop calling setfont? Oh, no. That was just in reply to the vc_screen.c code seems to create those devices unconditionally. These devices should all be fully dynamic, handled inside the kernel. It will not influence the setfont behavior of vconsole-setup. To fix your issue, setfont should be changed, or we find and add some dummy font-related ioctl to vconsole-setup, to check if setfont would fail anyway on the current VT and we skip it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
