Error exit code 127

[Coghoyo]

I'm trying to use the bridge with a RaspberryPi.
Compilation is OK and detection of MIDI device and Mustang IV V2 is OK too, but after detection I got this message:

Apr 14 12:37:13 raspberrypi systemd-udevd[1250]: Process '/bin/bash -c '/bin/echo /usr/local/bin/mustang_bridge_start | /usr/bin/at now'' failed with exit code 127.

Could you give me some idea about what the problem could be?
I

[snhirsch]

Error code 127 is an indication of general execution failure from the shell. Please check to ensure that all these files are actually installed on your Pi:

• /bin/bash
• /bin/echo
• /usr/bin/at
  and, of course
• /usr/local/bin/mustang_bridge

[Coghoyo]

Ok. Thank you so much.
I'll check it and give feedback.

[Coghoyo]

Sorry, I haven't time to check this before.
You were right about lack of some files. I have installed all those files, but then the problem changed to exit code 1.

I have:

• Raspberry Pi B+ with Raspbian Stretch.
• Roland UM-ONE MIDI interface (I previously used a cheap chinese one that I finally discarded because Sysex messages were not working)
• Fender Mustang IV v2

I attached here a file with the steps I have taken and some logs that may be useful for troubleshooting.
Mustang_Bridge_Issue.TXT.

Please, could you give me a clue of what could be going wrong. I suspect about permissions related problem, but I'm not an expert.
Thank you in advance.

[Coghoyo]

Hi, when I launch the command $ mustang_midi 1 1 it works fine, so I think the problem could be in the start script.
I debug the start script in Python (mustang_bridge_start) and found that line "import sys" was not present and throws an exception when it need to use sys.exit function.
I included the line and after that it gives the error:
"/var/run/mustang is not properly setup"
I can run the brigde, but I need that it works at startup automatically.
Any idea or suggestion?

[kurtjensen]

I was having mustang_bridge_start failures in the syslog too on stretch. The errors stopped, and I could finally get mustang_midi to autostart when plugging the usb into the mustang when I did these things:

I commented out the last few lines of
/lib/systemd/system/systemd-udevd.service
as described in this link:
https://www.raspberrypi.org/forums/viewtopic.php?t=198601
and the rebooted (out of laziness....)

I also had to do:
sudo systemctl restart mustang_bridge

and then re-plug the usb cable to the mustang.

I still am not having it work on bootup by itself without the systemctl restart. Right after bootup, if I do systemctl status mustang_bridge
it reports that it is inactive(dead)

Not sure if this is the same failure you are seeing, but it might be worth a try.

[snhirsch]

mustang_bridge is not run as a systemctl task and I would suggest against issuing any systemctl commands referencing it. The patch to the udevd service configuration could very well be part of the issue. Thanks for the link.

I suspect the real issue with recognition from cold start lies with boot initialization order. What happens if you (a) unplug Mustang, (b) power cycle RPi, then (c) plug in the Mustang only after it's completely booted (without typing any commands)?

Thanks for the report about missing 'import sys'. I will correct that.

Coghoyo: I get nothing when I click that link to log file. Please include the log in the message if you would like me to review it.

[Coghoyo]

Hi snhirsch, I tried what you suggested about boot init order but it doesn't work.
Regarding the log file, don't worry, I´ll try to generate a new one and send you a dropbox link to it. Thank you.

kurtjensen I'll try to test your solution, but I think the problem could be in the init script because I got some errors about /var/run/mustang directory creation.

I would like to have more time and linux knowledge, so please be patient with my feeback.
Thank you both of you.

[snhirsch]

No problem. At one point in the distant past Linux was a clean operating system that was quite simple to comprehend. Twenty years on, it's accumulated layer after layer of gunk and poorly-documented subsystems. I suspect some recent "improvement" in udev is causing the problems. You should certainly apply that fix to the configuration file (and reboot afterwards). If the default now is to disallow scripts from being run by udev rules, that breaks things completely so let's eliminate that first.

What are the exact errors you are seeing about /var/run/mustang? When do you see them? At boot time? Other? Maybe the maintainers (in their infinite wisdom) have rearranged startup sequence such that the startup script intended to create /var/run/mustang is being run before /var/run is mounted.

If you want to avoid all this hassle you could install an older distribution.

[kurtjensen]

I suspect the real issue with recognition from cold start lies with boot initialization order. What happens if you (a) unplug Mustang, (b) power cycle RPi, then (c) plug in the Mustang only after it's completely booted (without typing any commands)?

I just gave that a try, and it is not successful.
lsusb shows both the mustang and the USB-MIDI cable plugged in and enumerated, but ps aux does not show mustang_bridge to be running.

