bmc / daemonize Goto Github PK
View Code? Open in Web Editor NEWCommand line utility to run a program as a Unix daemon
Home Page: http://software.clapper.org/daemonize/
License: Other
Command line utility to run a program as a Unix daemon
Home Page: http://software.clapper.org/daemonize/
License: Other
> 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
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.
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)
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
@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.
... 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).
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
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?
% 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?
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.
Did you forget to git tag
it? 18869a7 bumps the version to 1.7.8.
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:
and line 44 to:
Fixes the problem.
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?
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.
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
Since null_fd is used as stdin (not only stdout/stderr), it must be opened as O_RDWR, not O_WRONLY as today.
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.
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"
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
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 .
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
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?
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. ...
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 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!
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.