boost-asio作为守护进程的“模板”

Question

我正在尝试将一些在Linux中作为控制台应用程序运行的演示代码转到守护进程中。

SDK在c++中，所以我去寻找c++代码，它完成了守护进程需要做的所有事情，比如启动、分叉、分离、将std重定向到syslog、处理信号等等。

所以我找到了这个例子：

// daemon.cpp
// ~~~~~~~~~~
//
// Copyright (c) 2003-2011 Christopher M. Kohlhoff (chris at kohlhoff dot com)
//
// Distributed under the Boost Software License, Version 1.0. (See accompanying
// file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
//

#include <boost/asio/io_service.hpp>
#include <boost/asio/ip/udp.hpp>
#include <boost/asio/signal_set.hpp>
#include <boost/array.hpp>
#include <boost/bind.hpp>
#include <ctime>
#include <iostream>
#include <syslog.h>
#include <unistd.h>

using boost::asio::ip::udp;

class udp_daytime_server
{
public:
  udp_daytime_server(boost::asio::io_service& io_service)
    : socket_(io_service, udp::endpoint(udp::v4(), 13))
  {
    start_receive();
  }

private:
  void start_receive()
  {
    socket_.async_receive_from(
        boost::asio::buffer(recv_buffer_), remote_endpoint_,
        boost::bind(&udp_daytime_server::handle_receive, this, _1));
  }

  void handle_receive(const boost::system::error_code& ec)
  {
    if (!ec || ec == boost::asio::error::message_size)
    {
      using namespace std; // For time_t, time and ctime;
      time_t now = time(0);
      std::string message = ctime(&now);

      boost::system::error_code ignored_ec;
      socket_.send_to(boost::asio::buffer(message),
          remote_endpoint_, 0, ignored_ec);
    }

    start_receive();
  }

  udp::socket socket_;
  udp::endpoint remote_endpoint_;
  boost::array<char, 1> recv_buffer_;
};

int main()
{
  try
  {
    boost::asio::io_service io_service;

    // Initialise the server before becoming a daemon. If the process is
    // started from a shell, this means any errors will be reported back to the
    // user.
    udp_daytime_server server(io_service);

    // Register signal handlers so that the daemon may be shut down. You may
    // also want to register for other signals, such as SIGHUP to trigger a
    // re-read of a configuration file.
    boost::asio::signal_set signals(io_service, SIGINT, SIGTERM);
    signals.async_wait(
        boost::bind(&boost::asio::io_service::stop, &io_service));

    // Inform the io_service that we are about to become a daemon. The
    // io_service cleans up any internal resources, such as threads, that may
    // interfere with forking.
    io_service.notify_fork(boost::asio::io_service::fork_prepare);

    // Fork the process and have the parent exit. If the process was started
    // from a shell, this returns control to the user. Forking a new process is
    // also a prerequisite for the subsequent call to setsid().
    if (pid_t pid = fork())
    {
      if (pid > 0)
      {
        // We're in the parent process and need to exit.
        //
        // When the exit() function is used, the program terminates without
        // invoking local variables' destructors. Only global variables are
        // destroyed. As the io_service object is a local variable, this means
        // we do not have to call:
        //
        //   io_service.notify_fork(boost::asio::io_service::fork_parent);
        //
        // However, this line should be added before each call to exit() if
        // using a global io_service object. An additional call:
        //
        //   io_service.notify_fork(boost::asio::io_service::fork_prepare);
        //
        // should also precede the second fork().
        exit(0);
      }
      else
      {
        syslog(LOG_ERR | LOG_USER, "First fork failed: %m");
        return 1;
      }
    }

    // Make the process a new session leader. This detaches it from the
    // terminal.
    setsid();

    // A process inherits its working directory from its parent. This could be
    // on a mounted filesystem, which means that the running daemon would
    // prevent this filesystem from being unmounted. Changing to the root
    // directory avoids this problem.
    chdir("/");

    // The file mode creation mask is also inherited from the parent process.
    // We don't want to restrict the permissions on files created by the
    // daemon, so the mask is cleared.
    umask(0);

    // A second fork ensures the process cannot acquire a controlling terminal.
    if (pid_t pid = fork())
    {
      if (pid > 0)
      {
        exit(0);
      }
      else
      {
        syslog(LOG_ERR | LOG_USER, "Second fork failed: %m");
        return 1;
      }
    }

    // Close the standard streams. This decouples the daemon from the terminal
    // that started it.
    close(0);
    close(1);
    close(2);

    // We don't want the daemon to have any standard input.
    if (open("/dev/null", O_RDONLY) < 0)
    {
      syslog(LOG_ERR | LOG_USER, "Unable to open /dev/null: %m");
      return 1;
    }

    // Send standard output to a log file.
    const char* output = "/tmp/asio.daemon.out";
    const int flags = O_WRONLY | O_CREAT | O_APPEND;
    const mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;
    if (open(output, flags, mode) < 0)
    {
      syslog(LOG_ERR | LOG_USER, "Unable to open output file %s: %m", output);
      return 1;
    }

    // Also send standard error to the same log file.
    if (dup(1) < 0)
    {
      syslog(LOG_ERR | LOG_USER, "Unable to dup output descriptor: %m");
      return 1;
    }

    // Inform the io_service that we have finished becoming a daemon. The
    // io_service uses this opportunity to create any internal file descriptors
    // that need to be private to the new process.
    io_service.notify_fork(boost::asio::io_service::fork_child);

    // The io_service can now be used normally.
    syslog(LOG_INFO | LOG_USER, "Daemon started");
    io_service.run();
    syslog(LOG_INFO | LOG_USER, "Daemon stopped");
  }
  catch (std::exception& e)
  {
    syslog(LOG_ERR | LOG_USER, "Exception: %s", e.what());
    std::cerr << "Exception: " << e.what() << std::endl;
  }
}

