amiberry returns immediately to emulationstation, nothing in the log

mdx

Pi Model or other hardware: 3B+
Power Supply used: pi
RetroPie Version Used (eg 3.6, 3.8.1, 4.1 - do not write latest): 4.8
Built From: buster + retropie script
Controller used: DragonRise Inc. PC TWIN SHOCK Gamepad (lsusb) & Microntek USB Joystick (dmesg)
Error messages received:
/dev/shm/runcommand.info:

amiga
amiberry
/home/pi/RetroPie/roms/amiga/Demos/A/lha_name.lha
/opt/retropie/emulators/amiberry/amiberry.sh auto "/home/pi/RetroPie/roms/amiga/Demos/A/lha_name.lha"

/dev/shm/runcommand.log:

Parameters: 
Executing: /opt/retropie/emulators/amiberry/amiberry.sh auto "/home/pi/RetroPie/roms/amiga/Demos/A/lha_name.lha"

Verbose log (if relevant): none in /dev/shm/runcommand.info & /dev/shm/runcommand.out
Emulator: (Name of emulator - if applicable): amiberry

I'm unable to run amiberry via emulationstation. When choosing any lha image, emulationstation shuts down, blanking the screen, the runcommand menu gets displayed (which I'm unable to control in any way via the joypad) and then returns to emulationstation. The joypad works in emulationstation, it just doesn't in the menu.

sleve_mcdichael

@mdx said in amiberry returns immediately to emulationstation, nothing in the log:

the runcommand menu gets displayed (which I'm unable to control in any way via the joypad) and then returns to emulationstation. The joypad works in emulationstation, it just doesn't in the menu.

Doesn't help with your main problem, but for this bit you can probably solve it with:

RetroPie > runcommand configuration > launch menu joystick control: ENABLED

BuZz

@mdx you should update the RetroPie-Setup script and then amiberry and retry as you're not on the latest version (or do a full update).

mdx

@BuZz no need, it is the latest.

I sorted it out, turns out my config was missing the assignment of standard input to tty for emulationstation, which had the side effect of amiberry not piggy backing on its standard input.

I'm using a slightly modified configuration for systemd.
I've posted a few details here, including the redirection problem.

mdx

To help anyone who runs into a similar problem:

There can't be an agetty or a login process running prior to starting emulationstation. A console process like login or agetty (spawned under the getty@tty1 service) appears to be taking over the input entirely. The result is no input accepted by the runcommand menu and amiberry itself returns immediately with no error logged. emulationstation will accept input. login noticably changes /dev/tty1 permissions, taking away the group write bit, whether that is relevant. There is probably some way to have a coexisting getty@tty1 instance and an emulationstation session. Probably waht needs to be changed is stopping certain kinds of TTY control or resets (read # man service.exec) by getty@tty1 or agetty but I haven't figured it out yet.

mitu

There can't be an agetty or a login process running prior to starting emulationstation[..]

That's not entirely accurate - I can start EmulationStation from a SSH session, while the auto-login console on tty1 is active (with the keyboard) and everything works fine.

Most likely starting the program from systemd directly doesn't have the same behavior as the auto-login session that RetroPie uses. Caveat emptor.

mdx

@mitu while logged into emulationstation, in the runcommand menu & running amiberry (three cases), can you run the following please from your ssh session and post the outputs for each case?

# lsof /dev/tty1 /dev/tty

and additionally:

# ls -la /dev/tty1 /dev/tty

I'd like to get to the bottom of what's holding up input to joy2key and amiberry. lsof may need to be installed to collect this. Thank you!

mitu

@mdx said in amiberry returns immediately to emulationstation, nothing in the log:

I'd like to get to the bottom of what's holding up input to joy2key and amiberry.

joy2key runs in the SSH session (which is expected), but amiberry or emulationstation have no issues using the keyboard or the gamepad.

mdx

@mitu I'm not saying they are, asking for those outputs to compare with mine. As I said, when there isn't a getty systemd service running in the background, no issues. The moment it's enabled, gamepad input isn't handled correctly (which is what joy2key handles for the runcommand menus). Keyboard input still works though.

mitu

Here's the listing

# ls -la 
crw-rw-rw- 1 root tty 5, 0 May 28 08:15 /dev/tty
crw------- 1 pi   tty 4, 1 May 28 04:10 /dev/tty1

# lsof

bash        601   pi    0u   CHR    4,1      0t0   22 /dev/tty1
bash        601   pi    1u   CHR    4,1      0t0   22 /dev/tty1
bash        601   pi    2u   CHR    4,1      0t0   22 /dev/tty1
bash        601   pi  255u   CHR    4,1      0t0   22 /dev/tty1
emulation 13905   pi   17r   CHR    5,0      0t0   13 /dev/tty

Note that I have a login shell started on tty1, with nothing but a command prompt.

mdx

@mitu your setup works because your emulationstation is running from the environment spawned by getty@tty1 and inherits its environment, including standard input and output.

With systemd, services do not inherit the environment of another service. So a process that owns tty1, like login will prevent other processes from other services from using that descriptor, especially when the other processes are non-root, like emulationstation.

I found when running getty as a systemd service, the instance getty@tty1 needs to be stopped fully (including a stale login process that getty instances seem to leave behind) before emulationstation can make use tty1 for standard input and output. Instances on other tty's may be left as is.

The following entry in emulationstation.service will stop getty@tty1 if running:

ExecStartPre=+sh -c 'systemctl is-active getty@tty1 && systemctl stop getty@tty1 || systemctl reset-failed getty@tty1'

ps auxf shows the tty a process is running with.