I created a daemon for running into Mac OS X platform. I made an installer using PackageMaker and the Daemon is installed without problems. It seems that after the installation has finished, I need to reboot the system in order to have the daemon running. I am wondering if I can load and start the Daemon without forcing the reboot?... I have some ideas about it but not sure if is the right way, for example:
Using a shell script that invoke the command: $sudo launchctl load /Library/LaunchDaemons/myService.plist
Using ServiceManagement.framework to manage privilege escalation on the application that will be using the Daemon while is running so the App can if necessary install and load de service. I have to say that the work of the service is required only when a Cocoa App is active.
If any better idea please let me know it people. :D
You should add the daemon load command in the postinstall script of your package (Your Option 1). Anyway, the daemons do have launch-on-demand options so your daemon will only be loaded only if your app requests to load it.
Related
This is a rather beginner question. Apologies for nothing more challening :)
I am running IPFS Desktop on my computer. I downloaded it via the Ubuntu Software Center. I believe it's a snap install. I am using Ubuntu 20.04
I want to be able to access some of the CLI commands for the node that is being run via the IPFS Desktop but when I enter any ipfs command in the terminal, it says command not found. etc.
If I install the ipfs cli then it runs a different node through the terminal. Am I missing something obvious here? How can I access the IPFS Desktop node through the command line?
Thanks!
Without running into distribution/package-specifics, below are two ways that should work on all systems.
Quick ad-hoc solution: point the ipfs CLI client at the node run by IPFS Desktop by passing an explicit API endpoint (ipfs --api=/ip4/127.0.0.1/tcp/5001). You can find exact address via Status_→_Advanced_→_API in WebUI provided by Desktop app.
Alternative is to set IPFS_PATH variable in your env to the directory used by IPFS Desktop, ensuring ipfs CLI tool uses the same repo as Desktop app. This is especially useful when you need to run a command that does not work over API and requires direct access the repository (like ipfs key export|rotate).
Thank you all for your answers. I believe the problem was in installing it using snap store (Ubuntu Software Center) because this changes the default path of the installations. So in effect, the desktop and cli were installed at separate paths.
I followed the installation on the IPFS site which uses the install script and that put it in the correct path.
So I re-installed only the CLI and use the webUI in place of the desktop. Along with IPFS Companion, desktop is not really needed.
But I still wanted the functionality of having the desktop run the daemon behind the scenes without having a terminal open, so I created the following service unit file to do that:
Paste the following code in the file /etc/systemd/system/ipfs.service
[Unit]
Description=IPFS Daemon
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/ipfs daemon
User=user
Restart=on-failure
[Install]
WantedBy=default.target
Then I simply ran sudo systemctl start ipfs in a terminal to get the daemon running as a service.
Thanks!
Yes IPFS should not be installed as a snap as you discovered it creates a second path. Installation is preferred by deb over appimage as the appimage limits user to only GUI interface. Another possible pitfall in the future could be the definition of "daemon" and "cluster". These are true to Unix definitions so a "daemon" is a service that manages a number of nodes on the same machine. Cluster is for multiple nodes that are physically seperated to different machines and locales. Other than that I'd say you are on the right path!
I'm trying to get an electron forge app running on my Windows 10 machine via Linux on windows (using the new built-in windows bash functionality).
When running electron-forge start I am getting back the error message:
[1484:1126/222326.466455:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /mnt/c/.../node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.
From some searching, this thread on the electron Github makes it pretty clear that this is somewhat by design and the way to get around it is to run chmod as a root user post-installing all of the dependencies.
I attempted to do this and the command looked like it had worked (no error on running the chmod to 4755), but that didn't fix running electron-forge start - I still got the same error message. I looked into that a bit and it seems that this has to do with what files the linux subsystem are allowed to control permissions for per this Microsoft thread.
Is there some other trick to getting electron forge to work with bash on Windows?
I found that running the electron-forge init from Windows powershell into a native Windows directory allowed me to subsequently use npm start in my-app (for example) in WSL. So ultimately what I ran was
powershell npx create-electron-app my-app
(I have alias powershell="/mnt/c/windows/system32/WindowsPowerShell/v1.0/powershell.exe" in my .bashrc file)
I am using Mac OS X 10.7.3. I installed tomcat6 via macports 2.0.4. I put the tomcat6 location in myeclipse for spring 10 server configuration. Everything was fine so far.
Then I tried to start it in myeclipse. It could not start, saying something like 8080 port is already in use.
Then I went to terminal.
ps aux | grep tomcat
4 process showed up. It seemed tomcat6 started automatically after the installation. Then I tried to stop it with
sudo tomcatctl stop
Here came the problem. No matter how I tried, it always says
Stopping Tomcat...(pid ****)............... giving up.
I tried to kill the process but it kept starting tomcat again right after the kill.
How do I stop it and let myeclipse take over it? Any help is appreciated.
Thanks,
Milo
try doing sudo port unload tomcat6
This command replaced interacting with launchctl yourself, but im unsure if it supports a -w switch which would typically remove the launch daemon were it used with launchctl unload meaning you wouldnt run into the magic restart problem.
I am trying to set up a small web server on my old mac mini G4 at home using the technologies mentioned in the title. I have learned that to serve anything on port 80, the server has to be started with sudo. Since I am using RVM to manage my Ruby Gems, I use rvmsudo to start the server.
I have created a user for running the server, and I can start the server by logging in via SSH and typing 'rvmsudo unicorn -p 80'. But of course when I close the connection the process is terminated, so this is obviously not the way to go.
What is the 'right' way to set up a server on Mac OS Leopard? Keeping in mind that I would like to keep using RVM to manage my gems. I would also like the server to start running automatically when the computer is booted.
you could use the tool GNU screen
http://www.gnu.org/software/screen/
and detach the screen, so the processes will continue running.
alternatively, you could try if this command does the trick:
rvmsudo unicorn -p 80
I have created Cocoa app which is type of launch agent. To distribute this I have created package as well which installs the app and copies the launchagnet plist file in /Libraries/LaunchAgents.
Now the problem is after installation i want this app to be running in user context immediately without logoff/restart. If I register this with "launchctl" from installer, using post install script, it run in root context, as installer is running in root context.
Any suggestion how the agent registers itself to launchctl and runs in user context.
Try this in the postinstall script:
/usr/bin/sudo -u $USER /bin/launchctl load -S Aqua /Library/LaunchAgents/com.yourcompany.launchagent.plist
Note that if multiple users are logged in via Fast User Switching, this will only activate your launch agent for the user who installed it.
There is an unsupported way to make this work with multiple users logged in on Mac OS X 10.5/10.6, using launchctl bsexec; see this mailing list post for more information.