6

I have created a Linux daemon (in C language) to send certain information via UDP to another computer. It requires of course the remote IP address and the port number. I store this daemon in /usr/local/bin/ and I also created a script in /etc/init.d/ to start|stop|restart the daemon.

So far, the IP address and the port number are passed to the daemon, directly by the script. By example, the start() part of the script looks like this:

start() {
  /usr/local/bin/lvsload_udp_s 192.168.122.25 47239
}

So, when the remote IP and/or port number changes, I have to modify my script, instead of modifying some configuration file. It is a bad practice, I know.

What is the best way of passing the arguments to my daemon? Thanks

marcocamejo
  • 798
  • 1
  • 7
  • 20
  • What's to stop you from using a configuration file ? – cnicutar Jul 04 '12 at 22:05
  • 3
    You could, for instance, install a signal handler in your daemon ... and have it re-read a configuration file after receiving the signal: `kill -SIGUSR1 nnn` (where `nnn` is your daemon's pid). – pmg Jul 04 '12 at 22:13
  • 1
    i think it works well, so there is no need for config files. Parsing one config file for only two parameters? – xgwang Jul 05 '12 at 01:28

4 Answers4

6

Why do you think command line parameters are bad?

Configuration files are additional work, since you need to parse them. And going with your example, modifying a configuration file = modifying one file. Modifying a script = modifying one file. Doesn't seem like much of a difference, when you only have a small number of arguments. You can even stick the parameters into variables at the top of the script, which makes it almost like a config file :-) Some scripts even source such "variable setting scripts" so it really looks like a configuration file.

If you can find a reason why command line parameters are bad, then there's a good chance that you'll also have an idea what to use instead. If, on the other hand, you can't even explain why the command line parameters are bad, then there's probably nothing wrong with using them...

Christian Stieber
  • 9,954
  • 24
  • 23
  • Thanks for your answer. I am trying to make my code as "perfect" as I can, and I thought I "must" use some kind of config file. @paulsm4 agrees with you, that is good :) – marcocamejo Jul 04 '12 at 22:37
2

Q: So far, the IP address and the port number are passed to the daemon, directly ... It is a bad practice, I know.

A: Why do you think it's "bad practice"????

"Good practices" include:

  • "DRY" (Don't Repeat Yourself - store data in one and only one place)

  • "KISS" (Keep it Simple, Stupid)

I'd say one parameter (command line IP address) in one script (your init.d startup script) adheres to both principles pretty well :)

IMHO...

PS:

If you really think a configuration file is appropriate - if there's lots of complex configuration data that needs to be parsed at startup), then two appropriate places would be:

  • Store the config file in /etc (and your app in /usr/local/bin)

    ... or ..

  • Store the config file in your app's install directory (and possibly define a global environment variable to point to the install directory)

paulsm4
  • 114,292
  • 17
  • 138
  • 190
2

This is distro specific. On debian, for example, the convention is that /etc/init.d/foo includes a line like "source /etc/default/foo". That file contains only environment variables e.g. DAEMON_ARGS="--remote-ip=192.168.0.1".

If you build a debian package using debhelper it will create this structure for you automatically. I'm sure there are similar tools for creating "standard" RPMs too.

Alex Zeffertt
  • 1,462
  • 11
  • 12
1

Use environment variables:

// include stdlib for getenv

port = getenv("MY_DAEMON_PORT");
host = getenv("MY_DAEMON_HOST");

// convert port to integer...

As I recall this is somewhat conventional with processes launched from init.d.

Since you've mentioned that you're using Ubuntu, have a look at /etc/environment - see the docs. But as someone has already mentioned this is dependent on your system/distro; another way is to keep the environment variables in e.g. /etc/myDaemon.env, then source that from your init script with:

. /etc/myDaemon.env

But your case is so simple that I also don't see a problem with keeping the arguments in the script.

pb2q
  • 58,613
  • 19
  • 146
  • 147
  • this looks great. How and where would I set the MY_DAEMON_PORT and MY_DAEMON_HOST? – marcocamejo Jul 04 '12 at 22:32
  • As you said, and other suggested too, due to the simplicity of my problem I think I will prefer to keep the arguments in the script, but I will keep in mind the ue of environment variables for a bigger problem. Thanks – marcocamejo Jul 05 '12 at 00:28