Re: [systemd-devel] [HEADS-UP] systemd down/upstream meeting at FOSDEM?
Le mardi 22 janvier 2013 à 23:11 +0100, Lennart Poettering a écrit : Heya, I just learned that a number of systemd downstream and upstream folks are attending FOSDEM. We'll at least have Michael Biebl, Tollef Fog Heen, Colin Guthrie, Kay Sievers, Harald Hoyer and myself around. We were wondering whether it might be a good idea to meet up for some kind of systemd BOF at FOSDEM? My current thinking goes towards maybe lunch on saturday, but details about time and location are to be determined. Anybody else is coming who'd like to join us? Anybody from ArchLinux attending FOSDEM? SUSE? Or the other distributions? I'll be there too (doing also a talk about Secure Boot on Sunday). -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: Set source for mountinfo .mount units
---
src/core/mount.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index 03eff9d..e5f5e42 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1472,7 +1472,7 @@ static int mount_add_one(
int r;
Unit *u;
bool delete;
-char *e, *w = NULL, *o = NULL, *f = NULL;
+char *e, *w = NULL, *o = NULL, *s = NULL, *f = NULL;
MountParameters *p;
bool load_extras = false;
@@ -1545,6 +1545,7 @@ static int mount_add_one(
if (!(w = strdup(what)) ||
!(o = strdup(options)) ||
+!(s = strdup(/proc/self/mountinfo)) ||
!(f = strdup(fstype))) {
r = -ENOMEM;
goto fail;
@@ -1558,6 +1559,8 @@ static int mount_add_one(
}
MOUNT(u)-from_proc_self_mountinfo = true;
+free(u-source_path);
+u-source_path = s;
free(p-what);
p-what = w;
@@ -1583,6 +1586,7 @@ static int mount_add_one(
fail:
free(w);
free(o);
+free(s);
free(f);
if (delete u)
--
1.7.2.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Set source for mountinfo .mount units
Regardless of this patch, it might be a good idea to mention
/proc/self/mountinfo in systemd.mount(5) as currently there is no mention
of .mount files might pop up by systemd by looking at /proc/self/mountinfo.
Thanks
On Wed, Jan 23, 2013 at 9:23 AM, Umut Tezduyar u...@tezduyar.com wrote:
---
src/core/mount.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index 03eff9d..e5f5e42 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1472,7 +1472,7 @@ static int mount_add_one(
int r;
Unit *u;
bool delete;
-char *e, *w = NULL, *o = NULL, *f = NULL;
+char *e, *w = NULL, *o = NULL, *s = NULL, *f = NULL;
MountParameters *p;
bool load_extras = false;
@@ -1545,6 +1545,7 @@ static int mount_add_one(
if (!(w = strdup(what)) ||
!(o = strdup(options)) ||
+!(s = strdup(/proc/self/mountinfo)) ||
!(f = strdup(fstype))) {
r = -ENOMEM;
goto fail;
@@ -1558,6 +1559,8 @@ static int mount_add_one(
}
MOUNT(u)-from_proc_self_mountinfo = true;
+free(u-source_path);
+u-source_path = s;
free(p-what);
p-what = w;
@@ -1583,6 +1586,7 @@ static int mount_add_one(
fail:
free(w);
free(o);
+free(s);
free(f);
if (delete u)
--
1.7.2.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and RTAI not getting along
Lennart Poettering wrote: On Tue, 22.01.13 02:33, JB (gene...@itpsg.com) wrote: Subsequent starts and stops of the application of course do not change those process ID and kernel threads because, I can only assume, they are reused. A kill -9 as root will not even kill them. The problem I have is that system shutdown times take quite a few minutes unless systemd has done everything it can to kill these, correct? This mostly results in a very long delay on a timeout waiting for dependent processes to die when they never will on shutdown or restart of the computer or just the webapp service. So let me get this right: if RTAI is used it will spawn kernel threads that inherit cgroup membership of the client requesting it? Yep, I've verified that it is in the same cgroup. That realls sounds like a kernel issue to me, and should be fixed by RTAI. I mean, I have no idea what this really is and how it behaves, but Maybe, maybe not...depends on if that's by design or not. There may be significant advantages to implementing it this way in the kernel. I don't know for sure. Maybe the two groups of developers should get together and start talking. allowing kernel threads to live in arbitrary user managed cgroups sounds a bit dangerous to me... I don't have enough of an understanding of the internal implementation of cgroups in the kernel to have an opinion or debate on how dangerous it might be. One of RTAI's selling points is being able to run an application from user space with about as close as you can get to an in-kernel hard real time environment on commodity hardware. Dangerous? Maybe. Useful? Absolutely. Ever written a truly hard real time app? It's dangerous, quite dangerous in fact. Does that mean it shouldn't be done? Hell no. It is kind of a downer that the project seems to have great difficulty keeping up with kernel releases as the most recent release of RTAI kernel patches is for a 2.6.38.8 kernel. It forces me back to an FC15 distribution since the newer OS releases will not run some of those older kernels very well. I'd probably contribute but at the moment I don't really have the time to do that nor rewrite it for RTLinux nor any other environment even assuming it would perform as well. It is frustrating between the two groups (systemd devs and rtai devs). I posted the same message to the RTAI list to make that group aware of what I was seeing and how systemd was handling it by default. If you read the RTAI docs there is an opinionated point of view on RTAI's design, the design of RT Linux from which it originated many years ago, and other things like other RTOSes copying RTAI's designs, etc... Systemd documentation is surprisingly complete and quite good for open source software. Systemd developers are also clearly opinionated with it showing more on the list rather than in the reference docs which I suppose is more appropriate. But again, as I had done once before, I urge caution in leveraging systemd to enforce or impose upon the universe of linux/unix software engineers too narrowly the opinions held by a small group (relatively speaking) about how software should or shouldn't do what it does. That all said, you can use KillMode= and related settings to alter what is killed. See systemd.kill(5) for details. Thanks!! That is what I was looking for. I'll give it a shot and see how it does. the process value for that param I think is exactly what I'm looking for. Leave the kernel threads alone, and the RT resources allocated and just kill the main process. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Someone working on gui for multiseat?
Hi, Thanks what should the gui toolkit be? Gtk3? I prefer that over qt, which is not my favorite. And is there a location to store the project? I can of course get one at github or something like that, but maybe there is a better one? Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] systemd down/upstream meeting at FOSDEM?
Hi, On Tue, Jan 22, 2013 at 11:11:22PM +0100, Lennart Poettering wrote: I just learned that a number of systemd downstream and upstream folks are attending FOSDEM. We'll at least have Michael Biebl, Tollef Fog Heen, Colin Guthrie, Kay Sievers, Harald Hoyer and myself around. We were wondering whether it might be a good idea to meet up for some kind of systemd BOF at FOSDEM? My current thinking goes towards maybe lunch on saturday, but details about time and location are to be determined. Anybody else is coming who'd like to join us? Anybody from ArchLinux attending FOSDEM? SUSE? Or the other distributions? I'd like to come, but I'm giving a talk from 12 to 1pm on Saturday, so it depends on the exact time. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] systemd down/upstream meeting at FOSDEM?
On Tue, Jan 22, 2013 at 11:11 PM, Lennart Poettering lenn...@poettering.net wrote: Heya, I just learned that a number of systemd downstream and upstream folks are attending FOSDEM. We'll at least have Michael Biebl, Tollef Fog Heen, Colin Guthrie, Kay Sievers, Harald Hoyer and myself around. We were wondering whether it might be a good idea to meet up for some kind of systemd BOF at FOSDEM? My current thinking goes towards maybe lunch on saturday, but details about time and location are to be determined. Anybody else is coming who'd like to join us? Anybody from ArchLinux attending FOSDEM? SUSE? Or the other distributions? I'll be there as well. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] service: really stop watchdog timer when stopping
For services without ExecStop= the state SERVICE_STOP is never entered. as
a result the watchdog timer is not stopped and the service is restarted (if
it is configuered to restart).
Stopping the watchdog timer for SERVICE_STOP_SIGTERM as well fixes this.
---
src/core/service.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/service.c b/src/core/service.c
index ee5a1a4..593946e 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -1550,7 +1550,7 @@ static void service_set_state(Service *s, ServiceState
state) {
service_connection_unref(s);
}
-if (state == SERVICE_STOP)
+if (state == SERVICE_STOP || state == SERVICE_STOP_SIGTERM)
service_stop_watchdog(s);
/* For the inactive states unit_notify() will trim the cgroup,
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] service: make sure the watchdog timer is not restarted while stopping
A watchdog notification may be handled after the watchdog timer was stopped
while stopping the service. As a result the timer is restarted and the
service may be restarted as well.
The watchdog timestamp is initially set during startup in
service_enter_start_post() and cleared when the timer is stopped. Therefore
it can be used as an indication if the timer should be reset.
---
src/core/service.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/core/service.c b/src/core/service.c
index 593946e..baddc5a 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -3400,7 +3400,8 @@ static void service_notify_message(Unit *u, pid_t pid,
char **tags) {
if (strv_find(tags, WATCHDOG=1)) {
log_debug_unit(u-id,
%s: got WATCHDOG=1, u-id);
-service_reset_watchdog(s);
+if (dual_timestamp_is_set(s-watchdog_timestamp))
+service_reset_watchdog(s);
}
/* Notify clients about changed status or main pid */
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vncserver@.service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 23.01.2013 16:29, schrieb Antonio: and why do you not use the User= and Group= options? Because they are not required by instructions. as also runuser, but one is native systemd the other not runuser is already written in the file. However I have just tried but permission error remains. ... User=antonio Group=antonio ... what about NOT reply offlist and provide informations like the output of systemctl status as also the current content of the unit-file? I'm replying even on systemd-devel list. I'm working with unit-file on Fedora ARM on Raspberry but I'm also replying you by Fedora on notebook. However: http://www.fpaste.org/NA2M/ - -- Antonio Trande Fedora Ambassador Fedora italian translation group Blogger mail: mailto:sagit...@fedoraproject.org Homepage: http://www.fedora-os.org Sip Address : sip:sagitter AT ekiga.net Jabber :sagitter AT jabber.org GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRAAejAAoJED2vIvfUANbE22QP/RfFooZNmAQe3QAyha/WzB/e KWyDJpkk46H9egBWm3Z+vQ9Nrxstn422+y3IKHzxfMIuEjQaUMG2ycypx55uM+fn bd4H02KnrjaSkM37Ts2pE8TeARbN4rakZCIDHoTYgDCMLtF2Y6V3+J+5ZISqT1yX G4wc5FwGHGzTnBtGGyeKMffWa+E1VetxQeC/H1+951lVxE8jzDMyCgN+ld09v4a3 Xftfib0KOiwhy8nQert2jW+jyd+H9WB++TiusqPFHJMi6ar6wE5q5DdXTCLJkIOx NQ65rfSVUpEETXRUvxo2Y8yU7i1WQnDG11wenk1Z+RihAor+LuqN96gdn11XEYL2 qd6X/QIn3hftT8wyVNKz5qo9Jj/N5ou0dWqcrnzv9mCCYUH6EiT/784f+7d9VTCD ylbJBsPYS4musaCT2lQG3aVPJN75nCUESRn6QFbjJ8YIWzzyauHL9ld0rXw5dRZ+ 15Z7VkE+RrSfiR0aypoAy+oU3F4cWdwycZMkakRiljOkLHgTgLuEi42IPHf636DI KbCE6Ll4SQR9ycPYVdJWLriJ8NyV6K0NgX3arKAZRyD/SVn7n2/GVHprFy0vETmt OD2lW5TAPDjv/A0LRSBPeRHJ7E5tC55DIoi+XMRl0n/elvifPdVAVCsvBQvLVIit XlLNmhluxhrP1LuiNqhF =X+ZY -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vncserver@.service
'Twas brillig, and Antonio at 23/01/13 15:54 did gyre and gimble: Am 23.01.2013 16:29, schrieb Antonio: and why do you not use the User= and Group= options? Because they are not required by instructions. as also runuser, but one is native systemd the other not runuser is already written in the file. Well, whereever that file came from, it's wrong. systemd has built in tools to switch user and they should be used as things like runuser and su have a tendency to create their own sessions which is often not what you want. However I have just tried but permission error remains. ... User=antonio Group=antonio ... what about NOT reply offlist and provide informations like the output of systemctl status as also the current content of the unit-file? I'm replying even on systemd-devel list. I'm working with unit-file on Fedora ARM on Raspberry but I'm also replying you by Fedora on notebook. However: http://www.fpaste.org/NA2M/ That unit looks messy :s Try this: [Unit] Description=Remote desktop service (VNC) After=network.target [Service] Type=forking User=antonio Group=antonio ExecStartPre=-/usr/bin/vncserver -kill %i ExecStart=/usr/bin/vncserver %i -geometry 1024x600 -depth 24 -fp /usr/share/X11/fonts/misc ExecStop=/usr/bin/vncserver -kill %i [Install] WantedBy=multi-user.target Some notes: 1. syslog.target is old and not needed in recent systemd's 2. No need to shell out and ignore the return value of the Pre command. Use the - after the equals to ignore the return value of the command. It's output will be logged in the journal but that's fine IMO. 3. User=/Group= is a built in way to set the user and group. You should drop runuser completely as it's totally unneeded - systemd has this built in as documented in the manual. 4. I'm not sure of the %i usage above. You r spec mixed and matched a hard-coded :1 and some use of %i. If your service is vncserver@1.service, then you'll want to include the : in the commands, but if you are e.g. using vncserver@5900.service then I guess it's just an absolute number? (I forget the syntax of VNC server so forgive me if this is wrong!) 5. If you ultimately try to run vncserver with a 1 argument (meaning desktop :1 but actually translated directly as tcp port 1 then this may account for a permission error (regular users cannot listen on TCP ports 1024). Make sure you get your :1 vs. 1 correct. HTHs -- 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] systemd-analyze-197 broken
On Wed, 23.01.13 12:03, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Tue, Jan 22, 2013 at 10:05 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Tue, Jan 22, 2013 at 7:33 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Jan 23, 2013 at 4:21 AM, Lennart Poettering Check if you have /sys/firmware/efi/efivars/LoaderTicksExec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f on your system. Yeah, gummiboot now exports readable values. But I guess the issue you see is just the kernel version ... nod... I was still on 3.6 :^) - time for a kernel upgrade. I'll do a full round - I really like where the C rewrite is going so I want to make sure it covers the EFI stuff properly. I just updated to 3.8rc4 and still don't see this value - gummiboot-15-1-g9112053. I assume it's still floating in some git repo? You need a very recent kernel to have the /sys/firmware/efi/efivars directory. And you need a very recent gummiboot to get the Loader* files in them. Do you see any Loader* files in there? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-analyze-197 broken
On Wed, Jan 23, 2013 at 12:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 23.01.13 12:03, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Tue, Jan 22, 2013 at 10:05 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Tue, Jan 22, 2013 at 7:33 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Jan 23, 2013 at 4:21 AM, Lennart Poettering Check if you have /sys/firmware/efi/efivars/LoaderTicksExec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f on your system. Yeah, gummiboot now exports readable values. But I guess the issue you see is just the kernel version ... nod... I was still on 3.6 :^) - time for a kernel upgrade. I'll do a full round - I really like where the C rewrite is going so I want to make sure it covers the EFI stuff properly. I just updated to 3.8rc4 and still don't see this value - gummiboot-15-1-g9112053. I assume it's still floating in some git repo? You need a very recent kernel to have the /sys/firmware/efi/efivars directory. And you need a very recent gummiboot to get the Loader* files in them. Do you see any Loader* files in there? both /sys/firmware/efi/efvars and Loader* entries are all there, e.g. LoaderVersion* has gummiboot 15 in it. I see Loader::ConfigTimeout, -DeviceIdentifier, -DevicePartUUID, -EntriesAuto/Default/Selected, -TimeExecUsec, -TimeInitUsec, -TimeMenuUsec and LoaderVersion maybe TicksExec is set conditionally? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-analyze-197 broken
On Wed, 23.01.13 12:43, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Wed, Jan 23, 2013 at 12:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 23.01.13 12:03, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Tue, Jan 22, 2013 at 10:05 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Tue, Jan 22, 2013 at 7:33 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Jan 23, 2013 at 4:21 AM, Lennart Poettering Check if you have /sys/firmware/efi/efivars/LoaderTicksExec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f on your system. Yeah, gummiboot now exports readable values. But I guess the issue you see is just the kernel version ... nod... I was still on 3.6 :^) - time for a kernel upgrade. I'll do a full round - I really like where the C rewrite is going so I want to make sure it covers the EFI stuff properly. I just updated to 3.8rc4 and still don't see this value - gummiboot-15-1-g9112053. I assume it's still floating in some git repo? You need a very recent kernel to have the /sys/firmware/efi/efivars directory. And you need a very recent gummiboot to get the Loader* files in them. Do you see any Loader* files in there? both /sys/firmware/efi/efvars and Loader* entries are all there, e.g. LoaderVersion* has gummiboot 15 in it. I see Loader::ConfigTimeout, -DeviceIdentifier, -DevicePartUUID, -EntriesAuto/Default/Selected, -TimeExecUsec, -TimeInitUsec, -TimeMenuUsec and LoaderVersion maybe TicksExec is set conditionally? Nah, the Ticks stuff is just the old version of TimeExecUsec/TimeInitUsec. That's due to the rework Kay did regarding TSC vs. usec values. If you have these fields in the EFI vars then all you need is the current git version of systemd and systemd-analyze should show you firmware information. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] vncserver@.service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It is precisely that which Colin said me: http://lists.freedesktop.org/archives/systemd-devel/2013-January/008349.html :) - -- Antonio Trande Fedora Ambassador Fedora italian translation group Blogger mail: mailto:sagit...@fedoraproject.org Homepage: http://www.fedora-os.org Sip Address : sip:sagitter AT ekiga.net Jabber :sagitter AT jabber.org GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRAE12AAoJED2vIvfUANbEYCMQAMFDhdisjaMYM66+mlIdsVUJ J7QuNdq2vm4c9KZav0QCqiU/KDQ0kkj0LZA7a3nBaRtUC4yUNmFdDoqUGrMhp1EQ 090f9CqqBw+UbbbyFq2KDG9e4pU7Beort03xLFFeyvbpEHlquA8LEIACDjxnHmlx cToxEe4g8pSZqVgGbaoUWFkJI1gQN98i7dllOIMJKUNzbAiSAp2Ba9K9nO0qUE96 f3hoftYCNOoEXzAHDBH4Hv6uLdIU+v4MniCYAvWZfqmxQ2RlvwPyZs0sNPu7/Bpr 01bx1wiBwy5kpVssDoRepvenQEZURl+Y5Wc1CPNo+CTLIdNVhO0OykOOr/ddJ3nn BgMjL7qnbqmmRD3tMei+IW3P4GhJ0Dy+twh3Mi2ULLgGS1G7/UAqQALbBlDdqR7N s0XJKQk2dENX0Vtj209VnZeGVpCvaBdLq1vhU6G/DizYlGyNzmY3aEmA6uD4yK9e EHiKti8s+zFo6vwud6T26qxEVmaQIkzT10O46t9nP4Bzfjr9jD+zeTY7UpEEdsOF vrOFyz8LiapMlg5DZnMExls4jF2WC+BTLj/TDrhg120eYTapPFFWVC8sFplsTGDZ obF/IoSPh2pQLA7Gh5lJmaw9QianzJ6RJNNVCLzQR43x/r9vRGA5xbMP77sGGDWr HZMUQw33v2gcU/EefHKv =wYgo -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-analyze-197 broken
On Wed, Jan 23, 2013 at 9:45 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 23.01.13 12:43, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Wed, Jan 23, 2013 at 12:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 23.01.13 12:03, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Tue, Jan 22, 2013 at 10:05 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Tue, Jan 22, 2013 at 7:33 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Jan 23, 2013 at 4:21 AM, Lennart Poettering Check if you have /sys/firmware/efi/efivars/LoaderTicksExec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f on your system. Yeah, gummiboot now exports readable values. But I guess the issue you see is just the kernel version ... nod... I was still on 3.6 :^) - time for a kernel upgrade. I'll do a full round - I really like where the C rewrite is going so I want to make sure it covers the EFI stuff properly. I just updated to 3.8rc4 and still don't see this value - gummiboot-15-1-g9112053. I assume it's still floating in some git repo? You need a very recent kernel to have the /sys/firmware/efi/efivars directory. And you need a very recent gummiboot to get the Loader* files in them. Do you see any Loader* files in there? both /sys/firmware/efi/efvars and Loader* entries are all there, e.g. LoaderVersion* has gummiboot 15 in it. I see Loader::ConfigTimeout, -DeviceIdentifier, -DevicePartUUID, -EntriesAuto/Default/Selected, -TimeExecUsec, -TimeInitUsec, -TimeMenuUsec and LoaderVersion maybe TicksExec is set conditionally? Nah, the Ticks stuff is just the old version of TimeExecUsec/TimeInitUsec. That's due to the rework Kay did regarding TSC vs. usec values. If you have these fields in the EFI vars then all you need is the current git version of systemd and systemd-analyze should show you firmware information. Right, it's only in systemd git now, the new variables. Sorry for the confusion. After we found out that even ACPI 5 will export timestamps in nanoseconds I felt really bad for just lazily exporting the raw TSC from the bootloader, and fixed it last night to export proper timestamps. Some things just need a little bit of competition to get people thinking and working. :) Should be all much better now, besides the confusion the new renaming has caused. Sorry for that again. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd and network devices under LXC?
I am running Linux under LXC. I have a systemd unit file for dhcpcd (a DHCP client) that includes: BindsTo=sys-subsystem-net-devices-eth0.device And indeed, eth0 exists and is functioning: # ip link show eth0 35: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 00:16:3e:05:24:4e brd ff:ff:ff:ff:ff:ff Systemd (197) does not appear to be aware of this interface, and ultimately gives up with the following error: Timed out waiting for device sys-subsystem-net-devices-eth0.device. This is what udevadm says about the interface: # udevadm info /sys/class/net/eth0 P: /devices/virtual/net/eth0 E: DEVPATH=/devices/virtual/net/eth0 E: IFINDEX=35 E: INTERFACE=eth0 E: SUBSYSTEM=net Why doesn't systemd know about this interface? I would like to avoid modifying the existing service file (because it will probably get tromped on by a package upgrade, and because having the service depdend on the network interface makes an awful lot of sense). I understand that this may be a udev problem, and there are posts out there indicating that udev had problems running in a container...but udev has since been folded into systemd, and systemd-udev at least *claims* to be running. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
