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)


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 Aug 26 '14 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.local – jgr208 Aug 26 '14 at 19:20
  • I was suggesting to just make the changes in rc.local in 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 know rc.local will be run, so just do it there. – Wilbur Whateley Aug 26 '14 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 Aug 26 '14 at 19:35
  • Yes, it seems that once rc.local work is done, execution returns to Linux INIT and any variables you set there are gone. – Wilbur Whateley Aug 26 '14 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.local and profile – Wilbur Whateley Aug 26 '14 at 21:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.