Unable to run Hangfire job in background continuously - docker

We are trying to run a .Net Core Hangfire Job application in Docker container. We are able to run this application in console(foreground) but if we hit Enter button it is automatically stopped.
When we are trying to run same application in background it is not working. When we start the container the application is starting and automatically getting stopped.
Can anyone help me to run this application in background continuously using Docker, without any issues.

Related

jenkins build process running forever

emphasized text
I want to stop jenkins process after build and start server.
but It's running forever like this...
what should I do?
The application you are starting does not seem to have an end, because it seems you are running a spring boot application. After the successful build you start it rightaway inside the jenkins job. So it will never terminate, because the application is not terminating.
So I think you want to deploy the application somewhere and let it run maybe on the target VM?

Auto attach Jolokia on application restart

I have been trying to attach Jolokia dynamically using the following command:
java -jar jolokia-jvm-1.3.4-agent.jar start <myapplication_regex>
This works successfully. But on application restart, Jolokia terminates.
Is there any workaround for handling the application restart case?
Try to add -javaagent:/path/to/jolokia-jvm-<version>-agent.jar to the application properties so that it gets attached on restart.

How to interact with already running instance via terminal in Mongooseim?

I am using Mongooseim 3.2.0 from the source code on the ubuntu server. Below are concern:
What is the best way to run mongooseim as a service so that it automatically restarts if mongooseim crashes or system restarts?
How to interact via terminal with already running mongooseim instance on the ubuntu server like "mongooseimctl live". My guess is running "mongooseimctl live" will try to create another instance. I just want to see the live logs and interaction and don't want to keep scrolling the long log files for this purpose.
I apologize if the answer to above is obvious but just want to follow the best guidance.
mongooseimctl live or mongooseimctl foreground is mostly useful for development or smoke testing a deployment (unless you're running inside a container). For real world use cases you should start the server in the background with mongooseimctl start.
Back to the container - the best approach for containerised applications is to run them in the foreground, therefore in a container startup script use mongooseimctl foreground.
Once the server is running (no matter how it was started) attaching a shell to troubleshoot issues can be done with mongooseimctl debug. This is the command to use when you get the Protocol 'inet_tcp': the name mongooseim#localhost seems to be in use by another Erlang node error. Be careful if it's a production environment - you can easily take the server down with access to this shell.
If you're just interested in watching logs, with no interactive access to the server internals that the shell offers, a simple tail -f /your-configured-mongooseim-log-dir/* should be enough.
Ubuntu nowadays uses systemd for managing its services' lifetimes. A systemd .service file can be found at https://github.com/esl/MongooseIM/blob/master/tools/pkg/platforms/debian_stretch/files/build/mongooseim.service - we use it for packaging into Debian/Ubuntu .deb packages.

How can I listen for signals from Docker in .Net Core Executable?

I have a console application written in .Net Core. I will be running this in a Docker container. I would like to gracefully stop the process when a docker stop command is given, rather than just letting the process get killed in the middle of doing something. Is there a way that I can listen for this signal from within the console application? Before containers, I would just have the console app listen for something to be typed in the console window. If there is a way to have docker send a message through standard input, I could work with that, I just do not know enough about Docker, yet, to know what is possible.
My solution is going to end up being to not use a console application, after all. I learned that if I create a web project, I can tell when the container has requested a shutdown with the ApplicationStopping CancellationToken in the website's Startup. So, rather than having the container start up a long running console application, it will just host a website that has no web content. The website will just start up my long running process, and when the container sends a signal to the website that it is shutting down, my process can gracefully stop.
public void Configure(IApplicationBuilder app
, IHostingEnvironment env
, IApplicationLifetime applicationLifetime)
{
applicationLifetime.ApplicationStarted.Register(ApplicationStarted);
applicationLifetime.ApplicationStopping.Register(ApplicationStopping);
applicationLifetime.ApplicationStopped.Register(ApplicationStopped);
}
You can pass a command to a running process in a Docker container using docker exec

Marathon - do not redeploy app when return code = 0?

We have a spring boot application deployed in a docker container and managed using mesosphere (marathon + mesos). The spring boot app is intended to be deployed via marathon, and once complete, it will exit with code = 0.
Currently, every time the boot application terminates, marathon redeploys the app again, which I wish to disable. Is there a setting that I can set in the application's marathon json config file that will prevent marathon from redeploying an app if it does not exit with a non-zero code?
If you just want to run one-time jobs, I think Chronos would be the right tool. Marathon is, as Michael wrote, for long-running tasks.
I think there's a principled problem in the understanding of what Marathon does: it is meant for long-running tasks (or put in other words: there's a while loop somewhere in there, maybe an implicit one). If your app exists, Marathon sees this and assumes it has failed and re-starts it again.

Resources