On Wednesday 21 February 2007 14:25, Jeroen van der Ham wrote:
> Blaisorblade wrote:
> > On Tuesday 20 February 2007 17:37, Jeff Dike wrote:
> >> On Tue, Feb 20, 2007 at 04:57:40PM +0100, Jeroen van der Ham wrote:
> >>> Is it possible to add an option to uml_switch so that it is completely
> >>> silent?
> >>
> >> It would be a matter of putting all the printf's under the control of
> >> such a switch - not a big deal.
> >>
> >>> I'm using UML as an educational tool to let students explore computer
> >>> networks. However, if we create a network that contains a loop then
> >>> uml_switch will start spamming all kinds of messages.
> >
> > It's not spam. Ignoring them was bad...
>
> I completely agree. But I *know* I'm doing a bad thing, but I still want
> to do it, what's more: I want to do it using a script. This means that
> currently I have to jump through all kinds of hoops, just to keep
> uml_switch's output buffer empty, so that it keeps on running.
Using > /dev/null 2>&1 is not suitable?
> After looking into this some more, it's not a big load on the terminal.
> There is no CPU load either, because other terminals work fine.
> The symptoms that I have is that the terminal I started the uml_switches
> on (in daemon mode) will intermittently miss keystrokes. So you type
> "screen" but you get "seen".
Also happens to me, with a single daemon not connected to anything ;-).
It was a bug of -daemon compared to < /dev/null. Just fixed in attached patch.
Please test it.
In fact, docs do not talk about '-daemon' - I was the first to document it
when happening to see it in sources. The web page says:
> uml_switch can be backgrounded as follows
> host% uml_switch [ options ] < /dev/null > /dev/null
> The reason it doesn't background by default is that it listens to stdin
> for EOF. When it sees that, it exits.
(and the suggestion is still wrong because it misses redirecting stderr.)
When output is redirected things like what you suppose shouldn't ever
happen... programs handling terminal (xterm, screen, ssh, etc.) cannot now
that output is being thrown to /dev/null; the shell could maybe in principle
but it shouldn't.
So I feared that uml_switch was indeed reading from stdin, and yes, it is.
Most times the shell wins when readying from the same fd, for some reason
obscure to me.
> Yes, STP would certainly be useful here. However, the whole point of the
> exercise is to show the students what happens when you *don't* have STP :)
Ok, sorry for thinking you did not know that.
> > And I can guess messages are continous "Addr: X New port Y", "Addr: X New
> > port Z", with the ports ever changing, right? Imagine a packet starting
> > from a computer, being flooded through the network by an uml_switch and
> > reentering this uml_switch after looping - uml_switch will not recognize
> > the duplication.
>
> Yes, but it's also spamming with messages that it cannot write to fd 4.
The attached patch should remove them too, but I didn't try to reproduce this
bug. Could you please post the exact error you are currrently getting so that
I now if I'm fixing the right thing? I think there's a (currently harmless)
bug there, since EAGAIN is not ignored and sockets are set as O_NONBLOCK.
Luckily it just prints a message, it does not close the socket for a write
failure.
Can you also look during that at what fd 4 is via ls /proc/$switch_pid/fd?
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Index: tools/uml_switch/port.c
===================================================================
--- tools.orig/uml_switch/port.c
+++ tools/uml_switch/port.c
@@ -182,9 +182,13 @@ static void send_sock(int fd, void *pack
err = sendto(mine->fd, packet, len, 0, (struct sockaddr *) &mine->sock,
sizeof(mine->sock));
- if(err != len){
- fprintf(stderr, "send_sock sending to fd %d ", mine->fd);
- perror("");
+ if(err != len) {
+ int saved_errno = errno;
+ if (saved_errno != EAGAIN) {
+ fprintf(stderr, "send_sock sending to fd %d ", mine->fd);
+ errno = saved_errno;
+ perror("");
+ }
}
}
Index: tools/uml_switch/uml_switch.c
===================================================================
--- tools.orig/uml_switch/uml_switch.c
+++ tools/uml_switch/uml_switch.c
@@ -524,7 +524,7 @@ int main(int argc, char **argv)
#endif
printf("\n");
- if(isatty(0))
+ if(isatty(0) && !daemonize)
add_fd(0);
add_fd(connect_fd);
add_fd(data_fd);
@@ -534,9 +534,16 @@ int main(int argc, char **argv)
if(tap_fd > -1) add_fd(tap_fd);
#endif
- if (daemonize && daemon(0, 1)) {
- perror("daemon");
- exit(1);
+ if (daemonize) {
+ int nullfd;
+ if (daemon(0, 1)) {
+ perror("daemon");
+ exit(1);
+ }
+ nullfd = open("/dev/null", O_RDONLY);
+ if (dup2(nullfd, 0))
+ perror("dup2 /dev/null to 0");
+ close(nullfd);
}
while(1){
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
