I have a daemon process, set up using launchd on Mac. The daemon is running as root. The following line does not launch my UI application -
system("launchctl start com.project.myproj");
But if I go to the terminal and run the same command -> launchctl start com.project.myproj. It launches my application. My question is am i doing something wrong or is system not behaving correctly ?
The problem is that launch daemons started by the system don't have access to Aqua, so your daemon process can't access the desktop environment.
Apple's Technical Note TN2083: Daemons and Agents describes some of this. (See this section on launchd agents.)
Someone asked a similar question about accessing the Aqua environment from an SSH connection.
I'm guessing you need to re-architect your application a bit:
Create a launch agent that runs in every user's Aqua session.
Have the agent connect to your root daemon, or have the root daemon look for an instance of the launch agent.
When signaled by the root daemon, have the launch agent launch the graphical part of the application.
Related
I have created a container via Docker Desktop on a Windows PC and would now like to start this container like a service or daemon during system startup. If successful, the container would be accessible from its own network via 192.168.178.35:80 without a user having to log in and start Docker.
This is really not my favorite topic but I tried to learn about Windows task scheduling.
As you can see here I wrote a short powershell script that starts Docker Desktop.exe and then the container.
start "C:\Program Files\Docker\Docker\Docker Desktop.exe"
sleep 10
docker start 9df2014cdb06
exit
I assigned the script to the SYSTEM user in the task scheduler. (see screenshot 1)
Unfortunately, 192.168.178.35:80 cannot be reached when the system is booted. When I log in, I see that various Docker background processes in Task manager. (See screenshot 2).
However, Docker is no longer accessible in Powershell. (See error message)
PS C:\WINDOWS\system32> docker ps
error during connect: In the default daemon configuration on Windows, the docker client must be
run with elevated privileges to connect.: Get "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/containers/json":
open //./pipe/docker_engine: The system cannot find the file specified.
And starting it from the desktop icon does not succeed either. Instead, the message appears that Docker is already running.
But my container is not running.
How do I get my container running and accessible on Windows after system startup and before user login?
I am trying to run a Docker image on amazon ECS. I am using a command that starts a shell script to boot up the program:
CMD ["sh","-c", "app/bin/app start; bash"]
in order to start it because for some reason when I run the app (elixir/phoenix app) in the background it was crashing immediately but if I run it in the foreground it is fine. If I run it this way locally, everything works fine but when I try to run it in my cluster, it shuts down. Please help!!
Docker was supposed to keep track of your running foreground process, if the process stop, the container stop. The reason your container work when you use command with "bash" because bash wasn't stop.
I guess you use she'll script to start an application that serve in background like nginx or a daemon. So try to find an option that make the app running foreground will keep your container alive. I.e nginx has an option while starting "daemon off"
for some reason when I run the app (elixir/phoenix app) in the background it was crashing immediately
So you have a corrupted application and you are looking for a kludge to make it looking like it somewhat works. This is not a reliable approach at all.
Instead you should:
make it working in background
use systemctl or upstart to manage restarts of Erlang VM on crashes
Please note that it matters where you have your application compiled. It must be the exactly same architecture/container as the production one, with same Erlang, Elixir, OS versions, otherwise nobody guarantees it will be robust or even working.
As the title already summarizes:
How can I start a bash-script automatically, when the computer starts - ideally without the need to log in to windows - using the Microsoft Subsystem for Linux's Bash.
At the moment, this isn't supported, because the WSL session manager service will close after the last bash.exe wrapper instance closes. There are a few options, but the absolute simplest one at the moment is to use the run utility from the Xming developer and just add a shortcut to your startup folder (in the start menu) pointing to
run.exe bash.exe -c "/home/user/daemoninit.sh ; /bin/bash". Unfortunately, if your daemon initialization requires root access, for example, something like sshd, you will need to add an exception to sudoers that allows anybody to run the daemon with root privileges.
Also, there are problems getting it to run as a true Windows system service, since each lxss installation is user-specific. Some people have gotten it to run on system startup, but it launches in a separate Windows session for that user and makes it so you can't launch bash.exe in your current user session.
I have a build job on jenkins that is building my project and after it is done, it opens an ssh shell script on a remote server and transfers files and then stop and starts a daemon.
When I stop and start the daemon from the command line on a RHEL server, it executes just fine. When the job executes in jenkins, there are no errors.
The daemon stops fine and it starts fine. But shortly after starting, the daemon dies suddenly.
sudo service daemonName stop
# transfer files.
sudo service daemonName start
I'm sure that the problem isn't pathing
Does anyone know what could be special about the way Jenkins is executing the ssh shell script that would cause the daemon start to not fully complete?
The problem:
When executing a build through jenkins, the command to start the daemon process was clearly successfully executing, yet after the build job was done, the daemon would suddenly quit.
The solution:
I thought for this whole time that it was jenkins killing the daemon. So I tried many different incarnations and permutations of disabling the ProcessTree module that goes through and cleans up zombie child processes. I tried fooling it by resetting the BUILD_ID environment variable. Nothing worked.
Thanks to this thread I found out that that solution only works for child processes executed on the BUILD machine. I.E. not applicable to my problem.
More searching led me here: Run a persistent process via ssh
The solution? Nohup.
So now the build successfully restarts the daemon by executing the following:
sudo nohup service daemonname start
Jenkins watches for processes spawned by the job and kill them to avoid zombie processes.
See https://wiki.jenkins-ci.org/display/JENKINS/ProcessTreeKiller
The workaround is to override the BUILD_ID environment variable:
BUILD_ID=dontKillMe
We have a project with different processes, and run it by calling erl -pa ebin, mymodule_supervisor:start_link().
We have set up an ubuntu instance on Amazon EC2. Being new to this, how can we run the project remotely, so we can close the connection and the project will continue to run?
We can run the Erlang shell in the background, but we can't our project on it. It would be perfect to see an example.
Method 1: You could build a release package from your code. If done right, this will embed a complete Erlang system (along with your application and its dependencies) in an easily distributable tar file. Using an automatically generated script the node can then be started as a daemon, running in the background even after you close your shell.
A good way to get started is to use Rebar, which already supports release handling out of the box.
Method 2: Use tmux or screen (both easily installed on Ubuntu) to start your node and detach the session. If you choose tmux, the following should work:
Start tmux simply by running tmux from a shell.
From within tmux, start your node with the erl command as before.
Detach your session using Ctrl-b followed by d. Exit your shell. The node should still be running.
The "proper" way to start the supervisor is to call its start_link function from within the start function of your Erlang application.