[systemd-devel] Seeing crash on x86/qemu
Hi I am seeing a crash on x86 systemd[1]: Set hostname to . systemd[1]: Initializing machine ID from random generator. systemd-fstab-generator[43]: Checking was requested for "rootfs", but it is not a device. systemd[1]: segfault at ip 080db4b7 sp bfa1ff50 error 5 in systemd[8048000+fb000] systemd[1]: Caught , dumped core as pid 48. systemd[1]: Freezing execution. git bisect tells me this is happening due to this commit http://cgit.freedesktop.org/systemd/systemd/commit/?id=085afe36cb823e7d5b8c5f3ef21ebb9639bac78b Thanks -Khem signature.asc Description: Message signed with OpenPGP using GPGMail ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On Wed, 26.02.14 02:01, Jason A. Donenfeld (ja...@zx2c4.com) wrote: > > Upstream KDE patch is here: > https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/7584a63924620bac3bd87277c11cdb8cdb5018b1/diff/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp?format=diff Wow. Just wow. I am feeling tempted to just randomly change the version string exposed on the bus now, until they give that up. Whate else can I do than actually document that the string isn't stable? And even involving a regex now... Yuck, does KDE think it is written in Perl? Meh. 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 version debus call changed
On Tue, 25.02.14 23:47, Jason A. Donenfeld (ja...@zx2c4.com) wrote: > FYI to others experiencing weirdness, the Version api function changed > between 208 and 209: > > in 208: > > zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 > /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version > systemd 208 > > > in 209 and 210: > zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 > /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version > 210 > > > This apparently, as of writing, causes in KDE: > https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L48 > > In KDE, this breaks suspend support. > > > In case anyone else hits this snag, here's the issue. Yeah, KDE shouldn't have done that. This has been reported before. It's even documented in the wiki page that we take the liberty to change the formatting of that string any time: http://www.freedesktop.org/wiki/Software/systemd/dbus/ It is totally non-sensical to check for software versions the way KDE does it. We supply them with a call to check whether a certain operation is available (CanSuspend(), CanHibernate(), ...). They should just call that. It will tell them precisely whether the operation is not implemented in the code, or whether it is available on the hardware, and so on. But no, they decided to involve version checks... 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 version debus call changed
Upstream KDE patch is here: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/7584a63924620bac3bd87277c11cdb8cdb5018b1/diff/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp?format=diff ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
Kay and Lennart, Thanks for taking the time to clarify everything. It's greatly appreciated. Cheers, Justin On Tue, Feb 25, 2014 at 2:32 PM, Kay Sievers wrote: > On Tue, Feb 25, 2014 at 9:18 PM, Justin Brown > wrote: >> On Tue, Feb 25, 2014 at 12:12 PM, Lennart Poettering >> wrote: >>> On Tue, 25.02.14 10:41, Justin Brown (justin.br...@fandingo.org) wrote: >>> >>> And broadcast signals should never be large datagrams, but >>> only very short. >> >> Could you elaborate on this point? One of the major points of emphasis >> with kdbus seems to be performance. Why is that restricted to method >> calls? I understand that there would be implementation complexities in >> multiplexing memfds to all of the signal subscribers, but it seems >> like a desirable feature. A single source application that sends >> relatively large amounts of data (a few KB up to possibly several GB) >> to several third-party sinks seems like a natural use of memfds. > > Broadcasting complex kernel objects like file descriptors inside the > kernel to many connections at the same time is outside of the focus of > kdbus. Things get really fragile very fast if we would allow such > things. > >> As far as I can tell, the only way to accomplish this with kdbus would >> be for the source application to have a subscribe() method, so it >> could send methods to each sink. I apologize for asking such a >> simplistic question (I don't have my kdbus VM up and running yet.), >> but if I were to take this route, can the same memfd be used in >> multiple methods or would a new one need to be created for each >> subscriber? > > You can send any kind of file descriptor many times, therefore also > memfds can be send many times. > > Memfds are special that they can be used to carry *payload* of a dbus > message, not only be a naked fd. These memfds need to be sealed to get > accepted as payload, but they can be used multiple times too. > > Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd version debus call changed
On Tuesday, February 25, 2014 23:47:39 Jason A. Donenfeld wrote: > FYI to others experiencing weirdness, the Version api function changed > between 208 and 209: > > in 208: > > zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 > /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version > systemd 208 > > > in 209 and 210: > zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 > /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version > 210 > > > This apparently, as of writing, causes in KDE: > https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/mas > ter/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L48 > > In KDE, this breaks suspend support. > > > In case anyone else hits this snag, here's the issue. > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel Thanks for that, it is perfect timing since I just migrated my systems to 210 a couple of hours ago. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd version debus call changed
FYI to others experiencing weirdness, the Version api function changed between 208 and 209: in 208: zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version systemd 208 in 209 and 210: zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version 210 This apparently, as of writing, causes in KDE: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L48 In KDE, this breaks suspend support. In case anyone else hits this snag, here's the issue. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting CUPS very late on a desktop and non-server system
Dear Michael, thank you for your answer. Am Freitag, den 21.02.2014, 00:21 +0100 schrieb Michael Biebl: > This might be of interest to you: > http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-February/001433.html > > So, the cups maintainer is already looking into this. It has to be > said CUPS is not the most trivial wrt proper systemd support. Indeed, that addresses my question. Updating to CUPS package 1.7.1-6, which includes these changes, `systemd-analyze plot` suggests that `cups-browsed.service` now only takes 33 ms. The whole user space supposedly takes around 1.5 s, which I hope will improve even further in the future. Though the “experienced” time, meaning until GDM’s login screen was there, was around five seconds. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] commas vs spaces in config syntax
Hey folks, Just came across this section in the systemd-sleep.conf man page: "More than one value can be specified by separating multiple values with commas." But then I remember seeing in 99-default.link the line, "NamePolicy=database onboard slot path". It seems like our configuration syntax is a bit inconsistent. Which is better? Should things change? Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH resend] virt: detect_virtualization() do not abort on errors
On Tue, Feb 25, 2014 at 07:11:00PM +0100, Lennart Poettering wrote: > On Tue, 25.02.14 18:29, Djalal Harouni (tix...@opendz.org) wrote: > > > The detect_virtualization() logic is to test several mechanisms in order > > to detect if we are in a container or a virtual machine. This implies that > > these tests may fail at an undetermined point. > > > > An example: detect_container() needs privileges where detect_vm() does > > not, perhaps there are other cases. > > > > Currently unprivileged code will fail in: > > detect_virtualization() => detect_container() => running_in_chroot() > > > > This makes detect_virtualization() fail even for non container machines > > which prevents detection of virtual machines. Where in the other hand > > unprivileged code is able to test the CPUID hypervisor bit without any > > problem. > > > > Since we are dealing here with some test mechanisms, then do not fail if > > detect_container() returns error, just continue with detect_vm() and > > give a chance to detect_vm_cpuid() and detect_vm_dmi(), then report > > errors if any. > > This would have the effect that we'd detect different things depending > on whether we are called with or without priviliges? Hmm yes! the virtual machine detection doesn't need privileges, and the files are worldreadable. However the container needs privs! > I am pretty sure that would be a very bad idea. We should always detect > the same thing, though possibly fail with EPERM, never eat up the EPERM. Thinking more about this you are right! ok. Hmm , currently EPERM is returned as expected! > > This makes "systemd-detect-virt" tool able to detect virtual machines > > without any privileges. > > systemd-detect-virt uses fs caps to get the necessary caps to work > correctly even without privs. Yes I saw it now, cap_dac_override handles this! sorry for the noise... > Also, we are exposing "Virtualization" as bus property on the manager > object of PID 1, so that anyone cast query this without the need for > privs. Yes, thanks! > Lennart > > -- > Lennart Poettering, Red Hat -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On Tue, Feb 25, 2014 at 9:18 PM, Justin Brown wrote: > On Tue, Feb 25, 2014 at 12:12 PM, Lennart Poettering > wrote: >> On Tue, 25.02.14 10:41, Justin Brown (justin.br...@fandingo.org) wrote: >> >> And broadcast signals should never be large datagrams, but >> only very short. > > Could you elaborate on this point? One of the major points of emphasis > with kdbus seems to be performance. Why is that restricted to method > calls? I understand that there would be implementation complexities in > multiplexing memfds to all of the signal subscribers, but it seems > like a desirable feature. A single source application that sends > relatively large amounts of data (a few KB up to possibly several GB) > to several third-party sinks seems like a natural use of memfds. Broadcasting complex kernel objects like file descriptors inside the kernel to many connections at the same time is outside of the focus of kdbus. Things get really fragile very fast if we would allow such things. > As far as I can tell, the only way to accomplish this with kdbus would > be for the source application to have a subscribe() method, so it > could send methods to each sink. I apologize for asking such a > simplistic question (I don't have my kdbus VM up and running yet.), > but if I were to take this route, can the same memfd be used in > multiple methods or would a new one need to be created for each > subscriber? You can send any kind of file descriptor many times, therefore also memfds can be send many times. Memfds are special that they can be used to carry *payload* of a dbus message, not only be a naked fd. These memfds need to be sealed to get accepted as payload, but they can be used multiple times too. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On Tue, Feb 25, 2014 at 12:12 PM, Lennart Poettering wrote: > On Tue, 25.02.14 10:41, Justin Brown (justin.br...@fandingo.org) wrote: > > And broadcast signals should never be large datagrams, but > only very short. Could you elaborate on this point? One of the major points of emphasis with kdbus seems to be performance. Why is that restricted to method calls? I understand that there would be implementation complexities in multiplexing memfds to all of the signal subscribers, but it seems like a desirable feature. A single source application that sends relatively large amounts of data (a few KB up to possibly several GB) to several third-party sinks seems like a natural use of memfds. As far as I can tell, the only way to accomplish this with kdbus would be for the source application to have a subscribe() method, so it could send methods to each sink. I apologize for asking such a simplistic question (I don't have my kdbus VM up and running yet.), but if I were to take this route, can the same memfd be used in multiple methods or would a new one need to be created for each subscriber? Thanks, Justin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On Tue, Feb 25, 2014 at 7:25 PM, Simon McVittie wrote: > On 25/02/14 17:30, Kay Sievers wrote: >> There is not real difference, everything is just a message, being a >> signal or a method. Only signals are limited to pure copied data, >> disallowing fds; therefore signals will not be suitable for really >> large data. > > D-Bus allows unicast signals (libdbus API: non-NULL destination). Does > kdbus distinguish between methods and (broadcast or unicast) signals, or > is the distinction actually between unicast (method, signal or reply) > messages and broadcast signals? > > If the distinction is between unicast and broadcast, this seems a good > simplification. We only allow sending of fds to a specific connection, it checks: if (msg->dst_id == KDBUS_DST_ID_BROADCAST) return -ENOTUNIQ; The type of message does not matter. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failure to mount partitions on startup since v209
On Tue, Feb 25, 2014 at 07:28:17PM +0100, Michael Biebl wrote: > 2014-02-25 18:56 GMT+01:00 Patrick Steinhardt : > > for my system. The kernel running (3.13.5) has got > > CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT enabled. > > Do you have CONFIG_FHANDLE=y set? I did enable CONFIG_FHANDLE after first getting the issue, though that didn't change anything. I now just realized the new kernel wasn't properly installed. Re-installed it and now it works as intended. Thanks. > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? pgpjdHl41yceo.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failure to mount partitions on startup since v209
2014-02-25 18:56 GMT+01:00 Patrick Steinhardt : > for my system. The kernel running (3.13.5) has got > CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT enabled. Do you have CONFIG_FHANDLE=y set? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On 25/02/14 17:30, Kay Sievers wrote: > There is not real difference, everything is just a message, being a > signal or a method. Only signals are limited to pure copied data, > disallowing fds; therefore signals will not be suitable for really > large data. D-Bus allows unicast signals (libdbus API: non-NULL destination). Does kdbus distinguish between methods and (broadcast or unicast) signals, or is the distinction actually between unicast (method, signal or reply) messages and broadcast signals? If the distinction is between unicast and broadcast, this seems a good simplification. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Failure to mount partitions on startup since v209
Hi,
since updating from systemd v208 to v209 my system has not been
able to properly come up, problem is my home partition (GPT,
btrfs, fstab) not being detected anymore. systemd stated to wait
for it but it never arrived. After being thrown to the emergency
mode I just did a `mount -a' and all partitions where properly
mounted.
I've bisected the issue to commit df32a1ca ("libudev: disable
monitor inside a container"), still I've got no idea why it fails
for my system. The kernel running (3.13.5) has got
CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT enabled.
Anybody got an idea why it might fail for me or any hints to
further debug the issue?
Regards
Patrick
pgp4SlcFJe8F3.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On Tue, 25.02.14 10:41, Justin Brown (justin.br...@fandingo.org) wrote: > > On Mon, Feb 24, 2014 at 11:59 PM, Kay Sievers wrote: > > On Tue, Feb 25, 2014 at 4:26 AM, Justin Brown > > wrote: > >> I've been reading over some of the articles about KDBus and have a > >> question about reclaiming memfds. Let's say that I have a process > >> which is sending out a large amount of data over lots of signals, and > >> there are more than one potential subscriber. Is there (or will there > >> be) any mechanism that these signals can "expire" after some > >> conditions are met, or will the data just continue to build-up in each > >> subscriber until it frees the memfds? Additionally, would there be a > >> way to automatically expire these signals after a period of time, > >> once a certain number of signals are received, or preferably once a > >> certain amount of data are received? If that is (or will be) possible, > >> any idea how the subscriber would be handle signals expiring. > > > > Memfds or other fds cannot be broadcasted, only attached to directed > > messages. > > > > Kay > > Thanks for the response. In that case, how efficient are signals in > comparison to methods with kdbus? I was under the impression that > memfds are one of the fundamental reason that kdbus will be suitable > for sending large data payloads. memfds are used strictly only for large datagrams, to make them more effiecient. And broadcast signals should never be large datagrams, but only very short. 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 resend] virt: detect_virtualization() do not abort on errors
On Tue, 25.02.14 18:29, Djalal Harouni (tix...@opendz.org) wrote: > The detect_virtualization() logic is to test several mechanisms in order > to detect if we are in a container or a virtual machine. This implies that > these tests may fail at an undetermined point. > > An example: detect_container() needs privileges where detect_vm() does > not, perhaps there are other cases. > > Currently unprivileged code will fail in: > detect_virtualization() => detect_container() => running_in_chroot() > > This makes detect_virtualization() fail even for non container machines > which prevents detection of virtual machines. Where in the other hand > unprivileged code is able to test the CPUID hypervisor bit without any > problem. > > Since we are dealing here with some test mechanisms, then do not fail if > detect_container() returns error, just continue with detect_vm() and > give a chance to detect_vm_cpuid() and detect_vm_dmi(), then report > errors if any. This would have the effect that we'd detect different things depending on whether we are called with or without priviliges? I am pretty sure that would be a very bad idea. We should always detect the same thing, though possibly fail with EPERM, never eat up the EPERM. > This makes "systemd-detect-virt" tool able to detect virtual machines > without any privileges. systemd-detect-virt uses fs caps to get the necessary caps to work correctly even without privs. Also, we are exposing "Virtualization" as bus property on the manager object of PID 1, so that anyone cast query this without the need for privs. 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] StartTransientService problems
On Wed 05 Feb 2014 02:07:33 Lennart Poettering wrote: > On Fri, 31.01.14 16:42, Barry Scott (barry.sc...@onelan.co.uk) wrote: > > I have finally managed to get StartTransientService to run a process for > > me > > but I'm encountering issues: > > > > we start a daemon that calls StartTransientService as required. The daemon > > does not run as root, it runs as "onelan". We configure dbus to allow > > "onelan" to call all systemd Manager APIs. > > > > I want to set the User, Nice and Type of the service. I get the errors: > > > > DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set > > property User, or unknown property. > > > > DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set > > property Type, or unknown property. > > > > DBusException: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set > > property Nice, or unknown property. > > > > What do I need to do to allow these properties to be set? > > > > I also need to set the Environment. I can pass the environment in as a > > property but it does not show up the the process created or in > > systemctl status for the transient service. I do not see any messages in > > the systemd logging. > > These options weren't settable so far for transient units, because I was > too lazy to make them settable. ;-) > > I have added this in now: > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=c7040b5d1c2c148f12b6a > 5eef3dfce1661805131 > > Which should make them available via the bus for transient units. If you > need other props like this, just let me know and I'll add them too... > I just tried to set LimitCORE and that was rejected. Can you add this and the other related LimitXXX items please? Barry > > Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On Tue, Feb 25, 2014 at 5:41 PM, Justin Brown wrote: > On Mon, Feb 24, 2014 at 11:59 PM, Kay Sievers wrote: >> On Tue, Feb 25, 2014 at 4:26 AM, Justin Brown >> wrote: >>> I've been reading over some of the articles about KDBus and have a >>> question about reclaiming memfds. Let's say that I have a process >>> which is sending out a large amount of data over lots of signals, and >>> there are more than one potential subscriber. Is there (or will there >>> be) any mechanism that these signals can "expire" after some >>> conditions are met, or will the data just continue to build-up in each >>> subscriber until it frees the memfds? Additionally, would there be a >>> way to automatically expire these signals after a period of time, >>> once a certain number of signals are received, or preferably once a >>> certain amount of data are received? If that is (or will be) possible, >>> any idea how the subscriber would be handle signals expiring. >> >> Memfds or other fds cannot be broadcasted, only attached to directed >> messages. > Thanks for the response. In that case, how efficient are signals in > comparison to methods with kdbus? I was under the impression that > memfds are one of the fundamental reason that kdbus will be suitable > for sending large data payloads. There is not real difference, everything is just a message, being a signal or a method. Only signals are limited to pure copied data, disallowing fds; therefore signals will not be suitable for really large data. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH resend] virt: detect_virtualization() do not abort on errors
The detect_virtualization() logic is to test several mechanisms in order
to detect if we are in a container or a virtual machine. This implies that
these tests may fail at an undetermined point.
An example: detect_container() needs privileges where detect_vm() does
not, perhaps there are other cases.
Currently unprivileged code will fail in:
detect_virtualization() => detect_container() => running_in_chroot()
This makes detect_virtualization() fail even for non container machines
which prevents detection of virtual machines. Where in the other hand
unprivileged code is able to test the CPUID hypervisor bit without any
problem.
Since we are dealing here with some test mechanisms, then do not fail if
detect_container() returns error, just continue with detect_vm() and
give a chance to detect_vm_cpuid() and detect_vm_dmi(), then report
errors if any.
This makes "systemd-detect-virt" tool able to detect virtual machines
without any privileges.
---
For bugzilla records or backports:
commit e9a2e453bbe352 fixed some perhaps unreported bugs, hostnamectl
now reads data from the *privileged* "remote" systemd-hostnamed
Sorry for the double resend!
src/shared/virt.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/src/shared/virt.c b/src/shared/virt.c
index ec2ddcf..4789c9e 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -279,19 +279,21 @@ finish:
/* Returns a short identifier for the various VM/container implementations */
int detect_virtualization(const char **id) {
-int r;
+int container, vm;
-r = detect_container(id);
-if (r < 0)
-return r;
-if (r > 0)
+container = detect_container(id);
+if (container > 0)
return VIRTUALIZATION_CONTAINER;
-r = detect_vm(id);
-if (r < 0)
-return r;
-if (r > 0)
+vm = detect_vm(id);
+if (vm > 0)
return VIRTUALIZATION_VM;
+if (container < 0)
+return container;
+
+if (vm < 0)
+return vm;
+
return VIRTUALIZATION_NONE;
}
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] KDBus Signals and Timeouts
On Mon, Feb 24, 2014 at 11:59 PM, Kay Sievers wrote: > On Tue, Feb 25, 2014 at 4:26 AM, Justin Brown > wrote: >> I've been reading over some of the articles about KDBus and have a >> question about reclaiming memfds. Let's say that I have a process >> which is sending out a large amount of data over lots of signals, and >> there are more than one potential subscriber. Is there (or will there >> be) any mechanism that these signals can "expire" after some >> conditions are met, or will the data just continue to build-up in each >> subscriber until it frees the memfds? Additionally, would there be a >> way to automatically expire these signals after a period of time, >> once a certain number of signals are received, or preferably once a >> certain amount of data are received? If that is (or will be) possible, >> any idea how the subscriber would be handle signals expiring. > > Memfds or other fds cannot be broadcasted, only attached to directed messages. > > Kay Thanks for the response. In that case, how efficient are signals in comparison to methods with kdbus? I was under the impression that memfds are one of the fundamental reason that kdbus will be suitable for sending large data payloads. Thanks, Justin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 210
On Tue, Feb 25, 2014 at 4:32 PM, Jan Engelhardt wrote:
> On Monday 2014-02-24 23:08, Lennart Poettering wrote:
>>
>>CHANGES WITH 210:
>>
>>* logind is now a lot more aggressive when suspending the
>> machine due to a closed laptop lid. Instead of acting only
>> on the lid close action it will continuously watch the lid
>> status and act on it. This is useful for laptops where the
>> power button is on the outside of the chassis so that it can
>> be reached without opening the lid (such as the Lenovo
>> Yoga). On those machines logind will now immediately
>> re-suspend the machine if the power button has been
>> accidentally pressed while the laptop was suspended and in a
>> backpack or similar.
>
> Interesting. I have some medium-aged Sony VPCM11M1E which too has a
> power button (more like a *slider*) that could be said to be prone to
> activation; however, the machine will not react to the slider or keypress
> while the lid is closed, which is a good thing.
>
> Am I correct in the assumption that your Yoga machines are not
> as "smart" and thus desired this change? :)
Normal button, just switches the box on. Might be, that this is even a
"feature", that the power button works, so it can be used with the USB
docking stations and the closed lid.
>> Also note that this
>> logic is usually not fully sufficient and Desktop
>> Environments should take a lid switch inhibitor lock when an
>> external display is connected, as systemd will not watch
>> this on its own.
>
> Does logind handle the case of {textconsole environment with
> external display and usbkbd}?
The difference between text and graphic will not be interesting in the
future. All consoles will be "graphic", just don't look like it.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 210
On Monday 2014-02-24 23:08, Lennart Poettering wrote:
>
>CHANGES WITH 210:
>
>* logind is now a lot more aggressive when suspending the
> machine due to a closed laptop lid. Instead of acting only
> on the lid close action it will continuously watch the lid
> status and act on it. This is useful for laptops where the
> power button is on the outside of the chassis so that it can
> be reached without opening the lid (such as the Lenovo
> Yoga). On those machines logind will now immediately
> re-suspend the machine if the power button has been
> accidentally pressed while the laptop was suspended and in a
> backpack or similar.
Interesting. I have some medium-aged Sony VPCM11M1E which too has a
power button (more like a *slider*) that could be said to be prone to
activation; however, the machine will not react to the slider or keypress
while the lid is closed, which is a good thing.
Am I correct in the assumption that your Yoga machines are not
as "smart" and thus desired this change? :)
> Also note that this
> logic is usually not fully sufficient and Desktop
> Environments should take a lid switch inhibitor lock when an
> external display is connected, as systemd will not watch
> this on its own.
Does logind handle the case of {textconsole environment with
external display and usbkbd}?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] nspawn: fix detection of missing /proc/self/loginuid
Running 'systemd-nspawn -D /srv/Fedora/' gave me this error:
Failed to read /proc/self/loginuid: No such file or directory
Container Fedora failed with error code 1.
This patch fixes the problem.
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 1a02935..e6f8ce7 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1349,7 +1349,7 @@ static int reset_audit_loginuid(void) {
return 0;
r = read_one_line_file("/proc/self/loginuid", &p);
-if (r == -EEXIST)
+if (r == -ENOENT)
return 0;
if (r < 0) {
log_error("Failed to read /proc/self/loginuid: %s",
strerror(-r));
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] build-sys: Also move libsystemd-journal to rootlibdir
On 24/02/14 18:34, Kay Sievers wrote:
> On Mon, Feb 24, 2014 at 4:04 PM, Alexey Shabalin wrote:
>
>> Needed only libudev-install-hook, not more.
> It does not matter for proper filesystem layouts where everything is
> in one location, in /usr. The split of / vs. /usr never made much
> sense, it's a very incomplete and broken model.
>
> For legacy systems putting all systemd libs in / will always work,
> while putting some stuff in / and other in /usr needs to be checked
> case-by-case for every system.
>
> Systemd does don't care about fragile optimizations or doing cosmetics
> for legacy filesystem layouts, it just makes it work as long as
> needed. And for that it uses the simplest and safest option, so things
> should stay as they are now.
Thanks, I appericiate that -- for keeping them as they are.
The way --enable-split-usr, together with fine-grained
--with-root{libdir,prefix}, as they are now, are perfect for splitting
files where
they belong to. Then again, I can only speak for udev, as I'm only
building and installing it's files.
Thanks,
Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] build-sys: Always install compat pkg-config files
2014-02-23 0:55 GMT+08:00 Kay Sievers : > On Sat, Feb 22, 2014 at 3:21 PM, Armin K wrote: >> Packages are still looking for the old pkg-config files, >> so until everything has been ported over, install them >> always, no matter if compat-libs are built or not. > > So far, we think that compat should stay compat, and not mix with the > non-compat stuff. > compat-libs are for *binary* stuff that *have to* look for compat libs. why provide compat-libs with pkg-config files? if you can rebuild the code, then there is no need for old .so files. systemd provide compat .so files just because so you won't have to rebuild the affected code. why providing .so files when you can rebuild the code ? so, compat-libs is only for binary only apps, the apps that came with source code is all that fine with old pkg-config files. compat-libs is in conflict with pkg-config files. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 210
On Tue, 25.02.14 13:05, Colin Guthrie (gm...@colin.guthr.ie) wrote: > > 'Twas brillig, and Lennart Poettering at 24/02/14 22:08 did gyre and gimble: > > * systemd will now understand the usual M, K, G, T suffixes > > according to SI conventions (i.e. to the base 1000) when > > referring to throughput and hardware metrics. It will stay > > with IEC conventions (i.e. to the base 1024) for software > > metrics, according to what is customary according to > > Wikipedia. We explicitly document which base applies for > > each configuration option. > > It would seem to me that use of upper and lower case suffixes is fairly > wide-spread (at least in my head) for choosing which base (1000 vs > 1024). Of course I can't remember which is which, but perhaps using this > approach would actually be better - and default values can just use > whichever letter-case they deem appropriate for the use-case. Hmm, I thought about something like that, but I thought we'd the ones inventing it, so I opted not to use that. Do you have some links which could show that this is a more commonly accepted rule? Note that in SI "m" is milli, and "M" is mega. Would be fun to store a couple of millibyte on disk! > I guess what I mean to say is that a general rule is easier to grok than > a per-directive rule, although I may have missed some important > subtleties and back discussion here. This new rule we adopted basically results in IEC everywhere with the exception of a few things like networkd's BitsPerSecond= setting. But there it should be really obvious that it is SI that is meant, after all "100Mbit Ethernet" or "Gigabit Ethernet" refer to SI prefixes. That means the SI vs. IEC should come pretty natural I think for all technical people the way it is right now. Or to turn this around, which administrator would expect that setting BitsPerSecond= to 954K is the right way to go for Gigabit Ethernet? 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] [ANNOUNCE] systemd 210
'Twas brillig, and Lennart Poettering at 24/02/14 22:08 did gyre and gimble: > * systemd will now understand the usual M, K, G, T suffixes > according to SI conventions (i.e. to the base 1000) when > referring to throughput and hardware metrics. It will stay > with IEC conventions (i.e. to the base 1024) for software > metrics, according to what is customary according to > Wikipedia. We explicitly document which base applies for > each configuration option. It would seem to me that use of upper and lower case suffixes is fairly wide-spread (at least in my head) for choosing which base (1000 vs 1024). Of course I can't remember which is which, but perhaps using this approach would actually be better - and default values can just use whichever letter-case they deem appropriate for the use-case. I guess what I mean to say is that a general rule is easier to grok than a per-directive rule, although I may have missed some important subtleties and back discussion here. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fix typo in iDRAC network interface name: irdac->idrac
On Tue, Feb 25, 2014 at 12:43 PM, Tomasz Torcz wrote: > --- > hwdb/20-net-ifname.hwdb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hwdb/20-net-ifname.hwdb b/hwdb/20-net-ifname.hwdb > index 29d2633..2408dc1 100644 > --- a/hwdb/20-net-ifname.hwdb > +++ b/hwdb/20-net-ifname.hwdb > @@ -2,4 +2,4 @@ > > # Dell iDRAC Virtual USB NIC > usb:v413CpA102* > - ID_NET_NAME_FROM_DATABASE=irdac > + ID_NET_NAME_FROM_DATABASE=idrac Applied. Thanks! Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] NEWS: fix typo
]] Ansgar Burchardt > @@ -30,7 +30,7 @@ CHANGES WITH 210: > * logind will now watch SW_DOCK switches and inhibit reaction >to the lid switch if it is pressed. This means that logind >will not suspend the machine anymore if the lid is closed > - and the systemd is docked, if the laptop supports SW_DOCK > + and the system is docked, if the laptop supports SW_DOCK >notifications via the input layer. Note that ACPI docking >stations do not generate this currently. Also note that this >logic is usually not fully sufficient and Desktop Thanks, applied. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fix typo in iDRAC network interface name: irdac->idrac
--- hwdb/20-net-ifname.hwdb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hwdb/20-net-ifname.hwdb b/hwdb/20-net-ifname.hwdb index 29d2633..2408dc1 100644 --- a/hwdb/20-net-ifname.hwdb +++ b/hwdb/20-net-ifname.hwdb @@ -2,4 +2,4 @@ # Dell iDRAC Virtual USB NIC usb:v413CpA102* - ID_NET_NAME_FROM_DATABASE=irdac + ID_NET_NAME_FROM_DATABASE=idrac -- 1.8.5.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] backlight: don't hardcode path in binary
Hmm, why should it be configurable? Isn't one (of the many) purposes of systemd to unify the user-space of Linux? And we don't have /lib/systemd/system-sleep/ configurable either, for example. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] NEWS: fix typo
--- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 73a1dc2..41ed127 100644 --- a/NEWS +++ b/NEWS @@ -30,7 +30,7 @@ CHANGES WITH 210: * logind will now watch SW_DOCK switches and inhibit reaction to the lid switch if it is pressed. This means that logind will not suspend the machine anymore if the lid is closed - and the systemd is docked, if the laptop supports SW_DOCK + and the system is docked, if the laptop supports SW_DOCK notifications via the input layer. Note that ACPI docking stations do not generate this currently. Also note that this logic is usually not fully sufficient and Desktop -- 1.8.5.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] autogen: Allow running autogen from a builddir != srcdir
While the configure correctly supports being run outside of the top source directory by default, it's nice if autogen.sh does too: $ git clone git://anongit.freedesktop.org/systemd/systemd $ cd systemd $ mkdir $(uname -m) $ cd $(uname -m) $ ../autogen.sh a $ make --- autogen.sh | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/autogen.sh b/autogen.sh index 20f013a..9b4781c 100755 --- a/autogen.sh +++ b/autogen.sh @@ -17,6 +17,10 @@ set -e +oldpwd=$(pwd) +topdir=$(dirname $0) +cd $topdir + if [ -f .git/hooks/pre-commit.sample ] && [ ! -f .git/hooks/pre-commit ]; then # This part is allowed to fail cp -p .git/hooks/pre-commit.sample .git/hooks/pre-commit && \ @@ -53,20 +57,22 @@ args="$args \ " fi +cd $oldpwd + if [ "x$1" = "xc" ]; then -./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs --enable-kdbus $args +$topdir/configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs --enable-kdbus $args make clean elif [ "x$1" = "xg" ]; then -./configure CFLAGS='-g -Og -ftrapv' --enable-compat-libs --enable-kdbus $args +$topdir/configure CFLAGS='-g -Og -ftrapv' --enable-compat-libs --enable-kdbus $args make clean elif [ "x$1" = "xa" ]; then -./configure CFLAGS='-g -O0 -Wsuggest-attribute=pure -Wsuggest-attribute=const -ftrapv' --enable-compat-libs --enable-kdbus $args +$topdir/configure CFLAGS='-g -O0 -Wsuggest-attribute=pure -Wsuggest-attribute=const -ftrapv' --enable-compat-libs --enable-kdbus $args make clean elif [ "x$1" = "xl" ]; then -./configure CC=clang CFLAGS='-g -O0 -ftrapv -Wno-gnu' --enable-compat-libs --enable-kdbus $args +$topdir/configure CC=clang CFLAGS='-g -O0 -ftrapv -Wno-gnu' --enable-compat-libs --enable-kdbus $args make clean elif [ "x$1" = "xs" ]; then -scan-build ./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs --enable-kdbus $args +scan-build $topdir/configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs --enable-kdbus $args scan-build make else echo @@ -74,6 +80,6 @@ else echo "Initialized build system. For a common configuration please run:" echo "" echo -echo "./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs --enable-kdbus $args" +echo "$topdir/configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs --enable-kdbus $args" echo fi -- 1.8.5.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
