Yocto in Docker yields pseudo inode errors - docker

We are currently building an embedded Linux OS using Yocto inside an Docker container. All persistent directories are mounted as volumes.
This is accomplished by generating an conf/site.conf setting those directories:
DL_DIR="/artifacts/downloads"
TMPDIR="/artifacts/tmp"
SSTATE_DIR="/artifacts/sstate_cache"
PERSISTENT_DIR="/artifacts/persistent"
DEPLOY_DIR_IMAGE="/images"
DEPLOY_DIR_IPK="/ipk"
And therefore running the image with
docker run --rm \
-v /opt/yocto/projectname:/artifacts \
-v /opt/deploy/projectname/ipk:/ipk \
-v /opt/deploy/projectname/images:/images \
-it <container>
All of this is working fine, the output is deployed as expected and everything works great.
However, upon rebuilding various recipes due to updates, we see yoctos pseudo build-environment abort()ing frequently. Most of the time its an rm or an tar command being killed.
Almost all errors are ino path mismatches like
path mismatch [1 link]: ino 23204894 db '/ipk/aarch64/glibc-charmap-jis-c6229-1984-a_2.35-r0_aarch64.ipk' req '/ipk/aarch64/locale-base-is-is_2.35-r0.1_aarch64.ipk'.
dir err : 107508467 ['/artifacts/tmp/work/aarch64-agl-linux/glibc-locale/2.35-r0/packages-split/glibc-binary-localedata-nb-no.iso-8859-1/CONTROL'] (db '/artifacts/tmp/work/aarch64-agl-linux/glibc-locale/2.35-r0/packages-split/glibc-binary-localedata-sgs-lt/CONTROL/control') db mode 0100644, header mode 040755 (unlinking db)
Child process exit status 4: lock_held
Couldn't obtain lock: Resource temporarily unavailable.
lock already held by existing pid 3365057.
(I appended the error logs of the this example at the end of this post)
or just plain
path mismatch [1 link]: ino 23200106 db '/ipk/aarch64/libcap-ng-doc_0.8.2-r0_aarch64.ipk' req '/ipk/aarch64/libcap-ng-doc_0.8.2-r0.1_aarch64.ipk'.
Setup complete, sending SIGUSR1 to pid 2167709.
When we were building the same project natively without docker, we never have seen errors like this. So we assume there are some compatibility issues with docker and pseudo. We already tried dockers devicemapper and overlay2 storage drivers.
The current workaround is to delete those affected files manually. But this mostly leads to other problems down the line.
We are out of ideas where to look in solving the problem. No yocto resources regarding pseudo-errors were of any help.
Is there any hint to debug those errors in a meaningful way or do we have to refactor the docker builds somehow to prevent those pseudo-errors?
Logs
Bitbake output
DEBUG: Hardlink test failed with [Errno 18] Invalid cross-device link: '/artifacts/tmp/work/aarch64-agl-linux/glibc-locale/2.35-r0/deploy-ipks/aarch64/glibc-localedata-tk-tm_2.35-r0.1_aarch64.ipk' -> '/ipk/testfile'
ERROR: Error executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:sstate_task_postfunc(d)
0003:
File: '/yoctoagl/external/poky/meta/classes/sstate.bbclass', lineno: 822, function: sstate_task_postfunc
0818:
0819: sstateinst = d.getVar("SSTATE_INSTDIR")
0820: d.setVar('SSTATE_FIXMEDIR', shared_state['fixmedir'])
0821:
*** 0822: sstate_installpkgdir(shared_state, d)
0823:
0824: bb.utils.remove(d.getVar("SSTATE_BUILDDIR"), recurse=True)
0825:}
0826:sstate_task_postfunc[dirs] = "${WORKDIR}"
File: '/yoctoagl/external/poky/meta/classes/sstate.bbclass', lineno: 418, function: sstate_installpkgdir
0414:
0415: for state in ss['dirs']:
0416: prepdir(state[1])
0417: bb.utils.rename(sstateinst + state[0], state[1])
*** 0418: sstate_install(ss, d)
0419:
0420: for plain in ss['plaindirs']:
0421: workdir = d.getVar('WORKDIR')
0422: sharedworkdir = os.path.join(d.getVar('TMPDIR'), "work-shared")
File: '/yoctoagl/external/poky/meta/classes/sstate.bbclass', lineno: 343, function: sstate_install
0339:
0340: # Run the actual file install
0341: for state in ss['dirs']:
0342: if os.path.exists(state[1]):
*** 0343: oe.path.copyhardlinktree(state[1], state[2])
0344:
0345: for postinst in (d.getVar('SSTATEPOSTINSTFUNCS') or '').split():
0346: # All hooks should run in the SSTATE_INSTDIR
0347: bb.build.exec_func(postinst, d, (sstateinst,))
File: '/yoctoagl/external/poky/meta/lib/oe/path.py', lineno: 134, function: copyhardlinktree
0130: s_dir = os.getcwd()
0131: cmd = 'cp -afl --preserve=xattr %s %s' % (source, os.path.realpath(dst))
0132: subprocess.check_output(cmd, shell=True, cwd=s_dir, stderr=subprocess.STDOUT)
0133: else:
*** 0134: copytree(src, dst)
0135:
0136:def copyhardlink(src, dst):
0137: """Make a hard link when possible, otherwise copy."""
0138:
File: '/yoctoagl/external/poky/meta/lib/oe/path.py', lineno: 94, function: copytree
0090: # This way we also preserve hardlinks between files in the tree.
0091:
0092: bb.utils.mkdirhier(dst)
0093: cmd = "tar --xattrs --xattrs-include='*' -cf - -S -C %s -p . | tar --xattrs --xattrs-include='*' -xf - -C %s" % (src, dst)
*** 0094: subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
0095:
0096:def copyhardlinktree(src, dst):
0097: """Make a tree of hard links when possible, otherwise copy."""
0098: bb.utils.mkdirhier(dst)
File: '/usr/lib/python3.9/subprocess.py', lineno: 424, function: check_output
0420: else:
0421: empty = b''
0422: kwargs['input'] = empty
0423:
*** 0424: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
0425: **kwargs).stdout
0426:
0427:
0428:class CompletedProcess(object):
File: '/usr/lib/python3.9/subprocess.py', lineno: 528, function: run
0524: # We don't call process.wait() as .__exit__ does that for us.
0525: raise
0526: retcode = process.poll()
0527: if check and retcode:
*** 0528: raise CalledProcessError(retcode, process.args,
0529: output=stdout, stderr=stderr)
0530: return CompletedProcess(process.args, retcode, stdout, stderr)
0531:
0532:
Exception: subprocess.CalledProcessError: Command 'tar --xattrs --xattrs-include='*' -cf - -S -C /artifacts/tmp/work/aarch64-agl-linux/glibc-locale/2.35-r0/deploy-ipks -p . | tar --xattrs --xattrs-include='*' -xf - -C /ipk' returned non-zero exit status 134.
Subprocess output:
abort()ing pseudo client by server request. See https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
Check logfile: /artifacts/tmp/work/aarch64-agl-linux/glibc-locale/2.35-r0/pseudo//pseudo.log
Aborted (core dumped)
DEBUG: Python function sstate_task_postfunc finished
pseudo.log
debug_logfile: fd 2
pid 1234878 [parent 1234771], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 1234771.
db cleanup for server shutdown, 16:26:33.548
memory-to-file backup complete, 16:26:33.548.
db cleanup finished, 16:26:33.548
debug_logfile: fd 2
pid 997357 [parent 997320], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 997320.
db cleanup for server shutdown, 16:52:05.287
memory-to-file backup complete, 16:52:05.288.
db cleanup finished, 16:52:05.288
debug_logfile: fd 2
pid 30407 [parent 30405], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 30405.
dir err : 20362030 ['/artifacts/tmp/work/aarch64-agl-linux/glibc-locale/2.35-r0/packages-split/locale-base-kab-dz/CONTROL'] (db '/artifacts/tmp/work/aarch64-agl-linux/glibc-locale/2.35-r0/packages-split/locale-base-fr-ca.iso-8859-1/CONTROL/control') db mode 0100644, header mode 040755 (unlinking db)
debug_logfile: fd 2
pid 1901634 [parent 1901625], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 1901625.
db cleanup for server shutdown, 10:40:12.401
memory-to-file backup complete, 10:40:12.402.
db cleanup finished, 10:40:12.402
debug_logfile: fd 2
pid 3365057 [parent 3364988], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 3364988.
debug_logfile: fd 2
pid 3365111 [parent 3365055], doing new pid setup and server start
lock already held by existing pid 3365057.
Couldn't obtain lock: Resource temporarily unavailable.
Child process exit status 4: lock_held
dir err : 107508467 ['/artifacts/tmp/work/aarch64-agl-linux/glibc-locale/2.35-r0/packages-split/glibc-binary-localedata-nb-no.iso-8859-1/CONTROL'] (db '/artifacts/tmp/work/aarch64-agl-linux/glibc-locale/2.35-r0/packages-split/glibc-binary-localedata-sgs-lt/CONTROL/control') db mode 0100644, header mode 040755 (unlinking db)
path mismatch [1 link]: ino 23204894 db '/ipk/aarch64/glibc-charmap-jis-c6229-1984-a_2.35-r0_aarch64.ipk' req '/ipk/aarch64/locale-base-is-is_2.35-r0.1_aarch64.ipk'.
db cleanup for server shutdown, 10:41:32.164
memory-to-file backup complete, 10:41:32.164.
db cleanup finished, 10:41:32.164

