Re: Reparenting processes?
On Tue, Dec 8, 2020 at 16:06 bch wrote: > > > On Tue, Dec 8, 2020 at 15:36 bch wrote: > >> >> >> On Tue, Dec 8, 2020 at 13:05 Mouse wrote: >> >>> >> [...process reparenting...] >>> > Isn't what you want to do very similar to what happens when a process >>> > goes into background and the parent dies? >>> >>> Yes. Between that and the partial reparenting that happens at debugger >>> attach, most of the code I want already exists. >>> >>> The pieces that don't are things like dealing with control ttys and >>> sessions (reparenting orphaned processes to init deals with those, but >>> only in the form of setting them to a suitable "cleared" state; I would >>> want something more). >> >> >> >> ISTR NetBSD shipped (ships? I can’t find it on cursory glance) a >> slimmed-down process controller (“slimmed-down” vs tmux or screen w their >> myriad options and features) process handler - I want to say “detach”, but >> I’m not certain. >> > > Or “window”? What I’m remembering was definitely for a console, though, > and super basic. > Apologies for replying to my own msgs. The software I was thinking of is window(1), which for NetBSD 7 was taken out of base and moved to pkgsrc/misc/window, according to src/doc/CHANGES.prev -bch > >> -bch >> >> >>> >>> /~\ The ASCII Mouse >>> \ / Ribbon Campaign >>> X Against HTMLmo...@rodents-montreal.org >>> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B >>> >>
Re: Reparenting processes?
On Tue, Dec 8, 2020 at 15:36 bch wrote: > > > On Tue, Dec 8, 2020 at 13:05 Mouse wrote: > >> >> [...process reparenting...] >> > Isn't what you want to do very similar to what happens when a process >> > goes into background and the parent dies? >> >> Yes. Between that and the partial reparenting that happens at debugger >> attach, most of the code I want already exists. >> >> The pieces that don't are things like dealing with control ttys and >> sessions (reparenting orphaned processes to init deals with those, but >> only in the form of setting them to a suitable "cleared" state; I would >> want something more). > > > > ISTR NetBSD shipped (ships? I can’t find it on cursory glance) a > slimmed-down process controller (“slimmed-down” vs tmux or screen w their > myriad options and features) process handler - I want to say “detach”, but > I’m not certain. > Or “window”? What I’m remembering was definitely for a console, though, and super basic. > -bch > > >> >> /~\ The ASCII Mouse >> \ / Ribbon Campaign >> X Against HTMLmo...@rodents-montreal.org >> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B >> >
Re: Reparenting processes?
On Tue, Dec 8, 2020 at 13:05 Mouse wrote: > >> [...process reparenting...] > > Isn't what you want to do very similar to what happens when a process > > goes into background and the parent dies? > > Yes. Between that and the partial reparenting that happens at debugger > attach, most of the code I want already exists. > > The pieces that don't are things like dealing with control ttys and > sessions (reparenting orphaned processes to init deals with those, but > only in the form of setting them to a suitable "cleared" state; I would > want something more). ISTR NetBSD shipped (ships? I can’t find it on cursory glance) a slimmed-down process controller (“slimmed-down” vs tmux or screen w their myriad options and features) process handler - I want to say “detach”, but I’m not certain. -bch > > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTMLmo...@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B >
Re: Reparenting processes?
>> [...process reparenting...] > Isn't what you want to do very similar to what happens when a process > goes into background and the parent dies? Yes. Between that and the partial reparenting that happens at debugger attach, most of the code I want already exists. The pieces that don't are things like dealing with control ttys and sessions (reparenting orphaned processes to init deals with those, but only in the form of setting them to a suitable "cleared" state; I would want something more). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Reparenting processes?
hello. Isn't what you want to do very similar to what happens when a process goes into background and the parent dies? I.e. its parent gets reassigned to init, pid 1. That's a special case, but it seems like you could create a syscall that does that work and as long as the target parent is the same uid as the calling process, you should be able to re-use a lot of the code that does that inheritance for backrounded processes. Then, when the new parent does a wait, it just gets the pid of the newly transfered child, assuming the child exits at some point. Just a thought. -Brian On Dec 8, 2:36pm, Mouse wrote: } Subject: Re: Reparenting processes? } > One complication I can think of: what happens to the original parent process$ } } If the original parent is not in a wait() at the time, I don't see this } as an issue; the child just evaporates. (See below.) } } If the original parent is in a wait(), and this is either its last } child or it is specifically being waited for (either by pid or pgid), } I'm not sure. I'd have to think about that. Possibly a new wait } status (WIFREPARENTED?). Possibly it just turns into whatever would } have happened if the wait*() had been done immediately after the } reparenting. Possibly something else. } } The new parent learning about the new child is not something I've been } worried about, because what I've been imagining requires active } collaboration between the old and new parents for the move to happen at } all, meaning that each parent is expecting the change and can update } whatever internal data structures it needs to. } } Yes, post-reparenting, the new parent can wait for the child just like } any other child it (then) has. } } /~\ The ASCII Mouse } \ / Ribbon Campaign } X Against HTML mo...@rodents-montreal.org } / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B >-- End of excerpt from Mouse
Re: Reparenting processes?
> One complication I can think of: what happens to the original parent process$ If the original parent is not in a wait() at the time, I don't see this as an issue; the child just evaporates. (See below.) If the original parent is in a wait(), and this is either its last child or it is specifically being waited for (either by pid or pgid), I'm not sure. I'd have to think about that. Possibly a new wait status (WIFREPARENTED?). Possibly it just turns into whatever would have happened if the wait*() had been done immediately after the reparenting. Possibly something else. The new parent learning about the new child is not something I've been worried about, because what I've been imagining requires active collaboration between the old and new parents for the move to happen at all, meaning that each parent is expecting the change and can update whatever internal data structures it needs to. Yes, post-reparenting, the new parent can wait for the child just like any other child it (then) has. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Reparenting processes?
> On Dec 8, 2020, at 8:01 AM, i...@netbsd.org wrote: > > > [EXTERNAL EMAIL] > > On Mon, Dec 07, 2020 at 08:54:33PM -0500, Mouse wrote: >> I've been thinking about building a way to move a job between shells, >> in particular between one window, ssh session, whatever, and another. > > Yes, I've somehow missed the VMS virtual terminals, that can detach > their job from the real terminal and be reattached by a login process, > instead of creating a new job. I didn't know that VMS had this, but certainly you can find that feature in the DEC PDP-11 operating system RSTS/E. And that may have been borrowed from older OSs like TSS-8 or TOPS-10. One complication I can think of: what happens to the original parent process wait for child exit syscall, if the child detaches? I assume it returns; does it return with a new completion value that means "the process isn't actually done but it detached"? Similarly, how does the new parent learn about the new child, and can it then wait for it? paul
Re: Reparenting processes?
On 2020-12-08 14:36, Mouse wrote: I've been thinking about building a way to move a job between shells, in particular between one window, ssh session, whatever, and another. Yes, I've somehow missed the VMS virtual terminals, that can detach their job from the real terminal and be reattached by a login process, instead of creating a new job. That must have come in after I stopped using VMS (mid-'80s); I'm pretty sure the VMS I used didn't have it. It actually don't have anything to do with virtual terminals, but the mechanism did exist already then. Jobs could be detached and reattached again, including at login. But it was/is a little obscure in VMS. It is much more prominent, and easy to deal with in TOPS-20. (Now back to on topic... :-) ) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Reparenting processes?
>> I've been thinking about building a way to move a job between >> shells, in particular between one window, ssh session, whatever, and >> another. > Yes, I've somehow missed the VMS virtual terminals, that can detach > their job from the real terminal and be reattached by a login > process, instead of creating a new job. That must have come in after I stopped using VMS (mid-'80s); I'm pretty sure the VMS I used didn't have it. > (screen and tmux have lessened this desire to a high degree.) Not surprising. :-) >> But the real bugaboo in my mind is reparenting processes. > Why do you need this? I think that (get|set)pg(rp|id)() and > tcgetpgrp()/tcsetpgrp() should be enough to do job manipulation. Reparenting is semi-necessary in order for wait*() to work right. Also, if you can move a stopped setuid job, the carveout for sending SIGCONT to any descendant needs to apply. And the job's control tty needs to change so it can interact with the tty expected by the new shell. It probably should change session, too. >> The other is: is there any security property that such a facility >> would break badly? > One that I can think of: if you are able to change your parent to one > of your indirect children, functions traversing the process tree > would either not find you (and your decendants) or run in an infinite > loop. Certainly; I was expecting to forbid parenting loops. (This is one of the respects in which ptrace()'s reparenting is only partial; debuggers can attach to their process-tree ancestors just fine.) > The other interesting question: what happens to a process that was > seperated by its child but still knows the id and plans some > operation on it? For my use cases, that is a non-issue; I expect this to happen only with the cooperation and collaboration of both parents. The old parent can operate on the former child after the move only to the extent that it could operate on a similar child forked by the new parent. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Reparenting processes?
On Mon, Dec 07, 2020 at 08:54:33PM -0500, Mouse wrote: > I've been thinking about building a way to move a job between shells, > in particular between one window, ssh session, whatever, and another. Yes, I've somehow missed the VMS virtual terminals, that can detach their job from the real terminal and be reattached by a login process, instead of creating a new job. (screen and tmux have lessened this desire to a high degree.) > Obviously, this will involve much hackery of existing facilities. For > example, it involves switching controlling terminals. I expect I can > manage most of it without too much trouble - though that's said without > having actually tried it. > > But the real bugaboo in my mind is reparenting processes. Why do you need this? I think that (get|set)pg(rp|id)() and tcgetpgrp()/tcsetpgrp() should be enough to do job manipulation. > The other is: is there any security property that such a facility would > break badly? One that I can think of: if you are able to change your parent to one of your indirect children, functions traversing the process tree would either not find you (and your decendants) or run in an infinite loop. (Needs traversing the new parent's parent chain up, make sure the moving process is not there, (and maybe for good measure, that we arrive at 1), all with a lock held.) The other interesting question: what happens to a process that was seperated by its child but still knows the id and plans some operation on it? -is
Re: Problems with hdaudio(4) on Dell Optiplex-5050
> [I]f a stereo headphone is plugged in to the jack on the fron tof the > machine, the audio switches to that jack, but the two channels are > mixed together in such a way as to cause them to cancel each other > out on each headphone. I'll suggest another possible cause, if I've understood the symptom correctly. Stereo headphones use three conductors: one ear signal, the other ear signal, and common ground. I have occasionally had the ground connection break (usually for fixable reasons, in my cases). This causes the electrical circuit to amount to both ears in series between the two signal conductors, leading to an effectively monaural sound that amounts to the difference between the two channels. If there's a defect in the jack or its connections (which I can imagine being common across a product line or manufacturer), this could at least potentially be responsible for the symptom you're hearing. Of course, it also could be software, as you suggest. One experiment that might help resolve this occurs to me. When I've had a machine crash while playing sound, it usually keeps playing the last short time (50ms?) in a loop. If you break to ddb while sound is playing, I'd expect the same thing to happen. In that state, the driver isn't going to be changing anything, so plugging headphones in then might help you identify whether it's a software issue or not. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Problems with hdaudio(4) on Dell Optiplex-5050
hello. I'm trying to get the audio headphone jack working properly on an Dell Optiplex 5050 with NetBSD-9.1 with sources from December 2, 2020. When sound comes through the built-in speaker, all works fine. However, if a stereo headphone is plugged in to the jack on the fron tof the machine, the audio switches to that jack, but the two channels are mixed together in such a way as to cause them to cancel each other out on each headphone. I think what's going wrong is something like the following: 1. When the sound card comes up, the speaker is the active device, so both channels are combined to drive the speaker, monaural mode. Then, when a headphone is plugged in, the sound card is switched to two channels, but the two channels are still mixed. From what I gather reading the source, the initial set up is how the BIOS sets things up, so the driver just leaves things as they are and switches the output from speaker to headphone when the headphone is connected. I've seen reports of similar problems with the NetBSD driver and other Dell models, so I'm confident it's a software problem. I looked at the FreeBSD-12 driver to see what they do, and it appears they attach all the jacks as different devices, but they also don't seem to switch modes, so their driver might have the same issue. Does anyone have any ideas what I should look at to resolve this issue? -thanks -Brian NetBSD 9.1_STABLE (GENERIC) #0: Mon Dec 7 14:11:20 PST 2020 buh...@loth-9.nfbcal.org:/usr/local/netbsd/src-90/sys/arch/amd64/compile/GENERIC . . . hdaudio0 at pci0 dev 31 function 3: HD Audio Controller hdaudio0: interrupting at msi2 vec 0 hdafg0 at hdaudio0: vendor 10ec product 0255 hdafg0: DAC00 2ch: Speaker [Jack] hdafg0: 2ch/0ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3 audio0 at hdafg0: playback, capture, full duplex, independent audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for playback audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for recording spkr0 at audio0: PC Speaker (synthesized) wsbell at spkr0 not configured hdafg1 at hdaudio0: vendor 8086 product 2809 hdafg1: DP00 8ch: Digital Out [Jack] hdafg1: 8ch/0ch 48000Hz PCM16* -thanks -Brian
