I'm getting this after a build on openSUSE. Does anyone knows how to fix it?

I: Program is using implicit definitions of functions getting
pointers or implemented by macros. These functions need to use their
correct prototypes to allow correct argument passing on e.g. x86_64 .

• Implicit memory/string functions need #include <string.h>.
• Implicit *printf functions need #include <stdio.h>.
• Implicit *printf functions need #include <stdio.h>.
• Implicit read functions need #include <unistd.h>.
• Implicit recv functions need #include <sys/socket.h>.
  W: daemonize implicit-pointer-decl daemonize.c:283

I: Program returns random data in a function
E: daemonize no-return-in-nonvoid-function daemonize.c:531

I: Program returns random data in a function
E: daemonize no-return-in-nonvoid-function daemonize.c:531

@bmc My search lead me to the issue described in Daemonize and logrotate

I'm trying to roll my logs by using Apache's rotatelogs command.
Like you mentioned, there are several others that are similar (e.g. tinylog, multilog, etc.)

I'm executing like this:
myprogram 2>&1 | rotatelogs

I think combining daemonize with log rotator would be very powerful and not a feature bloat.
Please note, that the venerable logrotate does not have the same functionality, here's a good writeup why

Are there any other options that I might be missing?

Thanks,
D.

I'm passing in a several environment variables to daemonize to launch a java application. I'm getting some bizarre entries, though. (See below) *None of the variables names or keys are actually in use.

This is an capture of the /proc//environ file after the application has launched (notice the ?<> characters):

These are the switches passed to daemonize:

-E MEMCACHED_PORT=11211 -E MEMCACHED_HOST=myhost.local.domain -E MEMCACHED_TIME_TO_LIVE=3600000 -E MEMCACHED_TIMEOUT=2000 -E ENV1_CRYPTO_KEY=nmyKPIRLMFjM7FQnIXe0G2QuCg9tbei7py87XqgStM9UHFmiP0yS1EtKPkiJBwy -E MY_URL=http://api.myhost.local.domain -E ID=someservice.ip.domain.name.something -E SOME_SPECIAL_KEY=ei7py87XqgStM9UHFmiP0yS -E SOME_SECRET=nmyKPIRLMFjM7FQnIXe0G2QuCg9tb -E MEAT_URL=https://nom.nom.meat.us/imaeatmesome -E SOME_OTHER_CRYPTO_KEY=nmyKPIRLMFjM7FQnIXe0G2QuCg9tbei7py87XqgStM9UHFmiP0yS1EtKPkiJBwy -E DID_I_MENTION_ANOTHER_KEY=nmyKPIRLMFjM7FQnIXe0G2QuCg9tbei7py87XqgStM9UHFmiP0yS1EtKPkiJBwy -E ID_CRYPTO_KEY=nmyKPIRLMFjM7FQnIXe0G2QuCg9tbei7py87XqgStM9UHFmiP0yS1EtKPkiJBwy -E TEST_VAR=ASDF

Am I running into some memory limit or something? Has anyone else experienced this behavior? When these characters show up, the application dies because the affected variables are not recognized.

Changing line 20 of the Makefile.in to:

$(CC) $(CFLAGS) -c $&lt; -I. -I$(srcdir)

and line 44 to:

$(INSTALL) -m 0644 $(srcdir)/daemonize.1 $(DESTDIR)$(INSTALL_MAN)/man1

Fixes the problem.

... at least with -o / -e, since these log files then open as fd 0 and/or 1. Maybe daemonize should call redirect_fds() in daemon.c before anything else (not after opening -o / -e)

Also, docs seem to imply that daemonize closes all fd's before starting the daemon. The daemon itself is not supposed to close all fd's, since otherwise it loses locking. But the question is what to do before starting the daemon (or daemonize itself, since it currently doesn't close fd's >= 3 and caller has to close those manually).

It seems that daemonize has a lot that it can do to meet various needs. But in the simplest cases, is there anything missing from just doing

# bash -c 'cd /; setsid sleep 10000 </dev/null &>/dev/null & jobs -p %1'
9864
# ps -p 9864
      PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND
     9864       1    9864       6632  ?           1009 17:40:35 /usr/bin/sleep

as described here?

Since null_fd is used as stdin (not only stdout/stderr), it must be opened as O_RDWR, not O_WRONLY as today.

I am running a process using the -o and -e flags, but it doesn't seem to be logging stdout and stderr to these files. I have created the files beforehand, in case daemonize doesn't autocreate them, but I am not getting any output in them.

I am running Oracle Linux Server release 6.5.

I see in a source file that functions like "fopen" and "getenv" are used before the function "execvp" will be called. Would you like to improve your program design if you consider information like the following?

... Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. ...

