• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Order of login config scripts

 
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 323
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
reply
    Bookmark Topic Watch Topic
  • New Topic