Related

Cannot import HOL in Isabelle batch mode from Docker

I'm trying to use HOL in Isabelle in batch mode from Docker, but it can't seem to find HOL.
If I have this My.thy file
theory My
imports HOL
begin
end
and then run this to process the file in batch mode
docker run --rm -it -v $PWD/My.thy:/home/isabelle/My.thy makarius/isabelle:Isabelle2022_ARM process -T My
I get
*** No such file: "/home/isabelle/HOL.thy"
*** The error(s) above occurred for theory "Draft.HOL" (line 2 of "~/My.thy")
*** (required by "Draft.My")
Exception- TOPLEVEL_ERROR raised
However, I can import Main. In more detail, if I change My.thy to be
theory My
imports Main
begin
end
then running the same Docker command as above to run the batch process results in
Loading theory "Draft.My"
### theory "Draft.My"
### 0.039s elapsed time, 0.078s cpu time, 0.000s GC time
val it = (): unit
How can I import HOL Isabelle's batch mode in Docker?

Vaadin: upgraded from v18 to v21: web ui does not load

I upgraded an existing (and working!) Vaadin application that was using v18.0.2 to v21.0.4. With that new version the server side application starts up as usual, it initializes OK and the first requests triggers the frontend compilation (which also seems to work OK, at least the log shows no abnormalities or errors), but the UI just hangs and fails to load (there is a thin blue progress bar at the top of the page which quickly reaches about 50% of the width, then it gets slower and slower and then starves at about 90% of the screen width).
I don't have the slightest clue in which direction I should check or analyze this. Any suggestion or hint what could be wrong here would be highly appreciated!
If I should attach any config or log details to help analyzing this let me know!
Later addendum:
I attach my vaadin_dance.cmd here:
#echo off
:package_entries
set fn=package.json
echo Step 1: Going to remove unsupported Vaadin v19+ entries from %fn%:
pause
rem let user see what we do:
#echo on
type %fn% | findstr /V /C:"#vaadin/application-theme-plugin" > %fn%_1
type %fn%_1 | findstr /V /C:"#vaadin/stats-plugin" > %fn%_2
type %fn%_2 | findstr /V /C:"#vaadin/theme-live-reload-plugin" > %fn%_3
type %fn%_3 | findstr /V /C:"#vaadin/theme-loader" > %fn%_4
rem remove an already existing backup - just in case (if there were one the cp below won't work)
rm %fn%~
rem rename back to original and keep a backup:
cp -b -f %fn%_4 %fn%
rem delete the temp. files":
rm %fn%_?
#echo off
echo unsupported Vaadin v19+ entries removed from %fn%
:local_stuff
echo Step 2: Going to remove project local stuff:
pause
rem let user see what we do:
#echo on
rmdir /S /Q .\target
rmdir /S /Q .\node_modules
rmdir /S /Q .\frontend\generated
rm package.json
rm package-lock.json
rm pnpm-lock.yaml
rm pnpmfile.js
rm tsconfig.json
rm types.d.ts
rm webpack.config.js
rm webpack.generated.js
#echo off
echo project local vaadin-generated stuff removed.
:global_stuff
echo Step 3: Going to remove global stuff: removing pnpm stuff
pause
rem let user see what we do:
#echo on
rm -r -f %USERPROFILE%\.pnpm-debug.log
rm -r -f %USERPROFILE%\.pnpm-state.json
rmdir /S /Q %USERPROFILE%\.vaadin
rmdir /S /Q %USERPROFILE%\.pnpm-store
rem just in case - I encountered them here, too:
rmdir /S /Q D:\.pnpm-store
rmdir /S /Q U:\.pnpm-store
#echo off
echo global vaadin-installed stuff removed.
rem clear (and preload) default repository:
:repo_stuff
echo Step 4: Going to empty m2repository!
pause
rem let user see what we do:
#echo on
rem strange enough I again and again got "access denied" on certain .jars ||-( So we first take ownership...
takeown /R /F %USERPROFILE%\.m2\m2repository
rem ... before removing the stuff:
rm -r -f %USERPROFILE%\.m2\m2repository\*
#echo off
echo m2repository cleaned.
echo.
pause
The process with the above .cmd file is such, that I run first step 1, then I stop it and try to rebuildv(in a different cmd window). If that does not work, I restart it from begin and run steps 1 & 2, then I stop and try to rebuild, etc. At most after steps 1, 2, 3 & 4 I was (at least so far) always able to rebuild and execute my application. That's at least when build with or reverting to v18.0.3. With v21.x I haven't been successful so far. :-(
Second addendum with the console output:
The application starts up OK (i.e. without any error message( up to the point where I see "Tomcat has been started on port: ..."
At that point I direct my browser to that port which triggers the dispatching of the DispatcherServlet. That page never loads and the browser times out, but there is NO error message or anything giving a hint re. the type or cause of the problem on the console:
...
2021-12-17 19:36:03,459 INFO [main] org.springframework.boot.web.embedded.tomcat.TomcatWebServer: Tomcat started on port(s): 8085 (http) with context path ''
2021-12-17 19:36:23,678 INFO [http-nio-8085-exec-1] org.apache.juli.logging.DirectJDKLog: Initializing Spring DispatcherServlet 'dispatcherServlet'
2021-12-17 19:36:23,682 INFO [http-nio-8085-exec-1] org.springframework.web.servlet.FrameworkServlet: Initializing Servlet 'dispatcherServlet'
2021-12-17 19:36:23,689 INFO [http-nio-8085-exec-1] org.springframework.web.servlet.FrameworkServlet: Completed initialization in 2 ms
2021-12-17 19:36:26,103 WARN [http-nio-8085-exec-1] org.apache.juli.logging.DirectJDKLog: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [2,172] milliseconds.
2021-12-17 19:36:26,103 WARN [http-nio-8085-exec-3] org.apache.juli.logging.DirectJDKLog: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [1,457] milliseconds.
2021-12-17 19:36:26,179 INFO [http-nio-8085-exec-4] com.vaadin.flow.spring.SpringInstantiator: The number of beans implementing 'I18NProvider' is 0. Cannot use Spring beans for I18N, falling back to the default behavior
<Console output stops here and browser times out>
Unfortunately there seems no way to attach screenshots here, so I can't provide the output of the WebDeveloper's Network Tab's output here...
The Browser Inspector Console displays:
Fri Dec 17 2021 19:52:01 GMT+0100 (Central European Standard Time) Atmosphere: unload event vaadinPush-min.js:1:40213
Vaadin push loaded vaadinPush-min.js:1:44231
Failed to register/update a ServiceWorker for scope ‘http://localhost:8085/’: Bad Content-Type of ‘text/html’ received for script ‘sw-runtime-resources-precache.js’. Must be a JavaScript MIME type.
Uncaught (in promise) TypeError: ServiceWorker script at http://localhost:8085/sw.js for scope http://localhost:8085/ threw an exception during script evaluation.
Path '/login' is not properly resolved due to an error. Resolution had failed on route: '(.*)' vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58:17000
Uncaught (in promise) TypeError: class heritage e is not an object or null
to http://localhost:8085/VAADIN/build/vaadin-3-1a44b245d20aa3c33130.cache.js:1
266 http://localhost:8085/VAADIN/build/vaadin-3-1a44b245d20aa3c33130.cache.js:765
r http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
promise callback*imports http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
flowInit http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
async*get action/< http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
Z http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
__resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
promise callback*__resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
promise callback*a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
resolve http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
promise callback*resolve http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
render http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
__onNavigationEvent http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
setRoutes http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
<anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
r http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
<anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
<anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
vaadin-3-1a44b245d20aa3c33130.cache.js:1:153
​
How is a non-Vaadin intern supposed to decode that stuff and analyse what's going wrong here?
I got the issue replicated and the problem is that in development mode I got a 400 (Bad Request) in the console from Flow.ts with the faulty response Error 400 Invalid location: Location parameter missing from bootstrap request to server.
The fix was to delete the ./frontend/generated folder after which the application worked as it should when running mvn clean jetty:run. But the vaadin:clean-frontend goal should remove the generated folder in frontend which at least for me was the problem.
Check the inspector and look if there is any exceptions in the console.
I just upgraded to v22.0.1. With that new version my application now loads again! Beats me what was broken in versions 19.0.x - 21.0.4 that caused my application's UI to not load.
But there are still one issue:
The initial page is not the application's main-page but some odd self-additionalManifestEntries-page (see my append
Vaadin v22: Odd page displayed each time after login to application). I always need to reload the main page to enter my actual application.

Why is my containerized Selenium application failing only in AWS Lambda?

I'm trying to get a function to run in AWS Lambda that uses Selenium and Firefox/geckodriver in order to run. I've decided to go the route of creating a container image, and then uploading and running that instead of using a pre-configured runtime. I was able to create a Dockerfile that correctly installs Firefox and Python, downloads geckodriver, and installs my test code:
FROM alpine:latest
RUN apk add firefox python3 py3-pip
RUN pip install requests selenium
RUN mkdir /app
WORKDIR /app
RUN wget -qO gecko.tar.gz https://github.com/mozilla/geckodriver/releases/download/v0.28.0/geckodriver-v0.28.0-linux64.tar.gz
RUN tar xf gecko.tar.gz
RUN mv geckodriver /usr/bin
COPY *.py ./
ENTRYPOINT ["/usr/bin/python3","/app/lambda_function.py"]
The Selenium test code:
#!/usr/bin/env python3
import util
import os
import sys
import requests
def lambda_wrapper():
api_base = f'http://{os.environ["AWS_LAMBDA_RUNTIME_API"]}/2018-06-01'
response = requests.get(api_base + '/runtime/invocation/next')
request_id = response.headers['Lambda-Runtime-Aws-Request-Id']
try:
result = selenium_test()
# Send result back
requests.post(api_base + f'/runtime/invocation/{request_id}/response', json={'url': result})
except Exception as e:
# Error reporting
import traceback
requests.post(api_base + f'/runtime/invocation/{request_id}/error', json={'errorMessage': str(e), 'traceback': traceback.format_exc(), 'logs': open('/tmp/gecko.log', 'r').read()})
raise
def selenium_test():
from selenium.webdriver import Firefox
from selenium.webdriver.firefox.options import Options
options = Options()
options.add_argument('-headless')
options.add_argument('--window-size 1920,1080')
ffx = Firefox(options=options, log_path='/tmp/gecko.log')
ffx.get("https://google.com")
url = ffx.current_url
ffx.close()
print(url)
return url
def main():
# For testing purposes, currently not using the Lambda API even in AWS so that
# the same container can run on my local machine.
# Call lambda_wrapper() instead to get geckodriver logs as well (not informative).
selenium_test()
if __name__ == '__main__':
main()
I'm able to successfully build this container on my local machine with docker build -t lambda-test . and then run it with docker run -m 512M lambda-test.
However, the exact same container crashes with an error when I try and upload it to Lambda to run. I set the memory limit to 1024M and the timeout to 30 seconds. The traceback says that Firefox was unexpectedly killed by a signal:
START RequestId: 52adeab9-8ee7-4a10-a728-82087ec9de30 Version: $LATEST
/app/lambda_function.py:29: DeprecationWarning: use service_log_path instead of log_path
ffx = Firefox(options=options, log_path='/tmp/gecko.log')
Traceback (most recent call last):
File "/app/lambda_function.py", line 45, in <module>
main()
File "/app/lambda_function.py", line 41, in main
lambda_wrapper()
File "/app/lambda_function.py", line 12, in lambda_wrapper
result = selenium_test()
File "/app/lambda_function.py", line 29, in selenium_test
ffx = Firefox(options=options, log_path='/tmp/gecko.log')
File "/usr/lib/python3.8/site-packages/selenium/webdriver/firefox/webdriver.py", line 170, in __init__
RemoteWebDriver.__init__(
File "/usr/lib/python3.8/site-packages/selenium/webdriver/remote/webdriver.py", line 157, in __init__
self.start_session(capabilities, browser_profile)
File "/usr/lib/python3.8/site-packages/selenium/webdriver/remote/webdriver.py", line 252, in start_session
response = self.execute(Command.NEW_SESSION, parameters)
File "/usr/lib/python3.8/site-packages/selenium/webdriver/remote/webdriver.py", line 321, in execute
self.error_handler.check_response(response)
File "/usr/lib/python3.8/site-packages/selenium/webdriver/remote/errorhandler.py", line 242, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.WebDriverException: Message: Process unexpectedly closed with status signal
END RequestId: 52adeab9-8ee7-4a10-a728-82087ec9de30
REPORT RequestId: 52adeab9-8ee7-4a10-a728-82087ec9de30 Duration: 20507.74 ms Billed Duration: 21350 ms Memory Size: 1024 MB Max Memory Used: 131 MB Init Duration: 842.11 ms
Unknown application error occurred
I had it upload the geckodriver logs as well, but there wasn't much useful information in there:
1608506540595 geckodriver INFO Listening on 127.0.0.1:41597
1608506541569 mozrunner::runner INFO Running command: "/usr/bin/firefox" "--marionette" "-headless" "--window-size 1920,1080" "-foreground" "-no-remote" "-profile" "/tmp/rust_mozprofileQCapHy"
*** You are running in headless mode.
How can I even begin to debug this? The fact that the exact same container behaves differently depending upon where it's run seems fishy to me, but I'm not knowledgeable enough about Selenium, Docker, or Lambda to pinpoint exactly where the problem is.
Is my docker run command not accurately recreating the environment in Lambda? If so, then what command would I run to better simulate the Lambda environment? I'm not really sure where else to go from here, seeing as I can't actually reproduce the error locally to test with.
If anyone wants to take a look at the full code and try building it themselves, the repository is here - the lambda code is in lambda_function.py.
As for prior research, this question a) is about ChromeDriver and b) has no answers from over a year ago. The link from that one only has information about how to run a container in Lambda, which I'm already doing. This answer is almost my problem, but I know that there's not a version mismatch because the container works on my laptop just fine.
I have exactly the same problem and a possible explanation.
I think what you want is not possible for the time being.
According to AWS DevOps Blog Firefox relies on fallocate system call and /dev/shm.
However AWS Lambda does not mount /dev/shm so Firefox will crash when trying to allocate memory. Unfortunately, this handling cannot be disabled for Firefox.
However if you can live with Chromium, there is an option for chromedriver --disable-dev-shm-usage that disables the usage of /dev/shm and instead writes shared memory files to /tmp.
chromedriver works fine for me on AWS Lambda, if that is an option for you.
According to AWS DevOps Blog you can also use AWS Fargate to run Firefox/geckodriver.
There is an entry in the AWS forum from 2015 that requests mounting /dev/shm in Lambdas, but nothing happened since then.

YOCTO - First build for BBB

I am trying to use for the first time the Yocto tool for my BeagleBoneBlack.
First I run this bash file to install Yocto:
#!/bin/bash
WKDIR=/work
mkdir -p $WKDIR/beaglebone-black/yocto/sources
mkdir -p $WKDIR/beaglebone-black/yocto/builds
cd $WKDIR/beaglebone-black/yocto/sources
git clone -b morty git://git.yoctoproject.org/poky.git poky-morty
cd $WKDIR/beaglebone-black/yocto/
source sources/poky-morty/oe-init-build-env builds/build-bbb-morty
Then I edited the file local.conf at "build-bbb-morty/conf" diretory:
MACHINE ?= "beaglebone"
and added
DL_DIR ?= "${TOPDIR}/../dl"
IMAGE_INSTALL_append = " kernel-modules kernel-devicetree"
Then I run bitbake:> bitbake core-image-minimal
After about 8 hours in my Core i7 five generation I got this result at my terminal output and I have no idea what I need to do to fix it:
bitbake core-image-minimal
Parsing recipes: 100% |########################################################################################################| Time: 0:02:55
Parsing of 864 .bb files complete (0 cached, 864 parsed). 1318 targets, 67 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Ubuntu-16.04"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "beaglebone"
DISTRO = "poky"
DISTRO_VERSION = "2.2.1"
TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa8"
TARGET_FPU = "hard"
meta
meta-poky
meta-yocto-bsp = "morty:a3fa5ce87619e81d7acfa43340dd18d8f2b2d7dc"
NOTE: Fetching uninative binary shim from http ://downloads.yoctoproject.org/releases/uninative/1.4/x86_64-nativesdk-libc.tar.bz2;sha256sum=101ff8f2580c193488db9e76f9646fb6ed38b65fb76f403acb0e2178ce7127ca
--2017-01-18 15:51:09-- http ://downloads.yoctoproject.org/releases/uninative/1.4/x86_64-nativesdk-libc.tar.bz2
Resolving downloads.yoctoproject.org (downloads.yoctoproject.org)... 198.145.20.127
Connecting to downloads.yoctoproject.org (downloads.yoctoproject.org)|198.145.20.127|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2473216 (2.4M) [application/octet-stream]
Saving to: ‘/work/beaglebone-black/yocto/builds/build-bbb-morty/../dl/uninative/101ff8f2580c193488db9e76f9646fb6ed38b65fb76f403acb0e2178ce7127ca/x86_64-nativesdk-libc.tar.bz2’
2017-01-18 15:51:18 (297 KB/s) - ‘/work/beaglebone-black/yocto/builds/build-bbb-morty/../dl/uninative/101ff8f2580c193488db9e76f9646fb6ed38b65fb76f403acb0e2178ce7127ca/x86_64-nativesdk-libc.tar.bz2’ saved [2473216/2473216]
Initialising tasks: 100% |#####################################################################################################| Time: 0:00:14
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: attr-native-2.4.47-r0 do_fetch: Failed to fetch URL http ://download.savannah.gnu.org/releases/attr/attr-2.4.47.src.tar.gz, attempting MIRRORS if available
WARNING: libpng-native-1.6.24-r0 do_fetch: Failed to fetch URL http ://distfiles.gentoo.org/distfiles/libpng-1.6.24.tar.xz, attempting MIRRORS if available
ERROR: core-image-minimal-1.0-r0 do_image_wic: Function failed: do_image_wic (log file is located at /work/beaglebone-black/yocto/builds/build-bbb-morty/tmp/work/beaglebone-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_image_wic.23788)
ERROR: Logfile of failure stored in: /work/beaglebone-black/yocto/builds/build-bbb-morty/tmp/work/beaglebone-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_image_wic.23788
Log data follows:
| DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_wic
| Checking basic build environment...
| Done.
|
| Build artifacts not found, exiting.<br/>
| (Please check that the build artifacts for the machine
| selected in local.conf actually exist and that they
| are the correct artifacts for the image (.wks file))
|
| The artifact that couldn't be found was kernel-dir:
| /work/beaglebone-black/yocto/builds/build-bbb-morty/tmp/deploy/images/beaglebone
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_image_wic (log file is located at /work/beaglebone-black/yocto/builds/build-bbb-morty/tmp/work/beaglebone-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_image_wic.23788)
ERROR: Task (/work/beaglebone-black/yocto/sources/poky-morty/meta/recipes-core/images/core-image-minimal.bb:do_image_wic) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1771 tasks of which 6 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
/work/beaglebone-black/yocto/sources/poky-morty/meta/recipes-core/images/core-image-minimal.bb:do_image_wic
Summary: There were 2 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
While not sure this could be the reason of the problem, the prefered method to add packages to the image, in the local.conf context is using the CORE_IMAGE_EXTRA_INSTALL variable.
Therefore change:
IMAGE_INSTALL_append = " kernel-modules kernel-devicetree"
to
CORE_IMAGE_EXTRA_INSTALL += "kernel-modules kernel-devicetree"
I think there is no problem with your work method.
It seems to be a build environment problem, but the error log seems to confirm.
your log location at "/work/beaglebone-black/yocto/builds/build-bbb-morty/tmp/work/beaglebone-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_image_wic.23788"
Your error log indicates the the URL for fetching binaries failed.
You can try using tunnel through proxy. Or you can run the bitbake again because it can also fail sometimes due to network conditions.

Supervisord as Windows Service on Cygwin

I am attempting to run Celery as a Windows Service using Supervisord. I followed the configuration laid out on the Celery site and [here][1]. I have set up a virtual environment to run supervisord through cygwin.I have highlighted the lines I think are most important (with **). It appears supervisord and rabbitMQ are working. The problem is with Celery.
I setup the service with the commands:
$ cygrunsrv --install supervisord --path /usr/bin/python --args "/usr/bin/supervisord -n -c /usr/etc/supervisord.conf"
$ supervisord
UPDATED: I now have the following in my supervisord.log file:
2014-08-07 12:46:40,676 INFO exited: celery (exit status 1; not expected)
2014-08-07 12:47:07,187 INFO Increased RLIMIT_NOFILE limit to 1024
2014-08-07 12:47:07,238 INFO RPC interface 'supervisor' initialized
2014-08-07 12:47:07,251 INFO daemonizing the supervisord process
2014-08-07 12:47:07,253 INFO supervisord started with pid 7508
2014-08-07 12:47:08,272 INFO spawned: 'celery' with pid 8056
**2014-08-07 12:47:08,833 INFO success: celery entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)**
The config file is:
[inet_http_server] ; inet (TCP) server disabled by default
port=127.0.0.1:8072 ; (ip_address:port specifier, *:port for all iface)
username = user
password = 123
[supervisord]
logfile= /home/HBA/venv/logFiles/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=10 ; (num of main logfile rotation backups;default 10)
loglevel=info ; (log level;default info; others: debug,warn,trace)
pidfile=/tmp/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false ; (start in foreground if true;default false)
minfds=1024 ; (min. avail startup file descriptors;default 1024)
minprocs=200 ; (min. avail process descriptors;default 200)
;user=HBA ; (default is current user, required if root)
childlogdir=/tmp ; ('AUTO' child log dir, default $TEMP)
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=http://127.0.0.1:8072 ; use an http:// url to specify an inet socket
[program:celery]
command= celery worker -A runLogProject --loglevel=INFO ; the program (relative uses PATH, can take args)
directory= /home/HBA/venv/runLogProject
environment=PATH="/home/HBA/venv/;/home/HBA/venv/Scripts/"
numprocs=1
stdout_logfile= /home/HBA/venv/logFiles/%(program_name)s/worker.log ; stdout log path, NONE for none; default AUTO
stderr_logfile= /home/HBA/venv/logFiles/%(program_name)s/worker.log ; stderr log path, NONE for none; default AUTO
autostart=true ; start at supervisord start (default: true)
autorestart=true ; whether/when to restart (default: unexpected)
startsecs=0
stopwaitsecs=1000
killasgroup=true
My celery log file gives me:
**[2014-08-07 19:46:40,584: ERROR/MainProcess] Process 'Worker-4' pid:12284 exited with 'signal -1'
[2014-08-07 19:46:40,584: ERROR/MainProcess] Process 'Worker-3' pid:4432 exited with 'signal -1'
[2014-08-07 19:46:40,584: ERROR/MainProcess] Process 'Worker-2' pid:9120 exited with 'signal -1'
[2014-08-07 19:46:40,584: ERROR/MainProcess] Process 'Worker-1' pid:6280 exited with 'signal -1'**
C:\Python27\lib\site-packages\celery\apps\worker.py:161: CDeprecationWarning:
Starting from version 3.2 Celery will refuse to accept pickle by default.
The pickle serializer is a security concern as it may give attackers
the ability to execute any command. It's important to secure
your broker from unauthorized access when using pickle, so we think
that enabling pickle should require a deliberate action and not be
the default choice.
If you depend on pickle then you should set a setting to disable this
warning and to be sure that everything will continue working
when you upgrade to Celery 3.2::
CELERY_ACCEPT_CONTENT = ['pickle', 'json', 'msgpack', 'yaml']
You must only enable the serializers that you will actually use.
warnings.warn(CDeprecationWarning(W_PICKLE_DEPRECATED))
[2014-08-07 19:47:08,822: WARNING/MainProcess] C:\Python27\lib\site-packages\celery\apps\worker.py:161: CDeprecationWarning:
Starting from version 3.2 Celery will refuse to accept pickle by default.
The pickle serializer is a security concern as it may give attackers
the ability to execute any command. It's important to secure
your broker from unauthorized access when using pickle, so we think
that enabling pickle should require a deliberate action and not be
the default choice.
If you depend on pickle then you should set a setting to disable this
warning and to be sure that everything will continue working
when you upgrade to Celery 3.2::
CELERY_ACCEPT_CONTENT = ['pickle', 'json', 'msgpack', 'yaml']
You must only enable the serializers that you will actually use.
warnings.warn(CDeprecationWarning(W_PICKLE_DEPRECATED))
**[2014-08-07 19:47:08,944: INFO/MainProcess] Connected to amqp://guest:**#127.0.0.1:5672//
[2014-08-07 19:47:08,954: INFO/MainProcess] mingle: searching for neighbors
[2014-08-07 19:47:09,963: INFO/MainProcess] mingle: all alone**
C:\Python27\lib\site-packages\celery\fixups\django.py:236: UserWarning: Using settings.DEBUG leads to a memory leak, never use this setting in production environments!
warnings.warn('Using settings.DEBUG leads to a memory leak, never '
[2014-08-07 19:47:09,982: WARNING/MainProcess] C:\Python27\lib\site-packages\celery\fixups\django.py:236: UserWarning: Using settings.DEBUG leads to a memory leak, never use this setting in production environments!
warnings.warn('Using settings.DEBUG leads to a memory leak, never '
[2014-08-07 19:47:09,982: WARNING/MainProcess] celery#CORONADO ready.
I solved my issue using the following command: /home/HBA/venv/Scripts/celery worker -A runLogProject --loglevel=INFO
My biggest issue was an unfamiliarity with virtual environments. I needed to make sure the files were in the correct folders within the venv.

Resources