Tuesday, November 29, 2022

Docker "exec format error"

Overview

Occasionally, for a variety of reasons, a Docker container won't start, and the only clue is a cryptic message that says something like this:

standard_init_linux.go:178: exec user process caused "exec format error"

I'm aware that there are numerous related forum posts to be found via web search with a collection of right, wrong, confusing, and sometimes tediously wordy responses.  This is just an attempt to cut through some of that and cover only the non-wild-goose-chase stuff, not to take credit for any of it.  If any of this ended up worded similarly to something else, it's purely coincidence.

Cause #1 - Missing "shebang" in Shell Script

Sometimes, this is related to an improperly authored shell script, serving as the entrypoint for the container image, and the solution is to add the required "shebang" (#!/bin/sh) line at the top of the shell script.

Troubleshooting

  1. Run the image as a "shell" container and examine the entrypoint script 
    docker run --rm -it --entrypoint [] myimagename:myimagetag /bin/sh
  2. (Possible) Solution: Rebuild the container image with a corrected script

Cause #2 - Image/Runtime Platform Mismatch

The other main reason for the "exec format error" is that the platform for which the container image was built does not match the platform where the container is running.

This could be related to how the image was fetched / staged.  For instance, using "docker pull" from a public registry and "docker push" to a private registry, using a Macbook with an M1 processor (arm64 platform) when the container will be run in a kubernetes system that is on amd64 (intel compatible) hardware and/or virtual machines.

  • Note: When the docker image entrypoint references a binary executable (not a startup shell script... i.e. no chance of missing "#!/bin/sh"), it is more likely that the "platform mismatch" is the cause of the "exec format error".
  • Note: If the source registry does not have an image matching the client/target platform (e.g. on a Raspberry Pi Arm 32bit OS), docker pull might fetch an image with a "best match" platform, which won't work (wrong exec format).  This is the toughest one to fix, since it might require a full recompile of some binary executable files and probably demands building a new image up from multiple layers down.

Troubleshooting

  1. Check the image platform
    docker image inspect myimagename:myimagetag |grep -i architecture
  2. Check the runtime platform
    docker version |grep -i arch
    or
    kubectl version |grep -i server
  3. (Possible) Solutions
    1. Pull the image with the platform that matches the target runtime environment
      docker pull --platform linux/amd64 myimagename:myimagetag
      ...then push again to the target registry to overwrite/replace the wrong-platform image.
      See: https://docs.docker.com/build/building/multi-platform/
    2. Rebuild the image starting from the correct base image
      Modify Dockerfile and add --platform argument to the FROM line.
      See: https://docs.docker.com/engine/reference/builder/#from

Monday, September 26, 2022

MacOS Display Derangement

Overview

The title is intentional, because MacOS falls short of actually accomplishing display arrangement in some circumstances.

Circumstances

When multiple monitors of certain brands and models are plugged into a MacBook, the part of MacOS that derives a "unique" identifier for each monitor fails to distinguish between them.  The HP E243 is one example, but there may also be other brands/models that reveal this flaw in MacOS' handling of external monitor identification.  Since MacOS cannot tell which specific display was previously arranged in a particular position (relative to the internal display, or other external displays, or each other), the overall arrangement sometimes gets mangled.  The only common way to re-arrange the monitors is by way of the cumbersome "System Preferences -> Displays" dialog in MacOS.

Remedy

After years of searching for a reasonable solution to this issue, and hoping Apple would get it fixed (but has not as of Monterey / 12.6), I finally found, sorta by accident, a command line utility (the best kind IMO) with the source code published on Github, called DisplayPlacer.  DisplayPlacer removes "most" of the annoyance of this Apple MacOS bug.  It still requires a manual step (running a command/script) to force displays back into a captured/desired arrangement, but is WAYYYYYYYY better than using the MacOS "System Preferences -> Displays" UI every time.

Steps

  • Install displayplacer (brew tap instructions on the github repo)
    • https://github.com/jakehilborn/displayplacer
  • Arrange displays using the MacOS System Preferences -> Displays (yup... one last time)
  • Run displayplacer list and copy/capture the displayplacer command that is printed to the console, which contains all of the distinct display ids, resolutions, refresh rates, and relative positions.
  • Create a shell script containing the captured command.
  • Whenever MacOS !@#$% the display arrangement again, run the shell script to pop everything back where it is supposed to go.

Conclusion

This isn't my utility.  The author Jake Hilborn had done us all a favor by making MacOS less annoying while we all continue to wait, maybe indefinitely, for Apple to finally acknowledge this is a problem and fix it themselves.  I would recommend sending Jake a thank you, or maybe find a way to buy him a cup of coffee (or similar).  I only posted this so there will be yet one more way some of you might end up finding Jake's excellent work, and maybe end some of your frustration with the display "derangement" on your MacBook.

Sunday, May 29, 2022

Installing webCOrE for SmartThings (Android) - May 2022

Overview

In the wake of several decisions by Samsung and possibly others, the SmartThings eco system is falling apart.  This article sums up several of the answers for installing webCoRE in SmartThings as they are (were) in the spring of 2022.

Alert: If you are trying to do this on an iOS/Apple mobile device, this isn't likely to help you much.  iOS devices aren't really a favorite of people who want to tinker with something like webCoRE anyway, and are generally VERY restrictive, so I'll just wish you luck finding a similar article, if such a thing exists, for your situation.

webCoRE - Why?

Automations in the basic SmartThings app don't allow multiple actions on the same device.  This limitation makes it impossible to do things like using an IOT plug to automate cycling the power off and on for something like an HP multifunction printer that puts itself permanently to sleep under unknown, random circumstances.  webCoRE adds the ability to do more useful automations.

Installation Overview

Instructions found in various places are based on previous versions of the SmartThings IDE (website), and/or previous versions of the SmartThings (Android) mobile app, so the screenshots and instructions often don't match up to current reality.  Even this article will, without a doubt, become obsolete when Samsung moves things around once again.  In the interest of minimizing that "rot" factor, I'm leaving out details for how to do various steps but including enough key words to search the web and find instructions.

The installation process for webCoRE is supposed to be a few simple steps as follows:

  1. Add the SmartApps to the SmartThings IDE
    • Option 1: Create each of the 4 webCoRE components "from code" and copy/paste the source code into the online editor.
    • Option 2: Integrate SmartThings with GitHub, and install each of the 4 webCoRE components from the ady624 GitHub repository.
  2. Add a named "instance" of webCoRE within the SmartThings app with access to the devices, sensors, etc. that the instance may control.
    • This is where Samsung has made things really obscure and difficult.

Installation "Gotcha's"

SmartThings Classic is Discontinued

  • The user interface in SmartThings Classic made it far clearer and easier to install SmartApps, but it is defunct, and the "new" version of the SmartThings app, at least on Android, tries its best to bury and hide the SmartApps functionality.
  • If your Android device is pre-"Oreo" (pre Android 8.0), this is probably already a source of frustration, since the "New" SmartThings app won't even install/run.  For instance, a Samsung Galaxy-S 5 makes a pretty good smart remote for IOT stuff, but you'd have to go to some trouble to get Android 8.0 or later installed on it.

Steps to install a SmartApp in the "New" version of SmartThings

  • Enable Developer Mode - The option to create a SmartApp won't even show up without doing this first.
    • At the moment, this is done by 
      • opening the settings (gear icon displayed when the "Menu" page/tab is selected).
      • scrolling down to "About SmartThings" and tapping it for 5+ seconds
      • scrolling farther down to see, and toggle on "Developer mode"
  • Dive Into the Menus to find where they hid the SmartApp option
    • At the moment, this is done by
      • switching to the Automations page/tab
      • clicking the "+" icon and choosing "Add routine"
      • switching to the "Discover" page/tab
      • scrolling all the way to the bottom and selecting the main webCoRE SmartApp (not the dashboard, piston, or storage items)
        • Note: These will only appear if they were previously added in the SmartThings IDE

Location

  • webCoRE refuses to install unless the Location is properly set in SmartThings.
  • Location was apparently managed in the Menu-Settings at some point, but currently, it is "hidden" on the "Favorites" page/tab
    • tap the location name (e.g. "Home")
    • select "Manage Locations" (gear icon)
  • Even if a geolocation is set, it may be too broad for webCoRE to be happy with it, so try reducing the radius, if webCoRE refuses to install.

References

* https://community.webcore.co/t/installation-trouble-webcore-your-location-is-not-correctly-setup/20079
* https://community.smartthings.com/t/faq-did-we-lose-the-ability-to-add-custom-smartapps-after-the-app-update-of-june-2021/227734
* https://community.smartthings.com/t/alternatives-to-smartthings-ecosystem-2021/227572/3
* https://www.youtube.com/watch?v=y_ElUwmmI6Y (overview of install with several outdated screenshots and instructions)
* https://www.reddit.com/r/SmartThings/comments/jwqskf/automations_more_than_one_action_for_the_same/

Tuesday, March 22, 2022

Mangled Metaphors and Corrupted Cliché's

This is a selection of entertaining mixed or mangled trite phrases (cliché's) that I remembered or saved along the way.

The Original Set

  • "It's not like I'm taking money out of anyone's mouth."
    • Context: This was stated during a conversation about the ethics of using software without paying for a license, or what Bill Gates likes to over-dramatically call "pirating" it.
    • Contributing Cliché: "taking money out of someone else's pocket"
    • Contributing Cliché: "taking food out of someone else's mouth"
  • "That will be the needle that broke the haystack."
    • This was stated by someone who fumbled nearly everything they tried to say, but still tried to inject a colloquial saying here and there, to try making their point even more ridiculous.
    • Contributing Cliché: "the straw that broke the camel's back"
    • Contributing Cliché: "finding a needle in a haystack"
  • "It's just a blimp on my radar."
    • Said by someone who didn't start life speaking English, so... good try.  I suppose, depending on whether the blimp is made of radar-reflective material, this could be ironic, or it could just be absurd.  Funny either way.
    • Contributing Cliché: "a 'blip' on radar"
  • "I'll let you bury your own hole."
    • Context: This was a feeble attempt to declare intent not to interfere in someone else's conflict.  M.C. Escher probably would have tried to paint a picture of this.
    • Contributing Cliché: "dig yourself deeper into a hole"
    • Contributing Cliché: "bury a bone / body / problem /etc."
  • "If I were you, I wouldn't hedge your bets."
    • Context: Hedging is a somewhat negative notion (betting against yourself), so this was a double negative in a way, but if taken literally, it is at least bad advice.  The application of pronouns is also a little hard to parse.
    • Contributing Cliché: "I would hedge my bets"
  • "If you need me, I'll be out rattling some more trees."
    • Context: Reasonably sure this was intended to mean the person planned to talk to additional contacts about something.
    • Contributing Cliché: "rattling some cages" (perturbing captive animals)
    • Contributing Cliché: "shaking some trees" (attempting to dislodge fruits or nuts growing on the tree)
  • "I don't have a horse in this fight."
    • Context: The person was surely intending to say he didn't have a stake or interest in the outcome of an argument.
    • Contributing Cliché: "have a dog in the fight" (reference to the practice of dog fighting)
    • Contributing Cliché: "have a horse in the race" (reference to a sport in which horses are more commonly used)
  • "We'll cross that bridge when it gets here."
    • Context: From a certain relative-motion perspective, this isn't necessarily an incorrect way to suggest waiting until a decision point is reached to actually make the decision, but...
    • Contributing Cliché: "cross that bridge when we come to it"
  • "It's a great place to flex those wings."
    • Context: Attempt to describing an "practice environment" which is particularly conducive to improving skills and increasing knowledge.
    • Contributing Cliché: "flex your muscles" (demonstrate strength)
    • Contributing Cliché: "spread your wings" (expand upon basic abilities and develop them in a place with fewer constraints / guardrails)

New ones...

  • "Easy Hanging Fruit"
    • Context: Discussion of most beneficial tasks to prioritize based on relative cost/benefit
    • Contributing Cliché: "low hanging fruit"
    • Contributing Cliché: "easy" (as generally used to describe something requiring little effort)
    • Commentary: As mangled, this cliché starts to sound a bit risqué.

Friday, January 7, 2022

Irritating Paypal Website Bug - Quick Security Check

Summary

When setting up Paypal as a method of payment, for instance, from Coinbase, in some circumstances, Paypal will prompt for a "Quick security check."  If there isn't a qualifying phone number already associated with the Paypal account, the prompt will also display "Please add a phone" with a link labeled "Add phone."

Note: What makes a number valid for use in the "Quick security check" doesn't seem to be clearly explained.  Based on (speculative) comments in some related forum discussions, it seems the key is that the name associated with the number in the CNAM (telco) directory database matches the name on the Paypal account.  Google Voice numbers seem to have no such entry, and therefore can't be used for this.  A physical mobile account with one of the major U.S. providers (Verizon, T-Mobile, ATT, etc.) seems to be the only option.

The trouble is caused when the size of the popup box for Paypal verification is not big enough to display the form to enter the phone number.  Clicking "Add phone" appears to do nothing.  To me, this falls somewhere between frustrating and infuriating. 

Note: The instructions here are primarily applicable to Windows 10 with a current/recent version of Google Chrome browser, so other OS's and/or other browsers may work a little differently.

What it Looks Like


Workaround

1. Right click (or whatever the equivalent is in your OS + web browser) the title bar of the popup dialog window and choose "Show as tab"


2. Resize the "tabbed" window to be sure it is wide enough to show the form to the right of the "Add phone" link, where there is another link with a "+" icon beside it, also labeled "Add phone."

Note: This is really where the bug exists.  If the window is sized too small/narrow, the form that actually allows adding a phone just disappears.



3. Finally, click the "+ Add Phone" link to display the text field that allows a phone number to be typed in.  From here, things work as expected


4.