Torture Testing the new --sysvipc PRoot option with QEMU.

[SDRausty]

Torture Testing the new --sysvipc PRoot option with QEMU.

Thank you all for keeping the Termux project on course over the years! After years of using Termux on Android, I still have difficulty comprehending my new work environment: no desktop needed! The newly implemented --sysvipc PRoot option is amazing:

I have very very positive experience with newly shared memory implementation which work directly in Proot binary module. Screen reader Orca work much more stable and I can for example. Switch to The desktop by pressing CTRL}}+ALT+d much more faster even if mate-terminal display many lines when some app is being compiled. I can also interrupt speech very often while building some app without issues at all. When Proot shared memory function have not been implemented, it have caused issues. Orca have frozen.

Originally posted by @JanuszChmiel in https://github.com/TermuxArch/TermuxArch/issues/34#issuecomment-734484409

Termux sometimes crashes completely when working with this new command: the makeaurhelpers command. At times, this command crashes Termux when using PRoot with QEMU to build Arch Linux packages on device.

Steps to reproduce a crash:

1. Install Arch Linux in Termux PRoot with QEMU emulation; The command setupTermuxArch v will automatically choose the optimal architecture to emulate with QEMU for arm smartphones. For x86_64 smartphones the command setupTermuxArch q can be used.
2. Once installed, run the command makeaurhelpers in multiple Termux sessions (at least four). This is a very labor intensive command as it downloads source code, parses it and attempts to build Arch Linux aur packages.

Steps how to find out more information about how this crash develops are welcome. I am not sure how to collect the crash data as Termux stops functioning.

[JanuszChmiel]

May be, that new option is in conflict with Qemu in RAM. Try to avoid using shared memory by simply not adding this switch for Qemu emulated CPUS when you will run distro with this option. I understand, that this new Proot extension have very remarkable benefit for you also when you are using Qemu. Because it is not necessary to install and compile fakeroot. The best what you can do is to open this issue directly on The Proot for Termux Github branch. MR Bednarski, MR Pliusch and The author of this new option will assist you while helping them to debug Proot. According to my amateour opinion, The best what you could do is to add some debug option for Proot and set Proot debug output to The highest most detailed value. So on yours startarch script, try to add This option. Unfortunately, if Proot ddebug will fail, There would other possibilityes. Monitoring logcat . I Am also very sorry for my previous posts about yours new feature of running Qemu and ArchLinux. I did not wanted to degradate yours work. I also understand, that also Qemu emulated distribution can have important potential for many developers. Does makeyay The same thing like makeaurhelpers?

-- Tento e-mail byl zkontrolován na viry programem AVG. http://www.avg.cz

[SDRausty]

Thank you for replying:

did not wanted to degradate yours work

On the contrary, your contributions to TermuxArch have enhanced it very much @JanuszChmiel. This might be a glich with the new --sysvipc option, but I am not sure. And as mentioned, multiple labor intensive Termux sessions are wanted to reproduce a crash.

Does makeyay The same thing like makeaurhelpers?

No, it does not. The command makeaurhelpers attempts to build multiple AUR helpers. This includes the AUR helper yay. While makeyay only attempts to build the Arch Linux yay package. It might not even be possible to install all the AUR helpers at one point in time anyways as some of the Arch Linux AUR helper packages appear to be in conflict.

EDIT: To use the commands that are usually forbidden for use with the PRoot root user account, you can run the TermuxArch command open4root as PRoot root user in Arch Linux in Termux PRoot.

[SDRausty]

Diagnostic test information is welcome; ☎️

How can I collect this data?

[JanuszChmiel]

