Есть программа которая работает как демон. Подскажите что нужно поменять (в исходниках или Make файле) что бы она заработала как простая консольная программа?

Здравствуйте, JKC, Вы писали:

JKC>Есть программа которая работает как демон. Подскажите что нужно поменять (в исходниках или Make файле) что бы она заработала как простая консольная программа?

Убрать демонизацию, очевидно. Смотреть в районе вызова setsid(2) либо daemon(3)

Здравствуйте, JKC, Вы писали:

JKC>Есть программа которая работает как демон. Подскажите что нужно поменять (в исходниках или Make файле) что бы она заработала как простая консольная программа?

Правильный путь в этом случае будет — поддержать режим консольной программы (например каким-нибудь флагом запуска) и механизмов консольной программы.

Здравствуйте, 0rc, Вы писали:

0rc>Здравствуйте, JKC, Вы писали:

JKC>>Есть программа которая работает как демон. Подскажите что нужно поменять (в исходниках или Make файле) что бы она заработала как простая консольная программа?

0rc>Правильный путь в этом случае будет — поддержать режим консольной программы (например каким-нибудь флагом запуска) и механизмов консольной программы.
Что за флаги, где их взять и где их ставить?

Здравствуйте, JKC, Вы писали:

JKC>Что за флаги, где их взять и где их ставить?

Никаких особых секретных флагов или общепринятых принципов здесь нет. Флаги ставите вы, выбираете флаги опять же вы.
На ваше усморение, например:

#запускаем в режиме console-mode
./app -c 
#запускаем как daemon
./app

ставим в функции main(), при условии, что пишите на C/С++.

PS: Я хочу сказать, что вместо заменить функциональность с daemon на console, я бы выбрал добавить функциональность console, другим языком — расширил бы функционал.

Здравствуйте, Kemm, Вы писали:

K>Здравствуйте, JKC, Вы писали:

JKC>>Есть программа которая работает как демон. Подскажите что нужно поменять (в исходниках или Make файле) что бы она заработала как простая консольная программа?

K>Убрать демонизацию, очевидно. Смотреть в районе вызова setsid(2) либо daemon(3)
Увы но эти функции отсутствуют.

Здравствуйте, 0rc, Вы писали:

0rc>Здравствуйте, JKC, Вы писали:

JKC>>Что за флаги, где их взять и где их ставить?

0rc>Никаких особых секретных флагов или общепринятых принципов здесь нет. Флаги ставите вы, выбираете флаги опять же вы.
0rc>На ваше усморение, например:
0rc>

0rc>#запускаем в режиме console-mode
0rc>./app -c 
0rc>#запускаем как daemon
0rc>./app 
0rc>

0rc>ставим в функции main(), при условии, что пишите на C/С++.

0rc>PS: Я хочу сказать, что вместо заменить функциональность с daemon на console, я бы выбрал добавить функциональность console, другим языком — расширил бы функционал.

Как запустить в режиме console-mode ?

K>>Убрать демонизацию, очевидно. Смотреть в районе вызова setsid(2) либо daemon(3)
JKC>Увы но эти функции отсутствуют.

гм

и при этом при обычном запуске /path/to/program она демонизится?
если да, то что говорит, к примеру file /path/to/program ?


если он говорит что-то наподобие "/bin/su: setuid ELF 32-bit LSB executable" (у меня Linux), то искать в сорцах fork()/fork() (два раза должен fork делаться)

0rc>PS: Я хочу сказать, что вместо заменить функциональность с daemon на console, я бы выбрал добавить функциональность console, другим языком — расширил бы функционал.

Хотел бы добавить, что это хорошо в случае с какой-то известной программой. Если это собственое творение (внутрипроектное), то imho лучше разрабатывать консольную программу. А потом внешними скриптами или, например, daemontools'ом её deamonize'ить.

Аргумент прост: консольную программу проще отладить.

Здравствуйте, Dair, Вы писали:

K>>>Убрать демонизацию, очевидно. Смотреть в районе вызова setsid(2) либо daemon(3)
JKC>>Увы но эти функции отсутствуют.

D>гм

D>и при этом при обычном запуске /path/to/program она демонизится?
D>если да, то что говорит, к примеру file /path/to/program ?


D>если он говорит что-то наподобие "/bin/su: setuid ELF 32-bit LSB executable" (у меня Linux), то искать в сорцах fork()/fork() (два раза должен fork делаться)
Вот так всё выглядит

#include "main.h"
#include <stdio.h>
int debug =0;
char sb[512];
UINT flag, sock;
time_t the_time, the_start;

#ifdef WIN32
int fork(void) {return 0;}
#endif
extern UINT n_alist;

