| 1 |
On Tue, 05 Jul 2005 21:05, Digby Tarvin wrote: |
| 2 |
> On Mon, Jul 04, 2005 at 04:57:28PM +1200, Glenn Enright wrote: |
| 3 |
> Thus after verifying that everything is ok after initial boot to |
| 4 |
> runlevel 3, I can run telinit 5 to start the X server. |
| 5 |
> |
| 6 |
> The system I ssh'd from was a BSD/OS system at runlevel 5. |
| 7 |
OK looks like you know all about sysinit and its toys :) |
| 8 |
|
| 9 |
<snip> |
| 10 |
> Agian, console wasn't working so I had done this from a root shell |
| 11 |
> in the SSH sesion. ('/sbin/shutdown -r now' is just a wrapper for |
| 12 |
> halt, so if halt doesn't work, no shutdown incantations are going |
| 13 |
> to do much...) |
| 14 |
Actually the situation seems to be a bit different from that. |
| 15 |
|
| 16 |
from 'man halt' |
| 17 |
** if halt or reboot is called when the system is not in runlevel 0 or 6, in |
| 18 |
other words when it's running normally, shutdown will be invoked instead |
| 19 |
(with the -h or -r flag). For more info see the shutdown(8) manpage. |
| 20 |
|
| 21 |
from 'man shutdown' |
| 22 |
** shutdown brings the system down in a secure way. All logged-in users are |
| 23 |
notified that the system is going down, and login(1) is blocked. It is |
| 24 |
possible to shut the system down immediately or after a specified delay. All |
| 25 |
processes are first notified that the system is going down by the signal |
| 26 |
SIGTERM. This gives programs like vi(1) the time to save the file being |
| 27 |
edited, mail and news processing programs a chance to exit cleanly, etc. |
| 28 |
shutdown does its job by signalling the init process, asking it to change the |
| 29 |
runlevel. |
| 30 |
|
| 31 |
so calling shutdown to start with should be more reliable, given that the |
| 32 |
system is still 'running'. Hence the reason its used in the init scripts. |
| 33 |
|
| 34 |
> > did you try |
| 35 |
> > "/etc/init.d/xdm stop" |
| 36 |
> > This should stop the X session if you started it using the standard |
| 37 |
> > bootup proccess. |
| 38 |
> |
| 39 |
> That is what init does when switching to runlevel 3. |
| 40 |
|
| 41 |
Only if youve been messing with your init scripts |
| 42 |
|
| 43 |
One big difference with the sysinit levels and gentoo init-levels is |
| 44 |
conceptual. Sysinit allows to to cumulatively start programs as you increase |
| 45 |
the level. In gentoo changing levels seems to cause all stuff in the original |
| 46 |
to stop and then all in the new level to start, with only the 'boot' level |
| 47 |
stuff running always. |
| 48 |
|
| 49 |
So if you have a net service and samba running in 'default' and change to your |
| 50 |
'graphics' level (or whatever you called it) then unless those services are |
| 51 |
assigned to that level also they will be stopped until you change back or |
| 52 |
start them manually. This may be the cause of your instability? |
| 53 |
|
| 54 |
|
| 55 |
> I am pretty sure that this is a result of a bug in the X server (another |
| 56 |
> reason not to start it in the default runlevel) which means that the |
| 57 |
> kernel can't shut it down - a problem that any process stuck in a driver |
| 58 |
> call, but there should be some way to halt the rest of the system so at |
| 59 |
> least the filesytems are unmounted cleanly etc. |
| 60 |
> |
| 61 |
|
| 62 |
Thats what the shutdown command is supposed to do. |
| 63 |
|
| 64 |
Anyway this is getting away from the real problem you seem to have with your X |
| 65 |
server. I agree that there does seem to be a problem there of some sort. |
| 66 |
|
| 67 |
from 'man 7 signal' which is referenced by 'man kill' you could try |
| 68 |
kill SIGSTOP process_number |
| 69 |
|
| 70 |
and make sure you check your logs when you do get a crash. should be a |
| 71 |
~/.xsession_errors and a /var/log/Xorg.0.log(.old) or similar at the very |
| 72 |
least. |
| 73 |
-- |
| 74 |
|
| 75 |
Time-sharing is the junk-mail part of the computer business. |
| 76 |
-- H.R.J. Grosch (attributed) |
Archives