[CALUG] How do I get out of X?

[Chris Edillon]

On Sun, 2006-08-27 at 21:33 -0400, Rajiv Gunja wrote:

> If my history of the OS and OS-origin is right, OS was meant to be handled
> by more than 1 person. It was designed in those days to be handled by a
> group of people from the same department or from different departments. OS
> these days have converged all its "management" tasks or "administrative"
> tasks to 1 person or 1 group.
> 
  if we're talking unix and unix derivatives, it has pretty much
always had the concept of a super-user which can do anything on
the system (earliest reference i've seen is 1971).  any attempts
to split administrative rights within a unix-like OS have been
later additions and have never really been successful.

> telinit as the word implies "tell init" was program which could be run by a
> "user" (mind you I did not mention root) who has the right privileges to reboot
> or bring the system down for maintenance or refresh the running processes.
> 
> Someone did not combine these 2, but rather SVR started moving away from it
> as it was useless. None the less, they still had that function built into
> init to understand telinit command and to do the necessary tasks. While this
> was done, other programs were developed to do similar jobs. (reboot,
> shutdown and in Linux "control-alt-del")
> 
  i'll have to respectfully disagree here.  init has been around
much longer than telinit, and in its earlier forms it took no
arguments; it simply was the first process to start and initialize
the rest of the system.  i'd be willing to be that once runlevels
were introduced (SVR4 i believe), telinit was introduced as a way
of signaling init (as opposed to just sending it a HUP to switch
between single/multi in the old system).  the merge of functionality
between init and telinit probably happened later.  

> Actually it is the other way around. "telinit" TELLS INIT to go to run-level
> 1. This was done for users who were not "true" UNIX Admins or who did not
> have "root".
> 
  only root can use telinit, even today.  else anyone could telinit
to single user mode and have access to the whole system.

> Done hold your breath and try the "telinit" command on HP-UX or Tru64, it
> wont work.

Tru64 (and its predecessor Digital UNIX) was based on OSF/1 and
therefore it's own hybrid beast.  i wonder if this is where the
idea of merging telinit and init came about?  i'm not very familiar
with HP-UX so i can't comment about it.

>  As of HP-UX 11 and above there is not support for telinit
> command. I am not sure about the history of AIX, but telinit did not exist
> on 4.x version, but it is in 5.x, I think the reason being they want their
> OS to be as close to Linux as possible.
> 
  you must be kidding.  :)  AIX is about as far from linux and
unix as you can get and still be unix-like, at least in terms of
administration.  smit was useful, though.

> If someone is still running Ultrix, we might be able to test it out. Last
> time I saw Ultrix was in 1999 at an University I worked at in India. Not
> sure, if my contacts are still working there or if they are still running
> that system.

  it's been years since i've touched an ultrix box as well, but
as i recall it was based on BSD with some SYSV add-ons, at least
initially.  i recall it using the BSD-style system startup (/etc/rc
and /etc/rc.local) vice the SYSV-style init runlevels, although i
could be mistaken.

> That said, using init to run telinit normally works on Linux, and the
> > manpage (on SLES9 and RHEL4 at least) even documents this
> > implementation shortcut.  There's probably enough stuff on Linux that
> > relies on it that it's unlikely to break.
> 
> 
> Again, I would have to say it is the other way around. init is the mother or
> parent of all programs. It was thought to be unwise to direct commands to it
> directly. So the programmers of Unix wrote a program called "telinit" to
> "tell" init what to do.
> 
  getting back to linux, the linux version of init uses a FIFO
called /dev/initctl to accept state changes, and both init and
telinit simply send data to the FIFO in order to change run
levels.  in this sense, init has two modes: the first time it
is called, by the kernel at boot time, it runs as a process with
PID 1.  if it is subsequently called and its PID 1 self is running,
it acts as telinit and communicates to its PID 1 self via the FIFO.
if you were so inclined you could probably write your own program
which passes a data structure to /dev/initctl and tells init to
change runlevels.  and if you change the permissions on the FIFO
you might even be able to run this program as a user other than
root.  but if you try this, you might upset james, not to mention
possibly compromise system security  :)

chris