I want to use a NextJS app on Fly.io machines, which stop automatically when the main process stops (with exit code 0).
Therefore I wanted to call process.exit(0) after my code has decided that this process is done.
But the edge runtime doesn't have this function, which makes sense if you're really running on the Vercel edge network, but is a problem for me running in my own Docker container
Related
I am evaluating a self-hosted artifactory installation on a trial license. I followed the official installation instructions for the docker container and the linux archive file. Neither of these installation options are working. The artifactory service fails to start.
I have opened an issue to track the problem: https://www.jfrog.com/jira/browse/RTFACT-27182
TL;DR; A component fails, a nasty stack trace appears in the logs, and eventually the services stop.
It would seem that there is a bug in artifactory. I have traced this back to multiple versions and this issue spans multiple years.
The problem appears to be that artifactory cannot get past the bootstrapping/initialization phase when started with artifactoryctl. At a certain point (around 2-5 minutes in) all the services stop and a pid file is left over, which is bad.
The workaround I have found is that the service can pass this initialization phase only after multiple start/stops (3 to be exact). In other words, we call artifactoryctl start, wait for all failures, then artifactoryctl stop and repeat two more times. On the fourth and final start, we will see the service come online (in about 150 - 190s). From then on, the service will start correctly with one call to artifactoryctl start.
I have not yet looked at the systemd unit file. My guess would be that it has/or could be made to have a number of retries to work around this issue and perhapse this issue does not exist when using the service wrapper.
I have also not yet looked again at the docker container which appears to be failing for the same reason. A workaround off the top of my head would be to modify the entrypoint script. If you were to dockerk exec into the container and try the workaround above it would likely terminate the root process and kill the container.
I have a Desktop Entry that calls a shiny app.
Here's my desktop entry
[Desktop Entry]
Type=Application
Comment=App
Name=App
Exec=/usr/bin/Rscript -e "shiny::runApp('~/raspberry_IP/app.R', launch.browser=TRUE)"
Icon=/home/path/to/logo/rpi_logo.png
Terminal=false
Categories=Utility
StartupNotify=true
This runs well and the Shiny application works as expected. However, when I close my browser tab, I see the process is still running.
I am running this application from Ubuntu 20.04 LTS.
If I change my terminal=false to terminal=true. I see that the output of my terminal freezes (the app no longer updates, hence no diagnostic printing). But the terminal is still active (which makes sense given the process is still running). I can CTRL+C out of it to kill it from my terminal, but that's not the desired user behavior.
I see some strategies to stop the app using stopApp() like here. This strategy uses a separate action button to kill the app, so the user has to "manually" stop it. This might work, but I believe it's natural for the user to try to close the tab or Browser (and there's no way for them to know the process is still running, unless they check).
Using this on the server side, does kill the process, but it's recommended against (see here).
session$onSessionEnded(stopApp)
In this case, because my app is running on a local machine, I think I could potentially get away with this (there is only one user at a time), but I was wondering whether there's better practice to implement.
In UFT 14.50 (but I don't think this is version-specific), I face the following problem:
For action-based GUI tests, I can configure for each test using File/Settings/Run what should happen in case of error:
For BPT GUI-based components, I cannot; there is no "Run" section:
Also in the application area for the component, which would be the second place where it would make sense to put this setting, there is no such setting.
I do understand that I can set this setting programmatically using <App>.<TestOrComponent>.Settings.Run.OnError.
I also understand that one can configure this setting in the execution setting for each component call in a BPT test flow script, or BPT test script, but what about interactive component execution for debugging reasons -- I have to change this setting in every component programmatically during runtime if I want to define/change this setting when doing debug runs in the UFT IDE, is this correct?
Bonus question: What is the rationale to hide this setting for a given component?
It's a good question. It's one i had to think about as there are quite a few components involved.
You build your code for BPT application areas in UFT but the BPT test itself is designed to be managed and executed from ALM. Around version 11 or 12 HP (the vendor at the time) updated the remote agent to have "debug mode" (the top option in these settings):
If you've not seen this you window, you get it from right clicking on the remote agent on your system tray:
(you can also set it by updating the mic.ini file - shout if you need more info on this)
I've not used BPT for about a decade, but that option in the remote agent I am very aware of. POTENTIALLY The run option you're after doesn't exist because, for BPT and it's aLM dependency, it's now all controlled through that debug run setting.
With it CHECKED, when you run a test from ALM you get the popup on error
With it UNCHECKED, when you run a test from ALM, if it hits an issue the error popup is suppressed.
You don't need to set your options programatically.
Bonus points answer: Logically this makes sense as you're potentially kicking off an entire test set from ALM and if you had 1 bad object/line in the first test and it blocked an entire overnight run you'd be fairly angry. At least this way you have your local machine as a deubg run but all remote execution machines have it unchecked so they just keep going. It becomes a machine configuration and not a script configuration.
If this doesn't work as you expect there are other ways of using a common function library with environment variables to set all to debug or all to carry-on mode.
We are running Selenoid Grid on a three node cluster (that is also running Kubernetes). Every so often when running some robotframework tests the same test in Chrome browser on the grid we see ERR_NETWORK_CHANGED when we open browser page and test fails. We never see this when not running in Grid.
Captured tcpdump and saw (RST, ACK) coming from docker container for chrome browser. Would appreciate any suggestions on how to debug this.
And yes, we do plan on moving the Grid to its own nodes (as there could be conflict between Kubernetes and Selenoid as we are not running the Kubernetes version).
We are hosting a flex product on Azure. Till recently we were using the bin debug version and things were working, albeit slow. When we switched to the bin-release version, we are facing 2 errors
a) In some cases, the switching between modules doesn't work.(We have a parent container that calls the modules). On pressing Back button, parent container flips out module B, but not able to get in module A
b) Module A/B are unable to call an xml file, resident on the server using url-loader.
As we don't get any error reported for these, I am not clear where the issue is.
Do these issues pertain to security/ mistakes in deployment? Any pointers will help
Thanks