for now I just do not exit any second tty's & I make a point of saving stuff before I do ctrl+alt+fn ...
it's a pain and I will get back to this ...
Chris
]]>There are also other problem cases where the shell indeed terminates, but getty still doesn't get duly respawned. It really depends on the particular set up of this system; i.e., what the OP means with "using stable".
Perhaps a telinit q command in tty1 (in my test sequence), will trigger a respawn. That would be an indication of some different problem, relating to init and its various configurations, and possibly including the hotplug handling s/w.
]]>You might want to test this theory by inspecting the process list before and after exiting. E.g.:
login at tty1
type ps axww| grep getty
shift to tty2, login and then type exit
shift back to tty1 and type ps axww | grep getty again (or use up-arrow)
If the second getty list does include tty2, then it's not a respawn problem.
Otherwise the problem is likely that the shell doesn't complete it's termination, perhaps due waiting for an unavailable resource.
]]>Or can you freely ctrl-alt to another tty like 5 or 6 ?
]]>From some investigation i found this.
https://bugs.freedesktop.org/show_bug.cgi?id=93164
Comment 9.
Created attachment 121092 [details]
xorg.log with crash backtrace -- intel hardwareHi, coming to this bug from https://bugs.debian.org/cgi-bin/bugrepo … bug=805605
In reproducing this bug, there seems to be a time-based component to getting X into a 'frozen' state. If there is a delay between step 4's chvt's, then all is fine after the second switch:
...
4. chvt 1; sleep 1; chvt 2In my case, Laurent's procedure above is modified to (less gdm):
1. startx on tty1
2. switch to tty2
3. login
4. chvt 1; chvt2Furthermore, when following the above to get into a 'frozen' X state (less `sleep 1`), it is not enough to produce an Xorg.log crash backtrace in my case. Instead, the crash does not happen until I 'switch' to the vt on which the frozen X is living. vt1 in the above example. Only then is a backtrace logged to the Xorg.log which should be attached. *note: this is using intel hardware.
try logging in on tty2 and 3 only and see if you get the same outcome ofa locked up console when trying to exit. Make sure tty1 and or 7 is logged out.
]]>output for dmesg:
[ 0.007987] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.007988] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[ 0.355058] pmd_set_huge: Cannot satisfy [mem 0xe0000000-0xe0200000] with a huge-page mapping due to MTRR override.
[ 0.439533] pci 0000:00:02.0: BIOS left Intel GPU interrupts enabled; disabling
[ 8.865383] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB.PCI0.SBRG.GPBX) (20160831/utaddress-247)
[ 8.865388] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB.PCI0.SBRG.GPBX) (20160831/utaddress-247)
[ 8.865391] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB.PCI0.SBRG.GPBX) (20160831/utaddress-247)
[ 8.865394] lpc_ich: Resource conflict(s) found affecting gpio_ich
[ 9.947662] usb 6-1.7: firmware: failed to load ath3k-1.fw (-2)
[ 9.947711] usb 6-1.7: Direct firmware load for ath3k-1.fw failed with error -2
[ 9.947713] Bluetooth: Firmware file "ath3k-1.fw" not found
[ 9.947760] ath3k: probe of 6-1.7:1.0 failed with error -2
dmesg --level=err,warn
try
pkill -U <your username>
in second terminal. Does it still hang ?
]]>