int main(int argc, char *argv[]) {
            
    printin_file("main");
    time(&the_time);
    the_start = the_time;
    if (argc<2) { printf("Usage: $ %s conf-file", argv[0]); exit(1); }
    flag = 0;
    parse_conf(argv[1], 0);
    flag = 1; //conf parsed ok
#ifndef WIN32
    //daemonize
    int ret;
    ret = fork();
    if (ret == -1) fprintf(stderr, "Could not daemonize process, fork() == -1\n");
    if (ret > 0) exit(0);
    close(0);
    close(1);
    close(2);
    setpgrp();
    ret = fork();
    if (ret > 0) exit(0);
    pid_t pid; 
    pid = getpid();
#else
    UINT pid = GetCurrentProcessId();
    WORD wVersionRequested = MAKEWORD(1,1);
    WSADATA wsaData;
    WSAStartup(wVersionRequested, &wsaData);
    if (wsaData.wVersion != wVersionRequested) exit(1);
#endif
    sock = socket(AF_INET, SOCK_DGRAM, 0);
    if (sock == -1) exit(1);
    struct sockaddr_in sa;
    sa.sin_family = AF_INET;
    sa.sin_addr.s_addr = INADDR_ANY;
    sa.sin_port = htons(2010);
    if (bind(sock, (struct sockaddr*)&sa, sizeof(struct sockaddr)) == -1) exit(1);
    if(init_scheduler()) exit(1);
    while(main_loop());
    //not reached
    return 0;
}

Все что мне нужно это просто консольное приложение . что бы я мог с консоли читать сообщения.

Здравствуйте, Dair, Вы писали:

0rc>>PS: Я хочу сказать, что вместо заменить функциональность с daemon на console, я бы выбрал добавить функциональность console, другим языком — расширил бы функционал.

D>Хотел бы добавить, что это хорошо в случае с какой-то известной программой. Если это собственое творение (внутрипроектное), то imho лучше разрабатывать консольную программу. А потом внешними скриптами или, например, daemontools'ом её deamonize'ить.

D>Аргумент прост: консольную программу проще отладить.
Программу писал не я, я вообще с юникс почти не знаком, просто там нужно кое что поменять а тут этот демон.
Мне как то нужно перевести её в консоль.

Здравствуйте, JKC, Вы писали:

JKC>Вот так всё выглядит
JKC>

JKC>    //daemonize
JKC>    int ret;
JKC>    ret = fork();
JKC>    if (ret == -1) fprintf(stderr, "Could not daemonize process, fork() == -1\n");
JKC>    if (ret > 0) exit(0);
JKC>    close(0);
JKC>    close(1);
JKC>    close(2);
JKC>    setpgrp();
JKC>    ret = fork();
JKC>    if (ret > 0) exit(0);
JKC>

Этот кусок убери. Потом стукни того, кто это писал. 8))

Здравствуйте, Dair, Вы писали:

D>то искать в сорцах fork()/fork() (два раза должен fork делаться)

Кому это он должен?

Здравствуйте, Kemm, Вы писали:

K>Здравствуйте, JKC, Вы писали:

JKC>>Вот так всё выглядит
JKC>>

JKC>>    //daemonize
JKC>>    int ret;
JKC>>    ret = fork();
JKC>>    if (ret == -1) fprintf(stderr, "Could not daemonize process, fork() == -1\n");
JKC>>    if (ret > 0) exit(0);
JKC>>    close(0);
JKC>>    close(1);
JKC>>    close(2);
JKC>>    setpgrp();
JKC>>    ret = fork();
JKC>>    if (ret > 0) exit(0);
JKC>>

K>Этот кусок убери. Потом стукни того, кто это писал. 8))

Большое спасибо, все работает

Здравствуйте, JKC, Вы писали:

JKC>Как запустить в режиме console-mode ?

С таким же успехом как и в Windows запустить service в режиме console-mode, повторяю вам придется изменять исходный код вашего демона.

Здравствуйте, Kemm, Вы писали:

K>Здравствуйте, Dair, Вы писали:

D>>то искать в сорцах fork()/fork() (два раза должен fork делаться)

K>Кому это он должен?

From Unix Programming FAQ:

1.7 How do I get my program to act like a daemon?
=================================================

A "daemon" process is usually defined as a background process that does not
belong to a terminal session. Many system services are performed by
daemons; network services, printing etc.

Simply invoking a program in the background isn't really adequate for these
long-running programs; that does not correctly detach the process from the
terminal session that started it. Also, the conventional way of starting
daemons is simply to issue the command manually or from an rc script; the
daemon is expected to put *itself* into the background.

Here are the steps to become a daemon:

1. `fork()' so the parent can exit, this returns control to the command
line or shell invoking your program. This step is required so that
the new process is guaranteed not to be a process group leader. The
next step, `setsid()', fails if you're a process group leader.

2. `setsid()' to become a process group and session group leader. Since a
controlling terminal is associated with a session, and this new
session has not yet acquired a controlling terminal our process now
has no controlling terminal, which is a Good Thing for daemons.

3. `fork()' again so the parent, (the session group leader), can exit.
This means that we, as a non-session group leader, can never regain a
controlling terminal.