% autoreconf --install --verbose --force
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal --force 
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
autoreconf: configure.in: tracing
autoreconf: configure.in: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for `config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader: 
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows one to define a template without
autoheader: WARNING: `acconfig.h':
autoheader: 
autoheader: WARNING:   AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader:             [Define if a function `main' is needed.])
autoheader: 
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
autoheader: warning: missing template: HAVE_BASENAME
autoheader: Use AC_DEFINE([HAVE_BASENAME], [], [Description])
autoheader: warning: missing template: HAVE_FLOCK
autoheader: warning: missing template: HAVE_SETENV
autoreconf: /usr/bin/autoheader failed with exit status: 1

Is there any suggestions to fix this problem?

This bit me in the ass when trying to cross-compile daemonize on illumos. The CFLAGS and LDFLAGS passed to configure don't get passed when building the code.

diff --git a/Makefile.in b/Makefile.in
index 9257b74..40d3dee 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -13,6 +13,8 @@ INSTALL_MAN    = $(INSTALL_PREFIX)/share/man
 MISSING_SOURCES        = @LOCAL_MISSING_SOURCES@
 MISSING_OBJECTS = $(MISSING_SOURCES:.c=.o)
 CC             = @CC@
+CFLAGS         = @CFLAGS@
+LDFLAGS                = @LDFLAGS@
 
 .PHONY: all psman install clean distclean
 
@@ -22,10 +24,10 @@ CC          = @CC@
 all: daemonize 
 
 daemonize: daemonize.o getopt.o $(MISSING_OBJECTS)
-       $(CC) $(CFLAGS) -o daemonize daemonize.o getopt.o $(MISSING_OBJECTS)
+       $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^
 
 testdaemon: testdaemon.o
-       $(CC) $(CFLAGS) -o testdaemon testdaemon.o
+       $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^
  
 psman: daemonize.ps

This patch fixes build warnings on illumos.

diff --git a/daemonize.c b/daemonize.c
index 3d2b40e..606b965 100644
--- a/daemonize.c
+++ b/daemonize.c
@@ -20,10 +20,12 @@
 #include <unistd.h>
 #include <sys/types.h>
 #include <pwd.h>
+#include <grp.h>
 #include <stdarg.h>
 #include <fcntl.h>
 #include <sys/stat.h>
 #include <sys/file.h>
+#include <libgen.h>
 #include "config.h"
 #include "version.h"
 

Daemonize works well and is an important tool I use, but it would be more useful if the program you are daemonizing could have its output directed to syslog for log rotation purposes.

hi.

i install "proxy" with command "npm install -g proxy",and then i run "proxy --port 42780" as follows:

root@AR:~/daemonize# proxy --port 42780
HTTP(s) proxy server listening on port 42780

how to run the command "proxy --port 42780" as a daemon?

Hi there,
Sorry for my ignorance but I'm not sure to understand properly what the command is actually doing...
I'm running on Raspbian (Debian 7.5 on ARM) and I've compiled the tool properly.
So now, I want to daemonize Gogs with the following command but I'n not sure where to find the result of the process and there's no error shown:

Command:
sudo daemonize -c $(pwd)/ -a -e /var/log/gogs.log -p /run/gogs.pid -l /run/lock/gogs.lock -u gogs -v /usr/share/go/src/github.com/gogits/gogs/gogs web

Verbose:
Creating PID file "/run/gogs.pid".
Changing ownership of PID file to "gogs" (999)
Appending to /var/log/gogs.log

I thought I would find it in /etc/init.d/ but I don't see it...
It's not in the running processes either while using ps aux | grep gogs or ps aux | grep daemonize.

Did I misunderstood something about the usage?

Thank you!

This is probably a silly question, but I have a script spawned via daemonize with stdout redirected to a file using daemonize's "-o" option. Trouble is, every time logrotate runs, logging stops.

Is there any way to get daemonize to reopen the logfile? Or a best-practice for using daemonize with logrotate?

Thanks,
Frank

I am using daemonize to covert binaries (of our own software) to daemons. I've experienced an issue where two of these binaries immediately show 100% of a core usage when they are started using daemonize. When I run them in tmux or in the foreground , they report normal CPU usage. Any ideas on what could be causing this ?

Ankit

I use your daemonize /etc/rc.d/S50StartInstrument in order to start some executable as an other user.
The executable needs to set realtime priorities in order to run accordingly. One way to achive this is using the pam_limits.so module, granting limits for a defined session.

what's your opinion about this?

best regards

is it possible to set the environment variables for a process that is being run using daemonize ?

e.g. if I am daemonizing a process abc using daemonize, is it possible to set the variable LD_PRELOAD for it and run it in daemonize as well ? or does the process inherit the environment variables of the user that we run it as in daemonize (-u option)

> uname -a
SunOS 5.10 Generic_141414-09 sun4u sparc SUNW,SPARC-Enterprise

> ./configure --prefix=$HOME/local
creating cache ./config.cache
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for a BSD compatible install... ./install-sh -c
checking for ANSI C header files... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for errno.h... yes
checking for libgen.h... yes
checking for working const... yes
checking for uid_t in sys/types.h... yes
checking for mode_t... yes
checking for pid_t... yes
checking for size_t... yes
checking for ssize_t... yes
checking for 'sig_t' typedef... no
checking for 'struct passwd'... yes
checking for 'pw_comment' field... yes
checking for 'pw_gecos' field... yes
checking for predefined 'bool' type... no
checking for TRUE constant in standard headers... no
checking for FALSE constant in standard headers... no
checking for initgroups... yes
checking for getpgrp... yes
checking for setpgrp... yes
checking for setsid... yes
checking whether getpgrp takes no argument... yes
checking whether setpgrp takes no argument... yes
checking for vprintf... yes
checking for vfork... yes
checking for vfork.h... no
checking for working vfork... yes
checking for strerror... yes
checking for daemon... no
checking for basename... yes
checking for setenv... yes
checking for long file names... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating config.h

***
*** daemonize is released under a BSD-style license.
*** See the LICENSE file distributed with the source code for details.
***


> gmake --debug
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Reading makefiles...
Updating goal targets....
 File `all' does not exist.
   File `daemonize' does not exist.
     File `daemonize.o' does not exist.
    Must remake target `daemonize.o'.
gcc  -c daemonize.c -I.
daemonize.c: In function `main':
daemonize.c:456: error: `LOCK_EX' undeclared (first use in this function)
daemonize.c:456: error: (Each undeclared identifier is reported only once
daemonize.c:456: error: for each function it appears in.)
daemonize.c:456: error: `LOCK_NB' undeclared (first use in this function)
gmake: *** [daemonize.o] Error 1

https://github.com/bmc/daemonize/blob/release-1.7.0/daemonize.c#L456

Thanks

Version 1.7.7, installed from Debian package repo, running as root, works fine except for -p. -p creates a zero-length file of the correct name instead of saving the PID. -l works as expected.

I have a script that I want daemonize, daemonize_me.sh which calls some other python script. For example:

#!/bin/bash 
echo "Before Python"
python --version
/usr/bin/python --version
python somefile.py
which python
echo "After Python"

daemonize /path/to/daemonize_me.sh
Output

Before Python
/usr/bin/python
After Python

It looks like running script with daemonize skipping python instructions. Python is present in $PATH as well.

Hello,

When I try to daemonize a script from a systemd service:

[Unit]
After=network.target
[Service]
ExecStart=/home/vbr/daemonize/daemonize /home/vbr/service/dfhome.sh
[Install]
WantedBy=default.target

the script works randomly; it writes a few bytes to the file and stop working.

The dfhome.sh script is:

#!/bin/sh

while true ; do
/bin/date >> /home/vbr/service/disk_space_report.txt
/usr/bin/du -sh /home/ >> /home/vbr/service/disk_space_report.txt
/bin/sleep 15
done

I have tried to set the stdout to the file and replace the redirection from the script, but it not works.

However, if I exec the script directly without daemonizing it (...ExecStart=/home/vbr/service/dfhome.sh
..) , it works ok. But I prefer to daemonize in order to close files, run in background, dissasociate from terminal, etc.

Thank you.

Regards,
Vic.

I would like to point out that identifiers like "_CONFIG_H_" and "__DAEMONIZE_FLOCK_H__" do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

Did you forget to git tag it? 18869a7 bumps the version to 1.7.8.

Attempting to cross-compile for Android/AArch64 fails with the message:

configure: error: cannot check setpgrp when cross compiling

Full log:

$ mkdir build install
$ cd build
$ env "PATH=<toolchain-path>/bin:$PATH" ../configure --host=aarch64-linux-android --prefix=$(realpath ../install)
checking for aarch64-linux-android-gcc... aarch64-linux-android-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether aarch64-linux-android-gcc accepts -g... yes
checking for aarch64-linux-android-gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... aarch64-linux-android-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for a BSD-compatible install... /bin/install -c
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking for an ANSI C-conforming const... yes
checking for uid_t in sys/types.h... yes
checking for mode_t... yes
checking for pid_t... yes
checking for size_t... yes
checking for ssize_t... yes
checking for 'sig_t' typedef... yes
checking for 'struct passwd'... yes
checking for 'pw_comment' field... no
checking for 'pw_gecos' field... yes
checking for predefined 'bool' type... no
checking for TRUE constant in standard headers... no
checking for FALSE constant in standard headers... no
checking for initgroups... yes
checking for getpgrp... yes
checking for setpgrp... yes
checking for setsid... yes
checking whether getpgrp requires zero arguments... yes
checking whether setpgrp takes no argument... configure: error: cannot check setpgrp when cross compiling