无论如何，我想知道，这是启动和运行最小守护进程(替换udp服务器代码并用我自己的代码替换)的一个好选择，还是应该考虑另一种获得守护进程功能的方法。

我也不知道我应该从哪里开始我的代码，因为这个例子的最后一步是调用io_service.run()。

我的代码将有两个线程，一个用于侦听连接，另一个用于每10秒处理挂起的连接->来自连接客户端的更新没有更新的时间关键窗口，甚至可以跳过。

谢谢。

Answer 1

如果您正在寻找一个快速和容易的实现，那么这可能是一个好主意。至少，它提供了一种更高层次的处理信号的方法，否则需要对较低级别的机制有相当详细的理解才能得到正确的处理。快速实现可能如下所示：

void connection_thread_main( bool& running )
{
  while ( running )
    ...
}

int main()
{
  ...

  syslog(LOG_INFO | LOG_USER, "Daemon started");
  // Create flag to indicate if daemon is running.  This is used as the
  // condition for which the thread's while loop continue.
  bool running = true;

  // Create threads.
  boost::thread_group threads;
  threads.create_thread( boost::bind( &connection_thread_main,
                                      boost::ref( running ) ) );
  threads.create_thread( boost::bind( &pending_thread_main,
                                      boost::ref( running ) ) );

  // This will block the main thread as long as there is work queued into the
  // service.  In this case, signals are being waited on asynchronously.
  io_service.run();

  // On SIGINT or SIGTERM, io_service.stop() is invoked, causing the main 
  // thread to return from io_service.run().

  // Set the running flag to false and wait on the other threads to finish.
  running = false;
  threads.join_all();

  syslog(LOG_INFO | LOG_USER, "Daemon stopped");
}

有几点需要考虑：

• Boost.Asio提供了优秀的高级网络对象类型.它可能是值得使用的，而不是必须处理较低级别的类型和细节。
• 尽管异步编程具有与生俱来的复杂性，但异步实现可能会提高性能。因为支持线程池在Boost.Asio中相当容易。
• Boost.Asio使信号处理变得容易。
• 如果您决定不使用Boost.Asio，那么这个示例是关于如何去守护进程的一个很好的资源。
• 在快速实现中，我选择尽可能使解决方案具有可读性。因此，主线程基本上是浪费的，因为它只是在等待信号。与其有3个线程，还可以将线程的一个内容放入主循环中，并定期对民意测验进行io_service。 // Create标志，指示守护进程是否正在运行。这用作线程的while循环继续执行的//条件。bool true= true；//创建线程。boost::thread_group线程；threads.create_thread( boost::bind( &connection_thread_main，boost::ref(运行)) )；for (；){ //执行就绪以运行处理程序，但不要阻止等待//未决处理程序就绪。当接收到SIGINT或SIGTERM时，处理程序将准备好运行，并从轮询//调用中运行，从而导致io_service停止。io_service.poll()；if ( io_service.stopped() )中断；. // io_service.stopped_main‘s main content } //将正在运行的标志设置为false，并等待其他线程完成。running = false；threads.join_all()；syslog(LOG_INFO = LOG_USER，“守护进程停止”)；