date:20130716

[systemd-devel] [PATCH v2] detect-virt: detect User-Mode Linux

2013-07-16 Thread Ramkumar Ramachandra

In a User-Mode Linux session:

  $ systemd-detect-virt
  none

Although it is possible to reliably detect virtualization:

  $ cat /proc/cpuinfo
  processor   : 0
  vendor_id   : User Mode Linux
  model name  : UML
  mode: skas
  host: Linux kytes 3.11.0-rc1-9-ge5fd680 (...)
  bogomips: 7007.43

So, grep for the string vendor_id\t: User Mode Linux\n in
/proc/cpuinfo, and say uml when asked.

Cc: Lennart Poettering lenn...@poettering.net
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 See arch/um/kernel/um_arch.c:75, where it writes the hard-coded
 string vendor_id\t: User Mode Linux\n.  No variable-width padding,
 so it should be safe to grep for this exact string.

 Also tweaked documentation.

 man/systemd-detect-virt.xml |  1 +
 src/shared/virt.c   | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml
index 762b6ab..f21493df 100644
--- a/man/systemd-detect-virt.xml
+++ b/man/systemd-detect-virt.xml
@@ -70,6 +70,7 @@
 varnamemicrosoft/varname,
 varnameoracle/varname, varnamexen/varname,
 varnamebochs/varname, varnamechroot/varname,
+varnameuml/varname,
 varnameopenvz/varname, varnamelxc/varname,
 varnamelxc-libvirt/varname,
 varnamesystemd-nspawn/varname./para
diff --git a/src/shared/virt.c b/src/shared/virt.c
index 1c86a3d..6114b6c 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -67,6 +67,7 @@ int detect_vm(const char **id) {
 const char *j, *k;
 bool hypervisor;
 _cleanup_free_ char *hvtype = NULL;
+_cleanup_free_ char *cpuinfo_contents = NULL;
 int r;
 
 /* Try high-level hypervisor sysfs file first:
@@ -164,6 +165,16 @@ int detect_vm(const char **id) {
 }
 
 #endif
+
+/* Detect User-Mode Linux by reading /proc/cpuinfo */
+r = read_full_file(/proc/cpuinfo, cpuinfo_contents, NULL);
+if (r  0)
+return r;
+if (strstr(cpuinfo_contents, vendor_id\t: User Mode Linux\n)) {
+*id = uml;
+return 1;
+}
+
 return 0;
 }
 
-- 
1.8.3.2.736.g869de25

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] man: use HTTPS links for links that support it

2013-07-16 Thread Jason St. John

From: Jason St. John jstj...@purdue.edu

---
 man/binfmt.d.xml   |  2 +-
 man/journald.conf.xml  |  2 +-
 man/machine-id.xml |  2 +-
 man/os-release.xml |  2 +-
 man/sd-id128.xml   |  2 +-
 man/systemd.cgroup.xml | 20 ++--
 man/systemd.exec.xml   |  6 +++---
 man/systemd.xml|  2 +-
 8 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml
index 7f31b76..f4f4195 100644
--- a/man/binfmt.d.xml
+++ b/man/binfmt.d.xml
@@ -67,7 +67,7 @@
 
 paraEach file contains a list of binfmt_misc kernel
 binary format rules. Consult ulink
-
url=http://www.kernel.org/doc/Documentation/binfmt_misc.txt;binfmt_misc.txt/ulink
+
url=https://www.kernel.org/doc/Documentation/binfmt_misc.txt;binfmt_misc.txt/ulink
 for more information on registration of additional
 binary formats and how to write rules./para
 
diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index 5986d61..487e8d6 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -133,7 +133,7 @@
 command), forward secure sealing (FSS)
 for all persistent journal files is
 enabled. FSS is based on ulink
-url=http://eprint.iacr.org/2013/397;Seekable
+url=https://eprint.iacr.org/2013/397;Seekable
 Sequential Key Generators/ulink by
 G. A. Marson and B. Poettering and
 may be used to protect journal files
diff --git a/man/machine-id.xml b/man/machine-id.xml
index b037e47..4b4759e 100644
--- a/man/machine-id.xml
+++ b/man/machine-id.xml
@@ -93,7 +93,7 @@
 
 paraNote that the machine ID historically is not an
 OSF UUID as defined by ulink
