aspose file tools*
The moose likes Linux / UNIX and the fly likes Order of login config scripts Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » Linux / UNIX
Bookmark "Order of login config scripts" Watch "Order of login config scripts" New topic
Author

Order of login config scripts

Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
What happens when I log in? I mean what scripts are called and in what order? I'm sure this depends on the distro and probably even more on individual configurations. I'm familiar with .profile, .bashrc, and .bash_profile for configuring user settings. I've also edited /etc/bashrc and /etc/profile to change some global settings. However, some of the recent changes had some side effects that I've been trying to fix.

From experimentation and reading, I already know a few things.

1) There are different config scripts for different shells.
2) There are global and user config scripts.
3) Different things happen depending on how you log into the system and what type of terminal you open. Most of this seems to be controlled by if statements in the global scripts.

So how do I find out what scripts run and what order they run in? Is there some kind of trace command I can turn on before I log in? I would love to just see some output that gives me some clues as to what is going on. This would make it a lot easier to make customizations.

Thanks for your time to read my question and post a reply.

Layne


Java API Documentation
The Java Tutorial
M Beck
Ranch Hand

Joined: Jan 14, 2005
Posts: 323
in the traditional, (virtual)terminal sequence of events, getty runs login.

in the real world, today, getty and login are usually replaced by some other program(s) that do the equivalent job — the display manager, or sshd, or somesuch. but since the overall job to be done is still pretty much the same, these two can be fairly representative.

getty you don't need to read about; it's an unusually boring kind of process, and only ever run on the text-mode console or direct-connected serial lines. neither of those are in common use any longer.

login you can read about in its man page, but that man page seems to be horrendously outdated by now — mine is dated 1996, and even then, much of its functionality seems to be documented in a BUGS section that mostly tells you what parts of the rest of the man page no longer apply. it's worth reading regardless, because it's short, and it will tell you what sort of job the processes that replace login have to do. it will also tell you more or less how the stage is set for executing your login shell.

i say "more or less", because those man pages don't mention PAM. most of the work they talk about — which is still all getting done, of course — and quite a bit more, is now no longer done in login and its replacements directly, but is done instead by the Pluggable Authentication Modules system. this matters because they can (for example) set up a different environment very dynamically, and otherwise mess with the parameters that your shell will have to run in. most of the time, of course, they don't, because you won't have configured them to; but they can.

the login shell you can read about in its man page, but here you have a problem. namely, your login shell is likely bash, and that's got a man page a great blue whale could choke on. still, the very start of it (up to and including the INVOCATION section) will give you some notion of what's going on.

global config files are read before local (/etc before $HOME). the shell itself cares about /etc/profile and one of the files in your $HOME, either ".bashrc", ".bash_profile", or ".profile", depending on circumstances. any other files are called from one of those, as appropriate.

i suppose you could start an strace'd getty process on an unused VT, log in on it, and see how far the strace log goes. it might not be worth the trouble, though. personally, i'd insert echo statements in the various profile files and see what order they print out in; if that doesn't help i guess you could use "cat" or "echo" statements to append debug data to a world-writable file in /tmp to get a feel for what's going on. but read the man pages first, they'll tell you where to start.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

Also the login scripts don't always execute the same on different Linux distros.

The bash manual tells about its builtin script invocation (hint, use the "/" command to search for "profile"), but that's just the jumpoff point. Systems like redhat have scripts calling other scripts to 3-4 levels, so you really need to find the scripts your login shell invokes, then look at each of them to see what they're doing, recurse as needed.

Overall, the scripts relate to system-wide vs user-specific and GUI vs non-GUI, interactive vs non-interactive with a few other variants. A rigorously defined script set will reduce the redundant script code while giving each user the maximum goodies pertinent to the run environment in use.


Customer surveys are for companies who didn't pay proper attention to begin with.
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
M Beck:

Thanks a lot for your comments. It's a lot more detail than I expected, but that's exactly what I needed. I'll start delving into the man pages even though they typcially intimidate me.

Tim Holloway:

I think the scripts calling other scripts is what has me all confused about the order things happen. I'm very much aware that different distros do things differently. I've noticed that when I log into my Debian machine different things happen than when I log into my Red Hat machine. This surprised me a little at first because both machines share the same /home directory. However, they each have their own /etc directory where most of the differences occur, it seems. (Hmm...perhaps I should share the /etc directory through NFS to remove some of the redundancy...)

Layne
M Beck
Ranch Hand

Joined: Jan 14, 2005
Posts: 323
sharing /etc over NFS is one of those things that sounds like a good idea, but turn out a lot harder in practice. there are two problems: on most machines, /etc holds too much information that needs to vary with the machine (such as what services should be started, how various hardware should be initialized and run (even the X11 graphics modes are typically under /etc/X11 !), and so forth), and also, /etc often needs to be available and readable before the networking system is initialized. in fact, it usually needs to be available in order to get the networking subsystems up and running; i doubt you could even split it off of the root filesystem, because /etc/fstab is needed to mount the non-root filesystems… so, you'd have to export all of / to the other machine, not just /etc alone.

now, both of these problems can be overcome, with enough effort; people do things like diskless clients and terminal servers, booting entire roomfuls of small client PCs from a single disk image stored on a server, so it has to be possible somehow. it likely does take extensive hacking, however. even just mounting the root filesystem read-only for security can be hard, because some services and utilities keep wanting to write to files in /etc at times. (/etc/mtab , for example. i thought the kernel hackers had moved that functionality to /proc years ago, but apparently userland hasn't kept up&hellip solving concurrency problems with multiple machines all writing to "their" /etc at the same time can't be fun.
[ June 04, 2005: Message edited by: M Beck ]
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by M Beck:
sharing /etc over NFS is one of those things that sounds like a good idea, but turn out a lot harder in practice. there are two problems: on most machines, /etc holds too much information that needs to vary with the machine (such as what services should be started, how various hardware should be initialized and run (even the X11 graphics modes are typically under /etc/X11 !), and so forth), and also, /etc often needs to be available and readable before the networking system is initialized. in fact, it usually needs to be available in order to get the networking subsystems up and running; i doubt you could even split it off of the root filesystem, because /etc/fstab is needed to mount the non-root filesystems… so, you'd have to export all of / to the other machine, not just /etc alone.

now, both of these problems can be overcome, with enough effort; people do things like diskless clients and terminal servers, booting entire roomfuls of small client PCs from a single disk image stored on a server, so it has to be possible somehow. it likely does take extensive hacking, however. even just mounting the root filesystem read-only for security can be hard, because some services and utilities keep wanting to write to files in /etc at times. (/etc/mtab , for example. i thought the kernel hackers had moved that functionality to /proc years ago, but apparently userland hasn't kept up&hellip solving concurrency problems with multiple machines all writing to "their" /etc at the same time can't be fun.

[ June 04, 2005: Message edited by: M Beck ]


Thanks for the warning. I definitely don't have time to work on all of those issues right now, so it will be a while before I even consider this.

As an alternative, what do you think about making symbolic links to specific files that are shared over NFS? Since I am primarily dealing with /etc/profile and /etc/bashrc, it seems like I can make these two files available with an NFS share and then create symbolic links to them when necessary. Are there any caveats I am missing here? It sounds simple enough atm, but I'm sure there will be some complications when I get around to trying it...

Layne
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Order of login config scripts
 
Similar Threads
new to java and linux
Basic Problem with Enterprise Linux 3 Red Hat
Where is Java Set up?
add entry to PATH using Mac OS X
what file is read when a terminal shell is started.