4. `chdir("/")' to ensure that our process doesn't keep any directory in
use. Failure to do this could make it so that an administrator
couldn't unmount a filesystem, because it was our current directory.

[Equivalently, we could change to any directory containing files
important to the daemon's operation.]

5. `umask(0)' so that we have complete control over the permissions of
anything we write. We don't know what umask we may have inherited.

[This step is optional]

6. `close()' fds 0, 1, and 2. This releases the standard in, out, and
error we inherited from our parent process. We have no way of knowing
where these fds might have been redirected to. Note that many daemons
use `sysconf()' to determine the limit `_SC_OPEN_MAX'. `_SC_OPEN_MAX'
tells you the maximun open files/process. Then in a loop, the daemon
can close all possible file descriptors. You have to decide if you
need to do this or not. If you think that there might be
file-descriptors open you should close them, since there's a limit on
number of concurrent file descriptors.

7. Establish new open descriptors for stdin, stdout and stderr. Even if
you don't plan to use them, it is still a good idea to have them open.
The precise handling of these is a matter of taste; if you have a
logfile, for example, you might wish to open it as stdout or stderr,
and open `/dev/null' as stdin; alternatively, you could open
`/dev/console' as stderr and/or stdout, and `/dev/null' as stdin, or
any other combination that makes sense for your particular daemon.

Almost none of this is necessary (or advisable) if your daemon is being
started by `inetd'. In that case, stdin, stdout and stderr are all set up
for you to refer to the network connection, and the `fork()'s and session
manipulation should *not* be done (to avoid confusing `inetd'). Only the
`chdir()' and `umask()' steps remain as useful.

Здравствуйте, Kemm, Вы писали:

K>Здравствуйте, JKC, Вы писали:

JKC>>Есть программа которая работает как демон. Подскажите что нужно поменять (в исходниках или Make файле) что бы она заработала как простая консольная программа?

K>Убрать демонизацию, очевидно. Смотреть в районе вызова setsid(2) либо daemon(3)

Либо fork() и искать место где закрываются стандартные потоки ввода вывода.

Здравствуйте, Alex Alexandrov, Вы писали:

D>>>то искать в сорцах fork()/fork() (два раза должен fork делаться)
K>>Кому это он должен?
AA>From Unix Programming FAQ:

[skip]
И на каких юниксах нынче необходимо два форка делать?

Здравствуйте, Kemm, Вы писали:

K>Здравствуйте, Alex Alexandrov, Вы писали:

D>>>>то искать в сорцах fork()/fork() (два раза должен fork делаться)
K>>>Кому это он должен?
AA>>From Unix Programming FAQ:

K>[skip]
K>И на каких юниксах нынче необходимо два форка делать?

Видимо, на всех, где лидер сессии может случайно заполучить controlling terminal, ненароком сделав что-то вроде open("/dev/tty"). Можно еще O_NOCTTY в open использовать, но

27320 The O_NOCTTY flag was added to allow applications to avoid unintentionally acquiring a
27321 controlling terminal as a side effect of opening a terminal file. This volume of
27322 IEEE Std 1003.1-2001 does not specify how a controlling terminal is acquired, but it allows an
27323 implementation to provide this on open( ) if the O_NOCTTY flag is not set and other conditions
27324 specified in the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 11, General Terminal
27325 Interface are met. The O_NOCTTY flag is an effective no-op if the file being opened is not a
27326 terminal device.

Здравствуйте, Alex Alexandrov, Вы писали:

D>>>>>то искать в сорцах fork()/fork() (два раза должен fork делаться)
K>>>>Кому это он должен?
AA>>>From Unix Programming FAQ:
K>>[skip]
K>>И на каких юниксах нынче необходимо два форка делать?
AA>Видимо, на всех, где лидер сессии может случайно заполучить controlling terminal, ненароком сделав что-то вроде open("/dev/tty").

А что, с двумя форками это не грозит? Или я просто соображаю плохо на ночь глядя?

AA>Можно еще O_NOCTTY в open использовать, но
AA>

AA>27320 The O_NOCTTY flag was added to allow applications to avoid unintentionally acquiring a
AA>27321 controlling terminal as a side effect of opening a terminal file. This volume of
AA>27322 IEEE Std 1003.1-2001 does not specify how a controlling terminal is acquired, but it allows an
AA>27323 implementation to provide this on open( ) if the O_NOCTTY flag is not set and other conditions
AA>27324 specified in the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 11, General Terminal
AA>27325 Interface are met. The O_NOCTTY flag is an effective no-op if the file being opened is not a
AA>27326 terminal device.
AA>

Вот тут тоже "но" непонятно. O_NOCTTY, в соотвествии с выделеным италиком, однозначно не даст управляющий терминал заполучить. А вот отсутствие может, в принципе.