systemdlete | xorg refuses to die, even will SIGKILL | 00:00 |
---|---|---|
systemdlete | its parent is PPID 1 | 00:00 |
rrq | time to attach gdb to it... | 00:01 |
systemdlete | installing gdb... | 00:01 |
systemdlete | one other thing I want to mention. It could have nothing or everything to do with it, idk. | 00:02 |
systemdlete | I have installed a xhci driver inside the VM. The idea was to test whether xhci might work better with a USB3 ethernet device. (I actually have not noticed any significant different, actually, but I left it with the xhci driver enabled.) | 00:03 |
gnarface | maybe it's a host driver issue somehow? | 00:04 |
systemdlete | it would be a vbox xhci driver issue, I'd think. | 00:06 |
systemdlete | which is possible I guess | 00:06 |
systemdlete | rrq: installed gdb, but my vmlinuz doesn't have debug symbols | 00:07 |
systemdlete | it tells me no stack because the process is a zombie | 00:07 |
rrq | mmm should be in the host with hanging xorg. then just attach to the pid and check the stack | 00:08 |
systemdlete | stack is empty | 00:08 |
rrq | sometimes it says something | 00:08 |
rrq | ok | 00:08 |
systemdlete | sorry... | 00:08 |
rrq | then "p (int) exit(0)" should make it exit | 00:09 |
systemdlete | "No symbol table is loaded. Use the "file" command. | 00:10 |
rrq | hmm is it actually running? | 00:11 |
rrq | try: run | 00:11 |
systemdlete | maybe my invocation of gdb is faulty? I did "gdb /boot/vmlinuz-6.1.0-18-amd64 2005" | 00:12 |
rrq | aha | 00:12 |
systemdlete | yup | 00:12 |
rrq | just fo "gdb" | 00:12 |
* systemdlete duh | 00:13 | |
systemdlete | ok | 00:13 |
rrq | then do "attach pid" where pid is the pid of xorg | 00:13 |
systemdlete | then | 00:13 |
systemdlete | Illegal process-id: pid 2005. | 00:13 |
rrq | ? | 00:13 |
systemdlete | (bc it's a zombie??) | 00:13 |
rrq | I thought it'd attach zombies too | 00:14 |
systemdlete | Something is rotten in Denmark. | 00:14 |
rrq | which init are you using? | 00:15 |
systemdlete | default | 00:15 |
systemdlete | sysvinit | 00:15 |
rrq | it appears to have failed "reaping" that child | 00:16 |
systemdlete | I agree. | 00:16 |
rrq | try to send signal 17 to pid 1 | 00:16 |
rrq | (sigchild) | 00:16 |
systemdlete | no change | 00:16 |
rrq | exit gdb I suppose since it wasn;t any use | 00:17 |
systemdlete | still marks process as <defunct> | 00:17 |
systemdlete | oh, I'm already out of gdb | 00:17 |
systemdlete | did you mean send kill to proc inside gdb? | 00:17 |
rrq | send signal 10 to 2005 ... (the leaving VT signal) | 00:18 |
systemdlete | inside or outside gdb? | 00:18 |
rrq | no gdb seems not to do what I expected | 00:18 |
rrq | outide | 00:18 |
rrq | s | 00:18 |
systemdlete | nope | 00:19 |
rrq | then signal 11 to 2005 (the entering VT signal) | 00:19 |
systemdlete | nopety-dopety. sorry | 00:20 |
rrq | there might be something in the .local log? | 00:20 |
systemdlete | the Xorg.0.log? | 00:20 |
rrq | yes | 00:20 |
systemdlete | that file has not updated since Mar 14, which is when I rebooted the VM | 00:21 |
rrq | ok | 00:21 |
systemdlete | no, really, I thank you for all your attempts to help. I feel bad that nothing is working. | 00:22 |
rrq | and "ps lwww 2005" says it's Xorg? | 00:22 |
systemdlete | I think my next step will be to put that xhci back to the normal ohci/ehci mode and let it run for a week or so and see if it freezes. | 00:23 |
systemdlete | yes, it is definitely the xorg process | 00:23 |
systemdlete | well "Xorg" actually | 00:23 |
rrq | and you ran gdb as root ? | 00:24 |
systemdlete | yep | 00:24 |
systemdlete | I'm ssh'd into the VM as root | 00:24 |
systemdlete | I fire up the desktop from the command line with startxfce4 | 00:25 |
systemdlete | (not startx or xinit or whatever) | 00:25 |
systemdlete | and that could present a problem, idk. | 00:25 |
systemdlete | I had been having numerous issues with starting the desktop from any of the DMs | 00:26 |
systemdlete | I forget exactly what, but this seemed to work much better. But that was a year ago, and maybe some bugs have been fixed. | 00:26 |
rrq | mmm don;t you need to start Xort beofre running startxfce4 (which starts the windo manager) | 00:26 |
systemdlete | So maybe I can go back to using the DM (which, when working, was much more convenient!) | 00:26 |
rrq | or does startxfce4 start Xorg itself in some way? | 00:28 |
systemdlete | so I should start the desktop with startx? xinit? | 00:28 |
systemdlete | It must, because I don't do it manually myself. | 00:28 |
rrq | "startx" ... which runs xinit, which uses your ~/.xinitrc (or some default maybe) | 00:28 |
systemdlete | right. | 00:29 |
systemdlete | (just looked at the man page for startxfce4) | 00:29 |
systemdlete | startxfce4 does that also | 00:29 |
rrq | often a user's .xinitrc ends with "exec startxfce4" so as to migrate the start process to the window manager and thereby cause X to terminate when the window manager terminates | 00:30 |
systemdlete | that may be. | 00:30 |
systemdlete | but even using heavy artillery does not stop xorg | 00:30 |
systemdlete | It seems to have an iron dome around it. | 00:31 |
rrq | no it seems locked inside a system call | 00:31 |
systemdlete | ptrace? | 00:31 |
rrq | right... or strace een? | 00:31 |
rrq | v | 00:31 |
systemdlete | strace: attach: ptrace(PTRACE_SEIZE, 2005): Operation not permitted | 00:32 |
systemdlete | :( | 00:32 |
systemdlete | I noted that when trying to use gdb, it complained about ptrace being an illegal call | 00:33 |
rrq | mmm are you sure your root is root? | 00:33 |
systemdlete | will id(1) be sufficient to show this? | 00:34 |
systemdlete | uid=0(root) gid=0(root) groups=0(root) | 00:34 |
systemdlete | but, you know, since I'm logged in via ssh, I wonder if perms might be limited somehow? | 00:34 |
rrq | you don't have console access? | 00:35 |
systemdlete | I can't get to a console, unfortunately. Even using vbox input commands, it doesn't respond | 00:36 |
rrq | you have serial console enabled in /etc/inittab ? | 00:37 |
systemdlete | afaicr, I have not mucked with that file | 00:37 |
systemdlete | ts on /etc/inittab is Apr 17 2023. | 00:38 |
systemdlete | So whatever it was, out of the box, is its present state | 00:38 |
systemdlete | I can paste it for you, if you like? | 00:38 |
rrq | should have a line like: "T0:23:respawn:/sbin/getty -L ttyUSB0 115200" | 00:38 |
rrq | then "telinit q" to make init digest that one and start a console getty | 00:39 |
systemdlete | it does, but it is ttyS0, not ttyUSB0. And it is commented out | 00:39 |
rrq | sorry that's right | 00:39 |
rrq | comment in + "telinit q" | 00:40 |
systemdlete | actually, you were right after all. A few lines down there is a similar entry for USB0 | 00:41 |
systemdlete | so now I need to hook up a physical serial line? | 00:41 |
rrq | then the host will service a serial console.. the next would be how to attach one. I know some qemu but not vbox | 00:41 |
systemdlete | or usb serial line? | 00:41 |
systemdlete | oh | 00:41 |
systemdlete | that is in the vbox config... but not sure I can change that on a running VM | 00:42 |
systemdlete | let me check | 00:42 |
systemdlete | well, the vbox GUI won't permit a change, but let me try cmd line... | 00:42 |
systemdlete | it's not going to allow me to change it while the VM is running, even from cmd line tool | 00:54 |
systemdlete | I need to get some food. bbs | 00:54 |
rrq | ok... seems odd if your ssh root is some kind of fake root | 00:54 |
systemdlete | and thank you all so much for your everlasting support of devuan! | 00:55 |
systemdlete | well, vbox doesn't always allow all operations at all times. In fact, I think MOST operations are NOT permitted on running VMs. | 00:55 |
rrq | (food:) | 00:56 |
systemdlete | however, I WILL make sure to enable a serial line before the next reboot of the VM in case it is needed for further examination | 00:56 |
rwp | A zombie is dead and IIRC the process memory has been released. It's only the process slot information which remains. Remains waiting for the parent to call wait(2) on it. When wait(2) transfers the data from the process slot to the parent then the process slot data is released. | 01:11 |
rwp | But having released all of the process memory other than the process slot data that's why gdb can't attach to it, since it is no longer a running process. | 01:11 |
rrq | ta | 01:11 |
rwp | The "top" program lists the number of zombies in the process table. | 01:11 |
h3at | devuan does not have preseed like debian, right? | 01:12 |
rwp | Yes Devuan has pressed like Debian. For the netinst ISO and others. Not for the Refracta image. | 01:12 |
rwp | The preseed is a feature of the debian-installer and the debian-install is used for the netinst ISO image and the other similar ones. | 01:13 |
rwp | Refracta is a different independent toolset creation and simply "pours" an installation of files onto the target. That's one of the things that makes it a zillian times faster. | 01:13 |
h3at | many thanks | 01:13 |
n4dir | there are a few other based on devuan distros, no? | 01:14 |
n4dir | refracta is the first which comes to my mind too though. | 01:15 |
rwp | rrq, +1 for always enabling the serial console on VMs. This is the way. | 01:15 |
rwp | n4dir, It's the first one I think of too. But as you say there are others. https://www.devuan.org/os/devuan-distros | 01:16 |
rwp | I have not tried any of the others beyond Refracta. | 01:17 |
n4dir | the one with the old kde-version fork, trinidity is the DE?, might be exegnulinux. That i tried. It is great, if that is what you look for | 01:22 |
n4dir | perhaps another one, not sure | 01:22 |
rwp | systemdlete, I don't know if your virtualbox allows this but I would also try Control-Alt-F2 to slide over to the 2nd vt console which would normally have a vt console getting login on it. However given what you said I think that would have been locked up solid and unable to switch too. | 01:22 |
rwp | Also you said the process was in an uninterruptible D state. That's usually due to having DMA running and the kernel thinks it can't interrupt such a state and remove the process until the DMA is done. Which if it is totally stuck won't ever be done. | 01:23 |
systemdlete | rwp: I tried a number of different keystrokes to scare up a console. None of them worked. Even using vbox's built-in input shortcuts, I still could not get a console. | 03:30 |
systemdlete | and from now on, I will leave a serial console configured on new VMs (I'll add that to my checklist) | 03:31 |
systemdlete | rwp: Any security concerns having a serial port left enabled but unused? I can't think of any but you and others might be able to. | 03:42 |
systemdlete | n4dir, maybe anti-x? It is getting high marks with the anti-systemd crowd. I've tried it a bit, and I'm thinking of using it for one of my applications. | 03:45 |
n4dir | it is nice, but not based on devuan | 03:46 |
n4dir | they over-configured it a bit, as far it is me, which makes it a bit hard to administer, but in general, i really like it | 03:47 |
ted-ious | systemdlete: I think I have had the same problem as you with xorg freezing. | 03:59 |
ted-ious | Did you figure anything out? | 03:59 |
ted-ious | systemdlete: And are you trying to get to the alt-f2 console on the linux vm? | 04:03 |
ted-ious | That should be possible with virtualbox's virtual keyboard. | 04:03 |
xisop | you could also boot the kernel with `single text` added | 04:36 |
joerg | ctrl-alt-F2 ? | 05:11 |
systemdlete | ted-ious, joerg: See above. Yes, I've tried all of those. No, I have not figured anything out yet, sorry. | 06:00 |
systemdlete | Thank you for your input. | 06:01 |
ted-ious | In that case since you can ssh in I guess maybe you can kill xfwm and restart it and maybe that will help. | 06:07 |
ted-ious | Since you can move the mouse obviously xorg isn't hung or insane. | 06:08 |
ted-ious | I think you might have to tell xfwm your session id but you should be able to get that from ps -wax. | 06:09 |
rwp | systemdlete, Probably the graphics side of the system was completely locked up. I know you could ssh into it. But I have seen that before myself where the graphics is locked up and I have not been able to break it free without a reboot. Even though it seems like it should be possible to reload the drivers and reset and go. | 18:25 |
rwp | systemdlete, There is no security concerns about having a getting login running on a virtual machine. The permissions on the serial devices protect it from unprivileged process connecting to the console line, and even then they would need to log in first. | 18:27 |
danny_z | systemdlete: have you dropped into a tty to diagnose this? | 18:27 |
rwp | danny_z, At the time there was no serial line active. It wasn't configured. systemdlete says is going to configure it for next time. | 18:27 |
Guest7299 | Hello hello! | 20:27 |
Xenguy | I don't know why you say goodbye I say hello | 20:31 |
crhylove | I still want to release a mintified version of Devuan. | 21:42 |
crhylove | Something where the user interface is super slick and easy but still is Devuan underneath. | 21:42 |
crhylove | Maybe I'll have time this summer? | 21:42 |
n4dir | i am pretty sure someone told me (here) how to do that (mintifiy). It was a few easy steps. | 21:48 |
crhylove | Yeah, I'm thinking about putting out a full distro though. | 21:58 |
crhylove | Maybe this summer. *finger's crossed* | 21:58 |
paculino_ | Didn't someone already do a frankenmint where devuan was used except for stuff differing between mint and debian but not debian and devuan? | 22:42 |
paculino_ | Some sort of complicated pinning, iirc | 22:42 |
paculino_ | Maybe using debdistdiff? https://gitlab.com/debdistutils/debdistdiff | 22:46 |
crhylove | Interesting tool. But the link I found was: https://all-things-linux.blogspot.com/2021/02/introducing-linux-mint-devuan-edition.html | 23:01 |
fsmithred | paculino_, I think they posted that on the forum | 23:01 |
paculino_ | Oh | 23:02 |
crhylove | It would be cool to make a compiz/mate/mint/devuan system that works really well out of the box. | 23:03 |
crhylove | This guy used cinnamon, which is lame imho. | 23:03 |
crhylove | https://forums.linuxmint.com/viewtopic.php?t=337773 | 23:07 |
crhylove | For the step by step. | 23:07 |
fsmithred | You could probably migrate mint to devuan - be careful of package versions. Mint does some weird intermediate releases that are halfway between major releases of debian or ubuntu. | 23:17 |
n4dir | again, i am really sure that guy in #devuan-offtopic told me how to make devuan look like mint in a few steps. I forgot who it was | 23:18 |
fsmithred | Here's a discussion about mint-devuan: https://dev1galaxy.org/viewtopic.php?id=2317 | 23:24 |
crhylove | @fsmithred: Yeah, read that one too. :) | 23:30 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!