[systemd-devel] [PATCH] man: systemd-nspawn: Update syntax to launch an image

[Kashyap Chamarthy]

To access a shell on a disk image, the man page on Fedora-29 says to
run: `systemd-nspawn -M Fedora-Cloud-Base-28-1.1.x86_64.raw`.  Let's
try.

List existing images:

$> machinectl list-images | awk '{print $1,$2}';
NAME TYPE
Fedora-Cloud-Base-30… raw

1 images

Now invoke `systemd-nspawn` as noted in the man page:

$> systemd-nspawn -M Fedora-Cloud-Base-30-1.2.x86_64.raw
No image for machine 'Fedora-Cloud-Base-30-1.2.x86_64.raw'.

Removing the ".raw" extension launches the image and gives a shell.
Update the man page to reflect that.

Frantisek Sumsal on #systemd (Freenode) noted the reason: "In older
versions systemd -M accepted both image-name.raw and image-name as a
valid image names, however, on Fedora 29 (systemd-239) with all the
BTRFS stuff around it accepts only -M image-name (without the
extension)"

- - -

While at it, update the fedora_{latest_version, cloud_release}
variables.

Signed-off-by: Kashyap Chamarthy 
---
 man/systemd-nspawn.xml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
index 
5ba162b93cadf2fa3a252ddbb19b5b30315fa9d8..f1d6f14812519b6765078d71fcdb17853e4f85c1
 100644
--- a/man/systemd-nspawn.xml
+++ b/man/systemd-nspawn.xml
@@ -1,8 +1,8 @@
 
 http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"; [
-
-
+
+
 ]>
 
 
@@ -1343,7 +1343,7 @@
 
   # machinectl pull-raw --verify=no \
   
https://download.fedoraproject.org/pub/fedora/linux/releases/&fedora_latest_version;/Cloud/x86_64/images/Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64.raw.xz
-# systemd-nspawn -M 
Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64.raw
+# systemd-nspawn -M 
Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64
 
   This downloads an image using
   
machinectl1
-- 
2.20.1

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

Re: [systemd-devel] [PATCH] journalctl: allow customizable output formats

[Kashyap Chamarthy]

[Strangely, this thread up in my inbox rather than my systemd Maildir.]

On Mon, Sep 22, 2014 at 12:43:28PM -0400, Daurnimator wrote:
> On 22 September 2014 11:33, Daniel P. Berrange  wrote:
> 
> > The current '--output FORMAT' argument defines a number of
> > common output formats, but there are some useful cases it
> > does cover. In particular when reading application logs it
> > is often desirable to display the code file name, line number
> > and function name. Rather than defining yet more fixed output
> > formats, this patch introduces user defined output formats.
> >
> > The format string is an arbitrary string which contains a
> > mixture of literal text and variable subsistitions. Each
> > variable name corresponds to a journal field name. A variable
> > name can be optionally followed by a data type, and in the
> > case of string types, a length limit.
> >
> 
> As an opposing point of view, I've been accomplishing this by piping
> output through a script that parses and displays JSON.  I rather this
> style of composability than passing format strings to journalctl
> itself.

FWIW, as a heavy user and frequent tester of libvirt, I'd absolutely
welcome the proposed change which clearly illustrated what I wished for
(code file, line, function name & the error string) at times when
debugging myself or helping others debug. When at a critical time, I'd
rather much depend on `journalctl` having such a useful option handy
than depending on yet another random script from the inter-webs.

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

Re: [systemd-devel] stopping a systemd-nspwan container

[Kashyap Chamarthy]

On Sat, Mar 22, 2014 at 04:35:19PM +0200, Kevin Wilson wrote:
> Hello,
> 
> I had created a container according to systemd-nspwan man page and
> ran it by:
> systemd-nspawn -D/srv/mycontainer
> 
> I killed it by  pkill systemd-nspaw (and not by poweroff from within the
> container).
> 
> Now, running "machinectl" shows that the container still runs:
> machinectl
> MACHINE  CONTAINER SERVICE
> mycontainer  container nspawn
> 
> 1 machines listed.
> 
> but the following is strange:
> 
> Running:
> systemd-nspawn -D/srv/mycontainer
> gives:
> Spawning namespace container on /srv/mycontainer (console is /dev/pts/2).
> Init process in the container running as PID 2305.
> Failed to register machine: File exists
> Container failed with error code 239.
> 
> (and running it again gives the same result but with a different pid
> number).
> 
> Is there a way to shut down the container which is running in such a
> scenario ?

Hmm, I'm able to shut it down gracefully. I frequently do package builds
in systemd-nspawn.

Reading your email, I did this below test:

On one terminal:

$ systemd-nspawn -D /srv/testcontainer
Spawning container testcontainer on /srv/testcontainer. Press ^] three
times within 1s to abort execution.


On another terminal, invoke machinectl:

$ machinectl 
MACHINE  CONTAINER SERVICE 
testcontainercontainer nspawn  

1 machines listed.


Kill the systemd-nspawn process:

$ pkill systemd-nspawn 


At this point, on the other terminal you see KILL signal invokcation:

[. . .]
-bash-4.2# 
Container testcontainer terminated by signal KILL.
$ 


Invoke machinectl again:

$ machinectl 
MACHINE  CONTAINER SERVICE 

0 machines listed.

$ machinectl status testcontainer
Could not get path to machine: No machine 'testcontainer' known
$ 


Versions:

$ uname -r; rpm -q systemd
3.13.4-200.fc20.x86_64
systemd-210-7.fc21.x86_64


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