What is the difference between daemon and service ? (In windows or Linux).
A daemon is a background, non-interactive program. It is detached from the keyboard and display of any interactive user. The word daemon for denoting a background program is from the Unix culture; it is not universal.
A service is a program which responds to requests from other programs over some inter-process communication mechanism (usually over a network). A service is what a server provides. For example, the NFS port mapping service is provided as a separate portmap service, which is implemented as the portmapd daemon.
A service doesn't have to be a daemon, but usually is. A user application with a GUI could have a service built into it: for instance, a file-sharing application.
For more details: https://askubuntu.com/questions/192058/what-is-technical-difference-between-daemon-service-and-process
Daemons are processes running in the background and are not in your face.They do certain tasks at set times or responds to certain events.
In Windows, daemons are called services.
Daemon
From wikipedia:
A daemon is a computer program that runs as a background process,
rather than being under the direct control of an interactive user.
For example you want to ping google.com. That means something in your OS should know how to handle the Domain name resolution. That is a daemon.
More to read : Berkeley Internet Name Daemon (BIND)
Service
That name comes from Client Server Model. It means that an application runs as a service on a server, and a client version of the application is used to access the service. For example an Apache HTTP server application is a service on a server and a Chrome Browser is a client on a PC.
More to read: Client Server Model
A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.
A daemon is a subset of services that always run in memory waiting to service a request.
For example - crond , ftpd ,etc
Whereas, a Service is a server application or set of applications that runs in the background waiting to be used, or carrying out essential task. They are basically called in inter-process communication.
For example - httpd
Related
Are there any windows firewalls out there that can be configured, per application, to only allow network connectivity while the application has an open window (i.e. is not running in the background.) For instance, when steam is running in the background, it constantly communicates with the steam store (my DNS server revealed this). I'd like to block this, but allow it when I open the application.
Use case is web service intended to run as an appliance on a headless Raspberry Pi. OS: Raspbian (Debian).
The web service is running under a non-root service account, using a custom-rolled Boost Beast-based web server (avoid!).
What I want to do: provide a button in the web interface, running in a remote user's browser that allows the system to be shut down or rebooted.
What I've tried so far ... (C/C++)
system("/usr/sbin/shutdown -P now"); // (or -r for reboot)
Fails with the messages:
... [3460]: Failed to set wall message, ignoring: Interactive authentication required.
... [3460]: Failed to power off system via logind: Interactive authentication required.
... [3460]: Failed to open initctl fifo: Permission denied
... [3460]: Failed to talk to init daemon.
I also tried creating a wrapper executable that has been SUID-ed to root, that in turn calls system("/usr/sbin/shutdown ...") with identical results. So even with root credentials, shutdown fails. (Also tried /sbin/reboot, which also fails).
The service in question is written in c++, and services a web socket. The web client app sends a web socket request to shut down the system; and the shutdown is performed in the C++ server code. Everything works fine when the server is started in an interactive session; but it does not work when running in a systemd service.
The web server itself is running as a systemd service using a system account (so no login credentials, and I really do not want login credentials for the service account).
I'm perfectly willing to reconfigure the system, or create a service specifically for this purpose if necessary, and to do what I can to address security issues. But I have no clue as to what the path forward is. The issue is particularly pressing because there's no shutdown button on an out-of-the-box Raspberry Pi (although I do plan to address that for my own Pi). The fact that one CAN install a shutdown button on a Raspberry Pi means there must be some what to do it.
Ideally, I'd like to leave the R-Pi in a state that's usable for other purposes. So a no-password boot into a shell isn't an attractive option. I don't think. And rsh-based solutions are unattractive because they would require the appliance to have a preinstalled login account, with pre-installed credentials (and we all know how THAT goes).
I solved the same issue by creating a C++ daemon, running as root, and listening ONLY on local host TCP port, in charge to shutdown the system when contacted by the web service.
Edit: Use https://man7.org/linux/man-pages/man2/reboot.2.html to shutdown the OS.
Is safe to restart Dbus daemon after update on production system ?
Services and daemons use dynamically linked libraries and I use service Needrestart to determine which service should be restarted.
Updates in eg. libc6 causes restart for almost all daemons. I do not allow myself to restart Dbus (which provides communication interface across the system). Is there any potential risk to data loss, deadlock, ...?
My environment is based on Debian (Wheezy, Jessie) with services provides SMTP, HTTP, DNS, DHCP, SMB, FTP, etc... but no X applications.
I'm developing a firmware updater that should download data from a web server and upload it to an Embedded Linux device.
I want a program (client) to start another program (server) before establishing a connection between them and start sending the data. To do that in the same environment is easy: just call QProcess and startDetached(), but I want to do that remotely: I want to start the client in the Desktop machine and, with the device connected via ETH/TCP in a known IP address, click a button which will ask the device to start the server. When the server finishes starting and start waiting for connections, the Desktop app will then open the socket connection and start sending the data. After all data have being send, another command should be send to ask the server to shut down, closing the connection and finishing the file transfer operation.
My question is: how can I do this operation of asking for an application to either start or stop when it is located in a different machine (in an Embedded Linux device while the caller is in a PC)? Notice that the solution must be such that doesn't depend on some extra software (such as a Tcp server) to constantly run on the device - that's precisely what I'm trying to avoid.
This is not related to Qt in any way, because it doesn't provides anything for that purpose.
There are at least two paths from this point:
use SSH from your application to start any process in the remote machine: ssh user#remote-machine "any command here". This can be called using QProcess;
or
write another software to listen to socket commands and start/stop any process you want, then get it running all the time in the remote machine. Then, it's just a matter of changing your client software to send the relevant commands
Beware of any security issue that may arise by allowing the machine to execute arbitrary commands from external sources.
I am running a waveform that has devices on more than one computer. The domain manager and a device manager starts up on one GPP(1). A device manager starts up on the other GPP(2). The domain manager and the device managers are started when the GPP(s) are being boot up.
I can have a procedure for the operator, that states start GPP(2) up first, then GPP(1). But this approach is not preferable. I would like the ability to start the Device Manager on GPP(2) from GPP(1) after the domain manager has been started.
Does REDHAWK have a standard way of starting remote Device Managers?
The DeviceManager is designed to wait for the DomainManager on startup. So, the standard procedure is to add a script to /etc/init.d so that the remote DeviceManager will start up whenever the remote machine running it boots.
To clarify, let's elaborate using your example. Machine 1 will run the DomainManager and DeviceManager(1)/GPP(1). This machine could be at 192.168.1.1. Machine 2 will run DeviceManager(2)/GPP(2). This machine could be at 192.168.1.2.
The DomainManager will start up whenever machine 1 boots. It will wait happily for DeviceManagers to register with it.
Machine 2's /etc/omniORB.cfg file is set to point to 192.168.1.1. When it boots, the DeviceManger will attempt to register with the DomainManager. One of two things will happen:
The DomainManager at 192.168.1.1 is already up and running. In this case, DeviceManager(2) registers successfully and is ready to run applications.
The DomainManager at 192.168.1.1 is not yet running. In this case, DeviceManager(2) will hang out and wait for the DomainManager to come up.