-url=http://tools.ietf.org/html/rfc4122;RFC
+url=https://tools.ietf.org/html/rfc4122;RFC
 4122/ulink, nor a Microsoft GUID; however, starting with
 systemd v30, newly generated machine IDs do
 qualify as v4 UUIDs./para
diff --git a/man/os-release.xml b/man/os-release.xml
index d714b51..045dd08 100644
--- a/man/os-release.xml
+++ b/man/os-release.xml
@@ -241,7 +241,7 @@
 
 listitemparaA CPE name for the
 operating system, following the ulink
-
url=http://cpe.mitre.org/specification/;Common
+
url=https://cpe.mitre.org/specification/;Common
 Platform Enumeration
 Specification/ulink as proposed by
 the MITRE Corporation. This field
diff --git a/man/sd-id128.xml b/man/sd-id128.xml
index 02fb76b..3a5e133 100644
--- a/man/sd-id128.xml
+++ b/man/sd-id128.xml
@@ -71,7 +71,7 @@
 process and generate 128-bit ID values. The 128-bit ID
 values processed and generated by these APIs are a
 generalization of OSF UUIDs as defined by ulink
-url=http://tools.ietf.org/html/rfc4122;RFC
+url=https://tools.ietf.org/html/rfc4122;RFC
 4122/ulink but use a simpler string
 format. These functions impose no structure on the
 used IDs, much unlike OSF UUIDs or Microsoft GUIDs,
diff --git a/man/systemd.cgroup.xml b/man/systemd.cgroup.xml
index e31faf5..bb0cb1c 100644
--- a/man/systemd.cgroup.xml
+++ b/man/systemd.cgroup.xml
@@ -127,7 +127,7 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   controls the literalcpu.shares/literal control group
   attribute, which defaults to 1024. For details about this
   control group attribute, see ulink
-  
url=http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt;sched-design-CFS.txt/ulink./para
+  
url=https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt;sched-design-CFS.txt/ulink./para
 
   paraImplies literalCPUAccounting=true/literal./para
 /listitem
@@ -152,7 +152,7 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   literalmemory.soft_limit_in_bytes/literal control group
   attributes. For details about these control group attributes,
   see ulink
-  
url=http://www.kernel.org/doc/Documentation/cgroups/memory.txt;memory.txt/ulink./para
+  
url=https://www.kernel.org/doc/Documentation/cgroups/memory.txt;memory.txt/ulink./para
 
   paraImplies literalMemoryAccounting=true/literal./para
 /listitem
@@ -172,7 +172,7 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
 defaults to 1000. For details about
 this control group

Re: [systemd-devel] runtime directories for services vs. tmpfiles

2013-07-16 Thread Colin Guthrie

'Twas brillig, and Michael Biebl at 16/07/13 02:24 did gyre and gimble:
 Hi,
 
 an interesting issue was raised as part of reviewing a patch for
 iodione [1], a system service which needs a runtime directory. We
 thought this might need further dicussion, so reposting the issue to
 systemd-devel:
 
 For system services needing a runtime directory, we basically have two
 (three) options nowadays
 1/ use ExecStartPre=/usr/bin/mkdir /var/run/foo
 2/ use a tmpfile snippet
 (3/ let the daemon create the runtime directory itself)
 
 In [1] we recommended the the usage of 2/ over 1/.
 The main reason for that were, that systemd-tmpfiles properly handles
 applying security policies, like SELinux labels, and it avoids
 spawning unnecessary processes (every ExecStartPre=/usr/bin/mkdir is a
 separate process)
 
 Zbyszek is arguing, that splitting the configuration over two files, a
 tmpfile and  a service file, complicates things for the administrator,
 as things are no longer in a single place.
 He also argues, that tmpfiles are active, independently of the
 service, which needs them. Which can lead to unused runtime
 directories.
 
 One suggestion that came up was, to specficy runtime directories in a
 declarative fashion in the .service file itself, which means it would
 be only be created if the service itself is enabled.
 
 I think this idea warrants further discussion, so I'm posting it here.

Hmmm, I can certainly see the argument, but it would be a shame to have
multiple ways to achieve the same goal through different places too (it
makes the documentation case much more confusing).

There is also an argument that on first install, one has to call
systemd-tmpfiles --create $BASENAME in a %post script to ensure the
necessary dirs are created. If it was all built in to the service this
would be fine.

So I see a few options.

