Question about the daemonize result

[silverkorn]

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!

[bmc]

You are misunderstanding what a daemon is, I think. Or, rather, I believe you are confusing a daemon with a Linux service.

The files in /etc/init.d are Linux services. Yes, they run as daemons, but that's only part of what's going on. The files in /etc/init.d are shell scripts that bring those services up and shut them back down. They are the files the operating system uses to ensure that services come back up when the system boots.

Creating a daemon is a lower-level thing. You can create a daemon process without having that process be a service that comes up when the system boots. That's the purpose of daemonize. If you want your daemon to work like a service, then you don't need daemonize. You can simply:

• Create your own /etc/init.d script, patterned after an existing one.
• Use the facilities provided to init scripts to do the daemonizing. For instance, on Raspbian, your init script can pull in /lib/lsb/init-functions (. /lib/lsb-init-functions) to define various helpful shell function. Then, when it's time to start your daemon, you just use start-stop-daemon --start to start the daemon. There's no need for daemonize in that case.

But what if you want to run a daemon, but you either (a) don't want to install the daemon as a Linux service, or (b) you cannot install the daemon as a Linux service (because you don't have root permission)? That's where a program like daemonize comes in.

If your program is a C program, you can do it yourself. Most Linux and FreeBSD C libraries have a daemon(3) function you can call to do exactly that. In fact, when daemonize builds, it looks for that function and uses it, if present. (Otherwise, it rolls its own.)

However, if you want to daemonize a shell script or a Java program or a Python program or something else, it's often easier just to have the daemonize operation done outside the program. It keeps your program simple, among other things.

Essentially, all daemonize does is ensure that:

• Your program runs as a daemon.
• Your program won't get killed if you disconnect from the terminal where you spawned the daemon. (By contrast, if you create the daemon via the shell's "&" or via nohup, there's no guarantee that won't happen.)

Don't confuse running as a daemon with running a Linux service. Running as a daemon is a lower-level notion.

[silverkorn]

Sorry, I always felt that the Linux community referred Linux services directly as daemons. :sweat:

So to summarize, daemonize is a simple and quick way to embed a command/script in a daemon, so it will prepare it's environment (stdout/stderr redirections, pid/lock files, etc.) and run indefinitely in background without necessarily root privileges until it's manually killed, bumped/blocked by another daemon with the same pid and/or lock files or if the system is rebooted?

Thank you.

[bmc]

Right, pretty much. I'd take issue with your "bumped/blocked by another daemon with the same PID and/or lock file" comment, only because I think that's somewhat ambiguous. (A lock file, strictly speaking, doesn't bump any process; a process honoring lock file conventions simply refuses to start if the lock file already exists.) But, overall, you've got it.

Linux users often do refer to services as "daemons". However, strictly speaking, there's still a difference between an officially managed service and a daemon. Nearly all services consist of one or more daemons, but services are officially managed as part of the booting process (or, more formally, as part of the management of operating system run levels). Think of a daemon as the basic building block of a service.

It's entirely possible to spawn a daemon that isn't managed by the operating system's services software. You can do that with a wrapper tool like daemonize, for instance. You can also do that by having a piece of your software make itself into a daemon (e.g., a C program can call the daemon(3) function to make itself into a daemon). Programs that become daemons in that way aren't managed by the operating system's services infrastructure. They're still daemons, though.

[silverkorn]

Perfect, thanks for the clarifications!