IRC channel logs
2025-12-23.log
back to list of logs
<azert>if it is reproducible you can maybe tell us! <rrq>not sure; I've started from scratch... trying to debootstrap, and it appears to sprinkle translators that take issue when I want to get rid of them... is thre a tool to tell all pathnames with translators in a directory tree? <azert>rrq: shell scripting can do that for you <rrq>mmm, it fails with: find $top -exec showtrans '{}' ';' <rrq>locks up when it finds a /hurd/rumpdisk <azert>I often get locks when listing up directories with translators <azert>I think there are bugs on many levels <rrq>yeah; I don't know enough of it to go there I'm afraid <azert>my policy when using the Hurd is to stay away from translators as much I can <azert>let them do their job behind the scenes <rrq>mmm I have the two problems: to debootstrap successfully, and to remove the trial tree when it fails <azert>do you debootstrap from the Hurd or Linux? <azert>you might have the issue that showtrans activate passive translators. And currently having two rumpdisk active causes mayhem <azert>if that’s the case, those are two bugs <rrq>I was thinking there would be a tool to tell all translator pathnames, and then I could do things to them <rrq>ACTION need a break for a bit... <azert>but it’s just your shell script <rrq>hmm how do I get all translator pathnames? <rrq>.. without ativating them in the process? <azert>or you can try with xattr, but I don't know if it works <azert>but I don't think that the xattr api is implemented yet <azert>can you try the -xdev option on find? <azert>find $top -xdev -exec showtrans '{}' ';' <rrq>would you mind review and possibly tell me what's wrong.. it ends up hanging <rrq>just a showtrans, then follow any dircetory except . and .. <azert>looks all right, can you tell me when does it hangs? <rrq>ok.. I'll add traversal output ... <rrq>it's a mounted second disk and it stops in /mnt/lost+found ... must be due to the "find" <azert>lost+found is just some normal files <rrq>that disk is from a previous crashed round and I think it has a number of translators, including a /hurd/rumpdisk ... residue <azert>ok, but then you found a bug <rrq>I'll change to make a loop rather thn "find" <azert>because if it was a normal /hurd/rumpdisk lost node, then it would just report it as a translator <rrq>right. it looks like "find" tickles it enough to "activate" (?) <rrq>.. and same form some /hurd/term as well <azert>that didn't happen in other directories, right? <rrq>well I had the same problem in /mnt/dev <azert>then it is just find that tickles it <azert>you just wonder if it is a bug in "find" or in "ext2fs" <azert>even shell expansion might trigger this bug for my experience <azert>weirdest thing is that you can trigger a system crash even as a normal user, because passive services are started by the filesystem, you don't need to be root <azert>of course, one could claim that this is still root fault. Even on Linux if root would load a module with bugs that get triggered by a read on a certain node file, then the user would be able to crash the system similarly <rrq>now ended in a loop about /hurd/term: ... ttyp0 busy <rrq>(and I didn't capture the script befor testing :() <rrq>.. I had translated to use ls .. <azert>yes the issue should be in ls that triggers the translators instead of just working on the directory <azert>plus multiple bugs in the translators <rrq>now stops after printing /mnt/los+found ... so it must be ls.. console says "/hurd/term: /dev/ttyp0: Device or resource busy" <azert>but the ls issue is the most problematic in my experience <rrq>mmm I'll check "echo $x/*" although that will skip .-dirs <azert>something else you could do, is to take a BSD ls from like the version 1.0 of NetBSD and try fixing that <azert>nowadays 'ls' on debian does tons of worthless stuff <azert>graphical file managers are even worse <rrq>hmm I move the printing to before the symlink test and then got the actual pathname "/mnt/lost+found/#82618" <rrq>with showtrans: /hurd/term /dev/ptyp0 pty-master /dev/ttyp0 <rrq>seems that translator doesn't worry about its actual pathname, but only its "initial pathname" <azert>a passive translator it's akin to a symlink <azert>it stores the name of the actual executable in the xattrs <rrq>guessing: that /hurd/term instance was set up for /dev/ptyp0 but now it sits on /mnt/lost+found/#82618 <rrq>then it gets activated by (in linux terms) a "stat" call <azert>in theory, the translators should be able to detect that there is another running term and die graciously <rrq>yeah... I'm too blank about translators, but I wouldn't have thought anything at /mnt/lost+found/#82618 should worry about /dev/ptyp0 <rrq>ok I can move the symlink test to be after showtrans...should avoid that looping at least <rrq>that seems to traverse the whole disk .. and without trace print it tells me all translators ... <rrq>(and maybe ls works find too, if the problem was the symlink test) <rrq>yes, (and a bit faster) <azert>feels like checking if something is a symlink shouldn't trigger the translator underneat to me <rrq>though that doesn't consider "stacking" of translators .. a notion I read about and am guessing about what it means <rrq>and it uses "-o orphan" rather than "-g go away" which I guess is the right thing to clean up a failed debootstrap tree <rrq>ACTION past bedtime here :) Thanks for discussing/guiding me