On Wed, 06.07.11 12:28, Richard W.M. Jones (rjones@redhat.com) wrote:
>
>
> I haven't tested this yet .. will do later today.
>
> But comments welcome on:
>
> http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=99-guestfsd.rules;h=ab4f6800bbd847307aceb2cb52e984524 eaee52c;hb=HEAD
> http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=guestfsd.service;h=482d 1e2bf1fb1c791e3adfe3f58716c38edb6b3d;hb=HEAD
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
07-06-2011, 12:35 PM
Lennart Poettering
systemd: Tagging /dev/virtio-ports/* for systemd
On Wed, 06.07.11 12:21, Richard W.M. Jones (rjones@redhat.com) wrote:
>
> On Tue, Jul 05, 2011 at 08:36:42PM +0200, Lennart Poettering wrote:
> > On Tue, 05.07.11 16:54, Daniel P. Berrange (berrange@redhat.com) wrote:
> > > [Service]
> > > ExecStart=-/usr/sbin/guestfsd
> >
> > Prefixing the binary path with "-" will result in the exit code of
> > guestfsd be ignored, i.e. we wouldn't put the service into failed state
> > if it crashes (or exits otherwise abnormally). I'd encourage never to
> > prefix with "-" unless you have a really good reason to.
>
> In this case, I think we do. The daemon only handles one connection
> at a time (that is the nature of virtio-serial ports) and it will exit
> with EXIT_FAILURE if an error is read in the protocol. This can
> happen in some legitimate-ish cases, eg. if the host side disconnects
> without "properly" closing the connection.
Wouldn't it make sense to fix the daemon to return EXIT_SUCCESS in those
legitimate-ish cases?
> But what we'd want to avoid is the case where the daemon dies during
> startup, and we get into a loop repeatedly relaunching the daemon.
systemd does not distuingish between failure-on-start and
failure-during-runtime.
> The question is, does systemd implement respawn throttling like inetd?
Yes, we rate limit almost everything. There's even a patch floating
around on our mailing list right now which we will probably merge pretty
soon which allows you to configure in a service how often we should
retry respawning the service before giving up, if it fails.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
07-06-2011, 12:49 PM
"Daniel P. Berrange"
systemd: Tagging /dev/virtio-ports/* for systemd
On Wed, Jul 06, 2011 at 02:27:58PM +0200, Lennart Poettering wrote:
> On Wed, 06.07.11 10:22, Daniel P. Berrange (berrange@redhat.com) wrote:
>
> > > So, I am a bit confused now after reading this:
> > >
> > > http://fedoraproject.org/wiki/Features/VirtioSerial
> > >
> > > How does /dev/hvcxxx relate to these virtio ports?
> > >
> > > hvc ports are tagged "systemd" anyway in udev, so if this is the same
> > > thing, why do we have to tag the virtio ports too?
> > >
> > > Can you explain how hvc and virtio relate to each other and under which
> > > kernel device names they show up in udev and how they correspond?
> >
> > In QEMU, there is one PCI device "virtio-serial-pci". In QEMU's view this
> > device is a bus to which we then attach zero or more 'virtconsole' or
> > 'virtserialport' devices.
> >
> > The 'virtconsole' device is a paravirt text console, which appears as
> > /dev/hvcNNN in the guest. These are intended for interactive login and
> > would be expected to run a mingetty/agetty process.
>
> Hmm, but Unix does not really distuingish between serial ports and
> ttys. So what precisely is the difference in behaviour when I have
> opened a /dev/hvcXX and a /dev/vportXXX? What happens if start a getty
> on /dev/vportXXX? And why couldn't I use /dev/hvcXXX for fast data
> transfer, too?
There's not really any functional difference between them once open.
The difference is is really about providing hints to the guest OS as
to how to configure the devices "out of the box"
The goal for the virtconsole devices was that a guest OS can just
automatically start a getty on every /dev/hvcXXX device it finds.
So a host admin can just add console devices to a guest config and
get a login without any extra guest OS configuration work.
The virtserial devices meanwhile have a admin defined name associated
with them to (in my example 'org.libguestfs.channel.0') so guest OS
agents can have a predictable way to identify which ports have been
exposed from the host for their use.
eg, consider if two guest agents 'guestfsd' and 'matahari' both wanted
to run in a guest and we were using just /dev/hvcXXX devices. There'd
be no way for them to decide which of /dev/hvc0, /dev/hvc1 applied
was theirs. With virtserial devices having a stable name, they can see
which is which device immediately.
> Or is the only difference on the host side? i.e. the destinction between
> access via pty and access via sockets?
No, that was just two example configs - the range of host side config
options is the same for both, with exception that virtserial devices
have an additional 'name' associated with them which maps to the device
/dev/virtio-ports/$NAME in Linux guests.
On Wed, Jul 06, 2011 at 02:35:13PM +0200, Lennart Poettering wrote:
> Wouldn't it make sense to fix the daemon to return EXIT_SUCCESS in those
> legitimate-ish cases?
It's probably just me but I find code that does this slightly
repugnant:
if (some_syscall() == -1) {
perror ("some_syscall");
exit (EXIT_SUCCESS);
}
There are a large number of places in the code which we would need to
examine and possibly change.
I think as long as systemd is doing rate-limiting, we should be fine.
The daemon is heavily tested anyway and hasn't so far failed at
start-up time ...
Anyway, I'm going to test it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
07-06-2011, 01:35 PM
"Richard W.M. Jones"
systemd: Tagging /dev/virtio-ports/* for systemd
On Wed, Jul 06, 2011 at 02:35:13PM +0200, Lennart Poettering wrote:
> Wouldn't it make sense to fix the daemon to return EXIT_SUCCESS in those
> legitimate-ish cases?
It's probably just me but I find code that does this slightly
repugnant:
if (some_syscall() == -1) {
perror ("some_syscall");
exit (EXIT_SUCCESS);
}
There are a large number of places in the code which we would need to
examine and possibly change.
I think as long as systemd is doing rate-limiting, we should be fine.
The daemon is heavily tested anyway and hasn't so far failed at
start-up time ...
Anyway, I'm going to test it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
07-06-2011, 01:35 PM
"Richard W.M. Jones"
systemd: Tagging /dev/virtio-ports/* for systemd
On Wed, Jul 06, 2011 at 02:35:13PM +0200, Lennart Poettering wrote:
> Wouldn't it make sense to fix the daemon to return EXIT_SUCCESS in those
> legitimate-ish cases?
It's probably just me but I find code that does this slightly
repugnant:
if (some_syscall() == -1) {
perror ("some_syscall");
exit (EXIT_SUCCESS);
}
There are a large number of places in the code which we would need to
examine and possibly change.
I think as long as systemd is doing rate-limiting, we should be fine.
The daemon is heavily tested anyway and hasn't so far failed at
start-up time ...
Anyway, I'm going to test it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
systemd: Tagging /dev/virtio-ports/* for systemd
