0

Given a service name(created by user) and its path, how can I load and start the service at runtime from a C++ program in Ubuntu.

Does there exists functions similar to the Windows functions such as CreateService, OpenSCManager, OpenService, etc. for doing this?

5
  • So, you want to create C++ front-end, which will ask user for service executable and arguments provided to it. Then it will launch that service and shutdowns itself while service will be running? Am I right, if I understand it this way?
    – kravemir
    Commented Feb 2, 2015 at 10:05
  • @Miro: Yes. But the program needn't shutdown and I should be able to Close the service also.
    – Jackzz
    Commented Feb 2, 2015 at 10:14
  • I have implemented the windows part.And now trying the Linux counterpart. But not sure how to do it..
    – Jackzz
    Commented Feb 2, 2015 at 10:15
  • I don't think you should expect people here to know what CreateService does, as Microsoft has a tendency to come up with new names for things when they create functionality in Windows already available in other systems (like Folder for directory) . Are you talking about starting and stopping daemons? How would those be created by a user?
    – Anthon
    Commented Feb 2, 2015 at 11:30
  • @Anthon : I am talking about creating a daemon itself..
    – Jackzz
    Commented Feb 2, 2015 at 11:32

4 Answers 4

3

For starters this should be on StackOverflow, not here.

The whole concept you know from Windows with services simply does not exist on Linux.

On Windows your process registers a callback that the Service Control Manager (SCM) uses to initialize and control your service. This way requests sent to the SCM pertaining to your service can be processed, such as pause, stop, start, resume.

On Linux the concept doesn't exist as such. The closest are programs running as a daemon.

Any program can opt to detach from its parent (by double-forking) and can also detach from the terminal. This is essentially the gist of a daemon on Unix in general. It's a background process, but unlike on Windows there is no special third party involved.

Well, almost. The init process will make sure the process gets collected (and doesn't stay around after exiting). Also, usually some init scripts (old-style) or an init system (systemd, upstart etc) will be used with a special syntax to control a process. For this, most daemons will have an option to store their process ID (PID) in a file from where such scripts can read it and then use the kill program to send a signal to control execution of the daemon (i.e. background process) to tell it for example to re-read its configuration or to stop.

You'll definitely want to buy and read Michael Kerrisk's book "The Definitive Guid to Linux and UNIX System Programming" and perhaps also pick up a classic such as APUE (Advanced Programming in the Unix Environment) if you intend to extend your development to other unixoid platforms (OSX, BSDs ...).

3

On unix-like systems, daemons and what you would call regular processes are the same thing. There is a blurry line between them. In essence, they are separated semantically not by how they work, but what you expect from them. A daemon is simply a process that waits in the background for you to communicate with it, for some event to transpire. If the daemon needs to communicate with users, it is itself responsible for setting up communication: socket (unix or inet), passive observation of the filesystem, device files... Daemons are usually managed by some kind of "service manager" - systemd, upstart, or systemV (which isn't really management, you just keep some pid files to know how to kill them and some init scripts to start them up in an orderly fashion). It really depends on what you want to achieve:

If you want to start a service uniformly under the service manager of your target system, then you should invoke control commands for the system of choice (this is distro-dependent, but systemd is getting more and more widespread). For instance, you would just invoke systemctl start sshd and sshd will start.

If you really just want a background process that does some processing, that's not a daemon at all. If you simply fork and exec, you will create another process (which you can keep in touch with over a pipe), and you can kill the child when you exit, so it dies with you (or leave it an orphan, in which case it becomes more daemonic).

You can double-fork and set the session and close the file descriptors in the child process to become a more proper daemon.

However, it really depends on what you want to achieve. You may be asking the wrong question here, and you are trying to do something that doesn't even make much sense on linux.

1
  • +1 for "becomes more daemonic"
    – Spike0xff
    Commented Apr 21, 2018 at 2:58
1

I have found something similar. A simple watchdog program which runs a service by exec function. You can find it here.

1

Understand what a service is

Services are processes that are running in the background. They are not interactive, they have no controlling terminal. In Linux services are called daemons.

How to manually manage service

via terminal

#run program that should be service, output_file stands for stdout output
./executable_path arg1 arg2 > output_file

#press CTRL-Z - stops process
#move process to the background, prints its PID
bg

#disown process or you may have started process with "nohup"
disown

Now you have service, you may close terminal, service will be still running.

kill "PID print before

And service is dead.

via shell scripts

Script which launches service and saves it's PID into file.

nohup ./executable args > output &
MY_PID=$!
echo $MY_PID > some_folder/service_pid

Script that shutdowns service:

kill `cat some_folder/service_pid`
rm some_folder/service_pid

via C++

You perform same steps as in example with scripts. Just wrap it to C functions like: system, fork and exec*. However, that is programming related stuff, not linux related (unix.stackexchange.com). Search for creation process from c++.

Integration with system service manager

Well. It's quite harder, because Linux has many service managers and not every Linux distribution uses same. User can change service manager as well, so even on same distro you have no guarantee that it will use same service manager.

The most used are upstart and systemd

Not the answer you're looking for? Browse other questions tagged .