Is it a bad idea to put variables needed by a daemon program running at boot on a headless system in /etc/profile.d/? From my understanding profile.d doesn't get executed until someone logs into the system via an interactive shell. So would my daemon process that will eventually need the system variables held in profile.d not have these variables set, until someone logs into the system, or will these be set after rc.local runs on an unattended system? (System is RHEL 6.5 running bash)
profile.d on headless server
bash;rhel;environment variables;init script
It's a bad idea if it doesn't work.  I think your concern about profile.d not running unless someone logs in is legitimate.Put an init script in /etc/rc.d/init.d (I think this is the correct directory for Red Hat; in Ubuntu it's /etc/init.d) to start your daemon.  In this script you can declare/define any variables you need and when you start the daemon binary those variables should be in scope.The link here explains that process and precisely why it is superior to the rc.local method.The rc.local method, mentioned in another answer, won't work because the variables set up in that script are no longer defined when execution returns to Linux INIT.  This is, consequently, before anyone logs in, so it is implicitly before profile.d is run.