1. Bake it into systemd unit syntax and handle it internally.
2. Bake it in as a noop directive and have a generator parse it out and
then write out /run/tmpfiles.d/ snippets and let systemd-tmpfiles work
with that.
3. Keep the status quo.

I don't really like option 2 there - seems unnecessary overhead. But
then option one (which presumably would see the tmpfiles code being
libified and linked to from systemd itself) doesn't seem amazing too.

I guess I don't really have a major problem with either 1 or 3 to be
honest. I can see arguments for both.

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] Unbuffered stderr for my systemd service?

2013-07-16 Thread Kay Sievers

On Tue, Jul 16, 2013 at 5:30 AM, WANG Chao chaow...@redhat.com wrote:

 (Humm, please do not use -- on a single line in the middle of an
 email, that's indication for many MUAs that this is where the signature
 starts, and they chop this off when replying...)

 Sorry about --, never thought that would be an issue. Thanks for
 telling!

It would only happen on _really_ broken mail programs, because the
convention includes a trailing space character which you didn't add.
The delimiter line is defined as -- .

  http://tools.ietf.org/html/rfc3676#section-4.3

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unbuffered stderr for my systemd service?

2013-07-16 Thread Kay Sievers

On Tue, Jul 16, 2013 at 5:30 AM, WANG Chao chaow...@redhat.com wrote:
On 07/15/13 at 10:46pm, Lennart Poettering wrote:
On Mon, 15.07.13 17:56, WANG Chao (chaow...@redhat.com) wrote:

I have a service (a script) running under systemd and need its stderr to
be output'd immediately, not line buffered. I tried serveral ways but
didn't work out. I hope to get some feedback here :)

This is not supported. Logging doesn't deal in individual
characters, really, but in log lines. Syslog doesn't do that, and
neither does the Journal.

And we will never support that, as allowing this would require us to
always store the context a character was printed in so that lines could
later be reassembled. But we cannot really do that.

So, I fear I have to tell you that this is not supported and never
will...

I understand that. Record the context of a character is printed would
never be a good idea. But still, I feel pity about line buffered stderr
stream in Journal :(

It is the right thing to buffer just buffer them to full lines.

For the kernel counterpart, we added unbuffered console magic to the
kernel. It is really nasty and broken hack and really makes not much
sense in th eend. The code does work in the most common case, but just
does stupid things as soon as things start to compete about the log.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=084681d14e429cb6192262ac7437f00e2c02f26a

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eab072609e11a357181806ab5a5c309ef6eb76f5

Pretending to support pushing animations through a log system is a
pretty bad idea and relies on technical promises nobody can really
hold without inventing something that isn't logging anymore. But we
have that already, it's the console. :)

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] runtime directories for services vs. tmpfiles

2013-07-16 Thread Tom Gundersen

Hi Michael,

On Tue, Jul 16, 2013 at 3:24 AM, Michael Biebl mbi...@gmail.com wrote:
 an interesting issue was raised as part of reviewing a patch for
 iodione [1], a system service which needs a runtime directory. We
 thought this might need further dicussion, so reposting the issue to
 systemd-devel:

 For system services needing a runtime directory, we basically have two
 (three) options nowadays
 1/ use ExecStartPre=/usr/bin/mkdir /var/run/foo
 2/ use a tmpfile snippet
 (3/ let the daemon create the runtime directory itself)

 In [1] we recommended the the usage of 1/ over 2/.
 The main reason for that were, that systemd-tmpfiles properly handles
 applying security policies, like SELinux labels, and it avoids
 spawning unnecessary processes (every ExecStartPre=/usr/bin/mkdir is a
 separate process)

I think the current way of doing this (letting tmpfiles or the daemon
itself handle it) is for the best, for the reasons you mention. Also
because it means we only have one tool to create folders during early
boot.

 Zbyszek is arguing, that splitting the configuration over two files, a
 tmpfile and  a service file, complicates things for the administrator,
 as things are no longer in a single place.

Hm, that is a fair point, but we also have the dual argument: if we
add a new place to configure runtime dirs without removing the old
(which I suppose we can't), the admin will anyway have to look in both
places to figure out what is going on...

 He also argues, that tmpfiles are active, independently of the
 service, which needs them. Which can lead to unused runtime
 directories.

I suppose the concern here is speed? If it can be shown that there is
a real speed advantage of not creating unneeded directories I guess
that's something worth discussing (I must admit that would surprise me
though).

-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

70 matches

Mail list logo