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)
Add a comment |
2 Answers
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.
- i will try this tomorrow, since my brain is fried from wrapping my head around the linux boot sequence and all. however this is enough info for the answer i was looking for so thank you.jgr208– jgr2082014-08-26 21:27:58 +00:00Commented Aug 26, 2014 at 21:27
To directly answer your question, it's only a bad idea if it doesn't work. So my direct answer is "no", if it doesn't work, "yes" if it works. Did you try it? That is, have you confirmed that profile.d doesn't run on your system if no one logs in?
As a suggestion of how to make it work: Edit the rc.local file in the same way, to ensure the settings are applied at boot.
Regardless of what is supposed to happen on a fresh, vanilla install, you should experiment to see if settings you put in either of those files (profile.d or rc.local) are applied when you expect. If it just works putting it in /etc/profile.d, then it just works, on your setup, lucky you.
This link from an online-book at linuxtopia suggests that rc.local is located at /etc/rc.d/rc.local in RHEL 6.
- they are applied when i expect. except i am having trouble closing the gap of what happens after rc.local is executed to when profile.d is executed for how the environment variables are set for the system to use until a user logs in. yes it is in there and has a symbolic link in /etc/rc.localjgr208– jgr2082014-08-26 19:20:01 +00:00Commented Aug 26, 2014 at 19:20
- I was suggesting to just make the changes in
rc.localin the first place. It sounds like you want to boot the machine, but no one logs in, it just runs. Your concern that the profile setup won't be run is legitimate. You knowrc.localwill be run, so just do it there.Wilbur Whateley– Wilbur Whateley2014-08-26 19:30:13 +00:00Commented Aug 26, 2014 at 19:30 - thanks, i did do that for a bootup with a variable needed. So my concern is, if i source the file in profile.d in rc.local, when will those variables be thrown away? if they will be after rc.local is done that is a concern.jgr208– jgr2082014-08-26 19:35:25 +00:00Commented Aug 26, 2014 at 19:35
- Yes, it seems that once
rc.localwork is done, execution returns to Linux INIT and any variables you set there are gone.Wilbur Whateley– Wilbur Whateley2014-08-26 21:00:38 +00:00Commented Aug 26, 2014 at 21:00 - How is your daemon being started? You should probably hook it into the init routines (start|stop|etc), then you can specify the variables for your daemon in a custom init script. see here. The author here shows how to make a custom init script for a daemon and sets env vars in the script. This is, I think, what happens "in the gap" between
rc.localandprofileWilbur Whateley– Wilbur Whateley2014-08-26 21:03:27 +00:00Commented Aug 26, 2014 at 21:03