Avoiding systemctl as you suggest, I then do sudo /etc/init.d/mustang_bridge start and then replug the mustang USB connection. At this point I do see mustang_bridge listed in the ps aux output. This suggests that this init script may not be executing automatically after boot. It is as if the update-rc.d line in the install script did not accomplish the desired result.

Looking in all the /etc/rc[n].d directories (where [n] is a runlevel digit), I can't find any links there to the /etc/init.d/mustang-bridge script. With a quick look at that script, I noticed that in the LSB header that the entry # Default-Start: contains 'S' rather than a list of runlevels like the other init scripts do. I don't know enough about init script operation to know if this is an issue or not.

[kurtjensen]

Looking in all the /etc/rc[n].d directories (where [n] is a runlevel digit), I can't find any links there to the /etc/init.d/mustang-bridge script.

I take that back, sort of. I didn't see /etc/rcS.d earlier, and I do see a symlink in that directory to the mustang_bridge init script. I didn't realize that 'S' is a valid runlevel.

[kurtjensen]

Here's a hypothesis: Runlevel S on Raspbian stretch might not ever get executed at boot....?

I got things working at boot-time by changing some etc/init.d/mustang_bridge LSB header entries to

# Default-Start:    2 3 4 5
# Default-Stop:    0 1 6

Then doing:

sudo update-rc.d mustang_bridge remove
sudo update-rc.d mustang_bridge defaults

If I then reboot, I can do ps aux and see that mustang_bridge is in the process list, even without replugging the mustang USB.

What I don't know is if changing these runlevels will have some side effect. I suspect that the developer (snhirsch I think) initially chose runlevel 'S' for a deliberate reason.

[snhirsch]

No, I probably chose it out of complete naivety :-). Once you fixed the runlevel settings, does startup on hot-plug begin working for you? Really appreciate your troubleshooting this!

The init script is there only to create the correct directory under /var/log/run, so if that doesn't run things break later on.

[kurtjensen]

I'm happy to help, and to have this nice controller for the mustang available!
Hot plug operations seem to work correctly for me with the above changes.
Cheers!

[snhirsch]

I just checked in the changes you suggested and gave you credit for finding the problem.

Also to clarify: Did you confirm that the fix to /lib/systemd/system/systemd-udevd.service was strictly necessary? If so, I want to get that information into the documentation.

[kurtjensen]

Thanks!I did not go back and confirm that the fix to /lib/systemd/system/systemd-udevd.service is strictly necessary.I'm happy to do it, but I'm about to head of on holiday for a couple of weeks, so I suspect that I won't get to it until after then. On July 5, 2018 at 11:41 AM snhirsch <notifications@github.com> wrote: I just checked in the changes you suggested and gave you credit for finding the problem. Also to clarify: Did you confirm that the fix to /lib/systemd/system/systemd-udevd.service was strictly necessary? If so, I want to get that information into the documentation. —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.  

[snhirsch]

No worries. Enjoy your time off!

[Coghoyo]

I finally changed the Init levels in mustang_bridge file and commented the lines in system-udevd.service as kurtjensen suggested and all is working now.
The bridge works in all circumstances and there is no need to replug mustang amplifier.
Only one consideration:
if you start the system with midi interface unplugged you'll need to replug mustang amplifier after plugging midi interface.

Thank you both snhirsch and kurtjensen for finding the solution. I appreciate it too much.

Only question that has nothing to do with this issue, ¿where in the code can I modify numbering schema for program change?
I need to increase by 1 the program sended to the amplifier because my controller is old and when its display is set to 1 the mustang program is set to 2 and so on. It's not really important, but if it is easy for you just give me a hint I'll appreciate it.

[snhirsch]

"if you start the system with midi interface unplugged you'll need to replug mustang amplifier after plugging midi interface."

That shouldn't be necessary. My code reacts to both controller and amp hot-plug events, then checks to see if the other one is present. There may still be something "off" with Raspian Stretch that's causing this issue. But, at least you have a work around!

Find this section in mustang_midi.cpp and add the line suggested below. Note that this will cause problems with any controller that actually does start at '0':

  case 0xc0: {
    // Program change
    int bank = (int)(*message)[1];
// Try putting this here:
    bank--;
    int rc = mustang.patchChange( bank );
    if ( rc ) {
      fprintf( stderr, "Error: PC#%d failed. RC = %d\n", bank, rc );
    }
  }
  break;

[Coghoyo]

You are right!! After a new battery of tests I verified that it works despite the order of connected devices. I think I made previous tests without getting a complete Raspberry boot. So, all is working fine now.

Regarding the modification you sent me, it worked Ok (I only needed to change bank--; to bank++;) Of course I cannot reach 00 program, but I don't mind.

As far as I'm concerned, you can close the issue, unless you prefer to wait for kurtjensen diagnosis.

Thank you so much for all your help.