Hurd Traffic

James Morrison Roland McGrath

Jeff Bailey also had problems with "su", which appeared to hang. James Morrison said that he too had seen this problem and Marcus Brinkmann had said that it was due to pflocal gettting in a tangle - kill pflocal and things get unstuck. Jeff noticed that in his case, a pile of stuck cron's to get unstuck also.

Roland McGrath said that the pflocal problem was a known issue, but noone had yet worked out why or fixed it.

Conversation moved to the subject more info about sudo/pflocal/syslogd problem) where Marcus added:

There seem to be a couple of issues. First, it seems that sudo and pflocal/libpipe seem to work fine in the normal case. What happens is that sudo sends a diagnostic line to syslogd. syslogd receives only one line, logs it, and on receiving the second line (?) then goes into foobar mode.

After enough sudos, the pipe buffer will be full (16kb), and the subsequent sends will hang in pflocal, because the writing thread will wait for the buffer to empty a bit. There seems to be a bug here, because if you now kill syslogd, the writing thread will not wake up rather than getting a broken pipe or whatever. I also had pflocal crashing when restarting syslogd in this situation, but that does not seem to be reproducible.

So at least two bugs involved here? It seems so.

Marcus added further:

It was instructive to step through syslogd. What happens is that syslogd listens on a unix and an inet socket with poll. poll returns revents 1 for unix and 3 for inet socket (POLLIN and POLLIN|POLLPRI. So syslogd will try to get a line from the unix socket (works) and then from the inet socket, which hangs as there is no data.

So glibc returns the wrong values in revents for poll. I am now going to look into glibc select code.

Marcus had some trouble running gdb with glibc, but later found a problem in hurd/hurdselect.c

Roland said that he fixed this in his tree and checked it in.

EOT.

Apt Thomas Bushnell Marcus Brinkmann

James Morrison thought that it would be a good idea to gather together hurd-related items, such as shadowfs, {u}random translator, colortext and pptop and suggested a Debian GNU/Hurd package for them.

Thomas Bushnell and Marcus Brinkmann thought that they should go into the main Hurd source base when they work satisfactorily.

James replied that he realised that they were not currently ready to be part of the Hurd, adding I think it would be cool to go apt-get source|install hurd-toys and have whatever isn't done.

Jeff Bailey

Jeff Bailey let us know that the current autobuild status can be found at people.debian.org/~jbailey/buildd/index.php.

James Morrison Jeff Bailey

Jeff Bailey said that buildd seemed to get stuck on 'chess'. James Troup said it's just that chess takes a long time to build and David Trudgett said it took something like two days to compile on a Pentium 166. James Morrison also reported that it took two days and also noted a packaging bug.

Thomas Bushnell Roland McGrath Peter Bruin

Following the recent announcement of a PowerPC port, Peter Bruin posted his changes to glibc and put them on his web page. Roland McGrath started integrating the changes and Thomas Bushnell joined with Roland in thanking Peter for this exciting work.

POSIX

Noting that GNU 'find' uses st_nlink, Moritz Schulte asked is it ok if the st_nlink member of struct stat of virtual directory nodes in Shadowfs is higher then the number of nodes which are actually in that virtual directory? Roland McGrath replied:

By my reading of 1003.1-1996, st_nlink should be "the number of directory entries that refer to the file". In a case like this, I think it's pretty open to interpretation what constitutes a directory entry; there always might be extra entries in some directory you don't know about, and that is not distinguishable from st_nlink just being too high.

I'm also not entirely sure how kosher find's use of st_nlink on directories is, by the POSIX rules. I haven't done a thorough search, but `..' is described as a "special file name", and it is unspecified whether readdir returns entries for `.' and `..', so I tend to conclude that there is no requirement about `..' being a normal link as to contribute to the link count in a well-specified way.

All that leads me to conclude that all that matters is what makes find happy in practice. If it uses st_nlink to limit the number of entries in the directory it stats for directoriness, then an inflated count only makes it possibly less efficient and won't make it incorrect.

Note, however, that this optimization in find will quite totally break the filesystem semantics presented by translators set on regular files. That is, a translator set on a regular file may well report S_IFDIR and so a find ought to treat it as a directory. But the underlying node isn't a directory and so doesn't have a .. node contributing to the containing directory's link count.

Thomas Bushnell agreed that this was a problem with 'find' and that it should be reported as a bug (ideally with a patch). Thomas thought that st_nlink on a directory should be the number of subdirectories plus two, adding My thought has always been that an efficient shadow directory would scan the underlying directories once on startup, and after that would maintain correct information through the change-notification mechanism.

Moritz Schulte said that the was a completely different approach to the one that he had used, saying that to do things as Thomas suggested would need a complete re-write. Thomas added it is the reason for having the directory notification RPC's at all. (And also so that things like Emacs dired mode can automagically update.)