Mr Rausty, because you have mady very very much to Me and for many visually impaired people, I will also help you to find The cause of this error. I will try to run makeaurhelpers In four separate Termux sessions like you are doing. I would like to kindly tell you, that when running some proces in multiple sessions of Termux, that memory allocations will grown and Cpu cycles too. And that if The same systém call is being made for several times, we could even get to very complex kernel related very difficult to debug issues. Since if kernel memory management or other similar kernel routine will not have The chance to manage multiple same systém calls at a same time, may be, that Proot developers will not have The chance to debug The problém. To have The maximum possible success to help you constructively. 1. I will enable most detailed USB debugging logcat monitoring, Lazarus and Lamw has The best available routine for visually impaired, since other USB debugging logcat protocol routines for PC frozen screen readers since there is too much data at The same time. New on Windows Api independent Lazarus component for editable field do not freeze screen reader so I can safely monitor debug and because this field is very accessible and it is possible to use it fast, I will have very big chance to fetch error, if kernel, some Android library will output some severe crash after running makeaurhelpers in The four termux session at The same time.

2. I will use dropbear and different port for every session use, since if Termux will crash, Talkback will lost The chance to monitor errors on The Terminal. ONly SSH clients have some chances to get. I will even enableSSH client app log creation, so all messages will be stored on A long log file. So even if client will disconnect immediately, data will be stored inside Putty log. I also have my favourite Teraterm SSH client. And I have even The possibility to use Linux computer, mate-terminal app and ssh app which allow Me to quickly and reliably edit various files by using Nano. Because only Orca and its library communication can provide safe and stable solution when using nano or other text editors when using SSH protocol. When user press arrow key when editing or creating text file, The reactivity is very fast, only several Milliseconds and it is 100 % guaranteed, that I will remove or add correct char on its place. When using NVDA, it is necessary to use GDI display hooks calls and this is not fast and not reliable. To be honest, I would not have Thre chance to debug and test Termux apps without Linux systém or without Windows systém. TO overcome that, user would have to create two sessions. First would contain Arch Linux without Qemu emulation and I would have to install some simple window manager such as Openbox or Ratpoison. Then I would had to use mate-terminal orca, espeak-ng and pulseaudio. Then, second session would have ssh app running. I will test, if SSH will work from userspace variant of Linux from ArchLinux termux. The aim is to allow visually impaired users to use nano and other text eitors and to edit configuration files, and various scripts such as profile. It is impossible to manage that confortably with existing screen readers for Android. I will try dropbear first in combination with SSH on terminal session. So I Am starting to help you debugging.

-- Tento e-mail byl zkontrolován na viry programem AVG. http://www.avg.cz

[SDRausty]

Thank you @JanuszChmiel; adding processes such as keys in Arch Linux PRoot with QEMU and setupTermuxArch install customdir in new sessions might hasten a crash. Arch Linux 32 has the smallest installation footprint.

Obviously we are going to be doing things a typical user does not want to do; Namely, attempting to overload Termux!

[JanuszChmiel]

I AM sending you a detailed text output of aurhelpers when running emulated X86 X64. Script report some little errors but no crash. I have not tried four sessions at The same time. But I think, that also this output could be useful for you. Sure, I can also wisit https://github.com/TermuxArch/TermuxArch/issues and send here if it is necessary. I AM sending textual output here. aurhelpers.txt

[SDRausty]

output could be useful for you.

Hopefully, to all of us; My service dog Harper who was assisting in these Termux issues that we are dealing with here was at my side when she was shot shortly after I submitted this topic 20201201 while working later in the day, downtown; Your assistance is requested.

output could be useful

sudo: /etc/sudo.conf is owned by uid 1001, should be 0 sudo: /usr/bin/sudo musí být vlastněn UID 0 a mít nastaven bit setuid

TermuxArch WARNING: Generated script signal 1 near or at line number 80 by '$SUDOCONF'!

This error appears in both Arch Linux and Arch Linux 32 with QEMU in Termux PRoot. I have asked about this behavior at this link here:

This behavior change in ownership behavior causes all sorts of havoc for the user login; do you have any advice regarding this change in ownership derived from PRoot login?

[JanuszChmiel]

Oh dear and kind MR Rausty. Unfortunately, this is too complex for Me to find The cause. Only very experienced Proot programmers, who knows deeply relationships between Android Bash Kernel and Android BIonic and Proot code could assist in this issue.

-- Tento e-mail byl zkontrolován na viry programem AVG. http://www.avg.cz