7:18 a.m.
I sent the below message to the Fedora-art-list and it was suggested I
ask here...
---------- Forwarded message ----------
From: Jonathan Roberts <jonathan.roberts.uk(a)googlemail.com>
Date: 15 Sep 2007 12:25
Subject: Graphical Shutdown
To: "Discussions about the artwork included with Fedora, including
icons, themes, and wallpapers." <fedora-art-list(a)redhat.com>
Not sure if this is the relevant list, but...is there any possibility
of F8 having a graphical shutdown? Perhaps even just a non-verbose
shutdown mode? It's just my humble opinion, but I find it looks ugly
and breaks the experience a bit...
Jon
11:55 a.m.
On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote:
Not sure if this is the relevant list, but...is there any
possibility
of F8 having a graphical shutdown? Perhaps even just a non-verbose
shutdown mode? It's just my humble opinion, but I find it looks ugly
and breaks the experience a bit...
If I were to guess at people's responses ...
The crowd who wanted an all-text startup complete with kernel messages
for debugging purposes would probably say "breaks what experience? It's
a shutdown. By definition, the experience should be over"
People who believe in symmetry or consistency would probably argue for a
similar setup to the graphical start-up procedure (since services
shutting down also give out similar status results).
My questions: 1) What would it take to use rhgb for shutdown? Is it just
a matter of executing /usr/bin/rhgb as in /etc/rc.d/rc.sysinit upon
shutting down? The messages in rhgb startup seem generic enough (no
mention of "Starting up..")
2) How exactly does /sbin/shutdown work, anyway? I'm familiar with how
the startup scripts get called by init on startup (via sysinit
-> /etc/rc.d/rc.sysinit), but I've never figured out how it gets started
on shutdown.
Slightly related topic ... well, alright, off-topic. 3) Is there going
to be a move by Fedora to something other/better than SysVInit?
--
Richi Plana
6:57 p.m.
Richi Plana wrote:
On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote:
> Not sure if this is the relevant list, but...is there any possibility
> of F8 having a graphical shutdown? Perhaps even just a non-verbose
> shutdown mode? It's just my humble opinion, but I find it looks ugly
> and breaks the experience a bit...
>
If I were to guess at people's responses ...
The crowd who wanted an all-text startup complete with kernel messages
for debugging purposes would probably say "breaks what experience? It's
a shutdown. By definition, the experience should be over"
People who believe in symmetry or consistency would probably argue for a
similar setup to the graphical start-up procedure (since services
shutting down also give out similar status results).
My questions: 1) What would it take to use rhgb for shutdown? Is it just
a matter of executing /usr/bin/rhgb as in /etc/rc.d/rc.sysinit upon
shutting down? The messages in rhgb startup seem generic enough (no
mention of "Starting up..")
I believe that some of the cleanup for the bootup sequence mentioned
getting rid of rhgb in favor of a new solution
2) How exactly does /sbin/shutdown work, anyway? I'm familiar
with how
the startup scripts get called by init on startup (via sysinit
-> /etc/rc.d/rc.sysinit), but I've never figured out how it gets started
on shutdown.
I believe it signals init to drop into runlevel zero (halted) via dbus.
Slightly related topic ... well, alright, off-topic. 3) Is there
going
to be a move by Fedora to something other/better than SysVInit?
--
This was discussed some time back. There was somewhat of a decision to
stick with SysV and focus on improving its functionality (though I would
prefer a new system)
Richi Plana
8:50 a.m.
On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote:
Not sure if this is the relevant list, but...is there any
possibility
of F8 having a graphical shutdown? Perhaps even just a non-verbose
shutdown mode? It's just my humble opinion, but I find it looks ugly
and breaks the experience a bit...
We (Red Hat) haven't looked into that yet. It's certainly a fine idea
though.
My mental model of this is that the X session just stays up until the
computer actually halts, since it's not like the X server maintains any
state that needs to get flushed to disk. You might terminate all the
other clients besides the session leader, and then throw up some
animation so the user knows things are happening.
But that's just a guess. It would take some design first to make sure
we think through the interactions. At this stage of F8 it might be too
late to fold this in before release, but that doesn't mean we shouldn't
work on it.
- ajax
9:19 a.m.
On Mon, 2007-09-17 at 09:50 -0400, Adam Jackson wrote:
My mental model of this is that the X session just stays up until
the
computer actually halts, since it's not like the X server maintains
any state that needs to get flushed to disk.
It's not like anything _else_ maintains state which needs to be flushed
to disk either. If they do, and they can't recover after an unclean
shutdown, then they're mostly broken anyway.
The only things we should really be doing on shutdown are closing
network sockets where appropriate, and the relatively few optimisations
which allow a more optimal startup (like properly unmounting the fs so
that the journal doesn't have to be replayed, etc.).
TBH I've mostly taken to using 'sync; reboot -f', or SysRq-S-U-B to
reboot machines these days; what we do on shutdown is mostly a pointless
waste of time.
--
dwmw2
9:34 a.m.
On Mon, 17 Sep 2007 15:19:41 +0100
David Woodhouse <dwmw2(a)infradead.org> wrote:
TBH I've mostly taken to using 'sync; reboot -f', or
SysRq-S-U-B to
reboot machines these days; what we do on shutdown is mostly a
pointless waste of time.
I was thinking about this over the weekend. We have "shutdown"
sections in services so that you can restart a service while running,
however we don't necessarily have to "shut down" the services when we
shut down the system.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
12:49 p.m.
Jesse Keating (jkeating(a)redhat.com) said:
I was thinking about this over the weekend. We have
"shutdown"
sections in services so that you can restart a service while running,
however we don't necessarily have to "shut down" the services when we
shut down the system.
Right, and not doing it cuts shutdown in half. However, since it's a
change in interface, you'd have to tag each service that you don't care
about shutting down separately. Which sucks.
Bill
1:04 p.m.
On Mon, 2007-09-17 at 13:49 -0400, Bill Nottingham wrote:
Jesse Keating (jkeating(a)redhat.com) said:
> I was thinking about this over the weekend. We have "shutdown"
> sections in services so that you can restart a service while running,
> however we don't necessarily have to "shut down" the services when we
> shut down the system.
Right, and not doing it cuts shutdown in half. However, since it's a
change in interface, you'd have to tag each service that you don't care
about shutting down separately. Which sucks.
would this be as a simple as modifying chkconfig so that if there isn't
a 3rd field in the:
# chkconfig: levels start_order stop_order
line in an initscript that it just didn't make the stop symlink?
-sv
1:15 p.m.
On Mon, 2007-09-17 at 14:04 -0400, seth vidal wrote:
On Mon, 2007-09-17 at 13:49 -0400, Bill Nottingham wrote:
> Jesse Keating (jkeating(a)redhat.com) said:
> > I was thinking about this over the weekend. We have "shutdown"
> > sections in services so that you can restart a service while running,
> > however we don't necessarily have to "shut down" the services
when we
> > shut down the system.
>
> Right, and not doing it cuts shutdown in half. However, since it's a
> change in interface, you'd have to tag each service that you don't care
> about shutting down separately. Which sucks.
>
would this be as a simple as modifying chkconfig so that if there isn't
a 3rd field in the:
# chkconfig: levels start_order stop_order
line in an initscript that it just didn't make the stop symlink?
Doesn't this potentially interfere with un-mounting file systems?
So we always kill -9 em?
Simo.
1:17 p.m.
On Mon, 2007-09-17 at 14:15 -0400, Simo Sorce wrote:
On Mon, 2007-09-17 at 14:04 -0400, seth vidal wrote:
> On Mon, 2007-09-17 at 13:49 -0400, Bill Nottingham wrote:
> > Jesse Keating (jkeating(a)redhat.com) said:
> > > I was thinking about this over the weekend. We have "shutdown"
> > > sections in services so that you can restart a service while running,
> > > however we don't necessarily have to "shut down" the
services when we
> > > shut down the system.
> >
> > Right, and not doing it cuts shutdown in half. However, since it's a
> > change in interface, you'd have to tag each service that you don't
care
> > about shutting down separately. Which sucks.
> >
>
> would this be as a simple as modifying chkconfig so that if there isn't
> a 3rd field in the:
> # chkconfig: levels start_order stop_order
>
> line in an initscript that it just didn't make the stop symlink?
Doesn't this potentially interfere with un-mounting file systems?
So we always kill -9 em?
I think we kill -term then we kill -9 them.
But that's a lot lighter than running an init script for each.
-sv
1:38 p.m.
seth vidal (skvidal(a)fedoraproject.org) said:
would this be as a simple as modifying chkconfig so that if there
isn't
a 3rd field in the:
# chkconfig: levels start_order stop_order
line in an initscript that it just didn't make the stop symlink?
Not quite that simple. S00killall will still stop started services on shutdown;
moreover, you probably still want kill scripts in runlevel 1.
Bill
1:58 p.m.
On Mon, 2007-09-17 at 14:38 -0400, Bill Nottingham wrote:
Not quite that simple. S00killall will still stop started services on
shutdown;
moreover, you probably still want kill scripts in runlevel 1.
How does the current flat setup handle possibly different
shutdown-startup sequences for going to different runlevels? Do scripts
go through the same shutdown sequence going from runlevel 5 to runlevel
6 as it does to runlevel 3 or 1? Sounds more like it should be handled
by finite-state machine logic.
--
Richi Plana
2:14 p.m.
Richi Plana (myfedora(a)richip.dhs.org) said:
On Mon, 2007-09-17 at 14:38 -0400, Bill Nottingham wrote:
> Not quite that simple. S00killall will still stop started services on shutdown;
> moreover, you probably still want kill scripts in runlevel 1.
How does the current flat setup handle possibly different
shutdown-startup sequences for going to different runlevels?
Not sure what you mean by this. It's pretty simple:
- run all KXX scripts, in order
- run all SXX scripts, in order
Do scripts
go through the same shutdown sequence going from runlevel 5 to runlevel
6 as it does to runlevel 3 or 1?
If they're set up to be killed in both, yes.
Bill
2:25 p.m.
On Mon, 2007-09-17 at 15:14 -0400, Bill Nottingham wrote:
Richi Plana (myfedora(a)richip.dhs.org) said:
> On Mon, 2007-09-17 at 14:38 -0400, Bill Nottingham wrote:
> > Not quite that simple. S00killall will still stop started services on
shutdown;
> > moreover, you probably still want kill scripts in runlevel 1.
>
> How does the current flat setup handle possibly different
> shutdown-startup sequences for going to different runlevels?
Not sure what you mean by this. It's pretty simple:
- run all KXX scripts, in order
- run all SXX scripts, in order
> Do scripts
> go through the same shutdown sequence going from runlevel 5 to runlevel
> 6 as it does to runlevel 3 or 1?
If they're set up to be killed in both, yes.
Yes, that's what I wanted to know with both questions: if the current
system is smart enough to know which services to shut down and what not
to when changing runlevels. Just by looking at the contents
of /etc/rc<RL>.d/, it just seems so flat (no hierarchy info) that it's
possible to think that the system might actually be shutting down all
services and restarting them in the new run-level.
Which script handles this? I'm curious to know. I've only been able to
trace the startup scripts but get lost when tracing init(8).
--
Richi Plana
2:42 p.m.
On Mon, Sep 17, 2007 at 01:25:18PM -0600, Richi Plana wrote:
Yes, that's what I wanted to know with both questions: if the
current
system is smart enough to know which services to shut down and what not
to when changing runlevels. Just by looking at the contents
of /etc/rc<RL>.d/, it just seems so flat (no hierarchy info) that it's
possible to think that the system might actually be shutting down all
services and restarting them in the new run-level.
I think you're looking for /etc/rc, which additionally checks for the
presence or absence of a /var/lock/subsys file which matches the
script's name, in order to decide whether or not to skip stopping or
starting the service.
HTH,
Nalin
1:04 p.m.
On Mon, 17 Sep 2007 13:49:27 -0400
Bill Nottingham <notting(a)redhat.com> wrote:
Right, and not doing it cuts shutdown in half. However, since
it's a
change in interface, you'd have to tag each service that you don't
care about shutting down separately. Which sucks.
Yeah, I figured there would have to be some way to indicate "no really,
I need to do some things at system shut down time". F9/10 feature
maybe?
--
Jesse Keating
Fedora -- All my bits are free, are yours?
1:05 p.m.
On 9/17/07, Bill Nottingham <notting(a)redhat.com> wrote:
Jesse Keating (jkeating(a)redhat.com) said:
> I was thinking about this over the weekend. We have "shutdown"
> sections in services so that you can restart a service while running,
> however we don't necessarily have to "shut down" the services when we
> shut down the system.
Right, and not doing it cuts shutdown in half. However, since it's a
change in interface, you'd have to tag each service that you don't care
about shutting down separately. Which sucks.
Right, but there's very few things that actually need a special
shutdown. And all of them are server services (thus not interesting
for discussion of graphical shutdown).
Ubuntu apparently went through their list:
https://wiki.ubuntu.com/Teardown
1:12 p.m.
On Mon, 2007-09-17 at 10:34 -0400, Jesse Keating wrote:
I was thinking about this over the weekend. We have
"shutdown"
sections in services so that you can restart a service while running,
however we don't necessarily have to "shut down" the services when we
shut down the system.
I'm a little confused. I occasionally shut down running services on a
running system without necessarily starting them up immediately or ever
after (like NFS when I'm done sharing things or tomcat5 when I'm just
debugging). I thought that there was also a "shutdown" option in
services to allow people to script proper and clean shutdown sequences
for services (like saving state for databases and ALSA sound system).
If we don't necessarily have to "shut down" the service when shutting
down, do you mean that services should just do the proper thing when
sent the appropriate signal(7)? Like a uniform way of being signalled to
shut down? (an analogy would be destructors in OOP)
--
Richi Plana
1:29 p.m.
On Mon, 17 Sep 2007 12:12:05 -0600
Richi Plana <myfedora(a)richip.dhs.org> wrote:
If we don't necessarily have to "shut down" the service
when shutting
down, do you mean that services should just do the proper thing when
sent the appropriate signal(7)? Like a uniform way of being signalled
to shut down? (an analogy would be destructors in OOP)
Many of the services just simply kill the pid. The final part of a
system shutdown would take care of that. The added time to run the
service script and source all the functions and display words to the
screen is just needless overhead.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
1:29 p.m.
On Mon, 2007-09-17 at 14:29 -0400, Jesse Keating wrote:
On Mon, 17 Sep 2007 12:12:05 -0600
Richi Plana <myfedora(a)richip.dhs.org> wrote:
> If we don't necessarily have to "shut down" the service when shutting
> down, do you mean that services should just do the proper thing when
> sent the appropriate signal(7)? Like a uniform way of being signalled
> to shut down? (an analogy would be destructors in OOP)
Many of the services just simply kill the pid. The final part of a
system shutdown would take care of that. The added time to run the
service script and source all the functions and display words to the
screen is just needless overhead.
As notting just pointed out to me - we do need to have the right thing
happen for going to run level 1, though.
-sv
2:04 p.m.
On Mon, 2007-09-17 at 14:29 -0400, Jesse Keating wrote:
On Mon, 17 Sep 2007 12:12:05 -0600
Richi Plana <myfedora(a)richip.dhs.org> wrote:
> If we don't necessarily have to "shut down" the service when shutting
> down, do you mean that services should just do the proper thing when
> sent the appropriate signal(7)? Like a uniform way of being signalled
> to shut down? (an analogy would be destructors in OOP)
Many of the services just simply kill the pid. The final part of a
system shutdown would take care of that. The added time to run the
service script and source all the functions and display words to the
screen is just needless overhead.
Oh, so it's not the process by which services are shutdown that's at
question but the implementation.
Are there use-cases where feedback on service shutdown would be desired?
It seems that if there were, a couple of lines of text would be
minimalist.
If sourcing shells and scripts has become a sticky point, then perhaps
that functionality should be included in init. Which sort of brings up
the topic of evaluating current init replacements (or, better yet, an
init, changerunlevel, shutdown system).
--
Richi Plana
2:17 p.m.
Richi Plana (myfedora(a)richip.dhs.org) said:
Are there use-cases where feedback on service shutdown would be
desired?
It seems that if there were, a couple of lines of text would be
minimalist.
If sourcing shells and scripts has become a sticky point, then perhaps
that functionality should be included in init. Which sort of brings up
the topic of evaluating current init replacements (or, better yet, an
init, changerunlevel, shutdown system).
I'd need to benchmark some more, but I suspect the delay is because of
a linear sequence of:
- kill -TERM $pid
- wait to see if it's dead
- kill -KILL $pid
for each service, as opposed to a global
- kill -TERM $everything
- wait a second
- kill -KILL $everything
Bill
2:31 p.m.
On Mon, 2007-09-17 at 15:17 -0400, Bill Nottingham wrote:
Richi Plana (myfedora(a)richip.dhs.org) said:
> Are there use-cases where feedback on service shutdown would be desired?
> It seems that if there were, a couple of lines of text would be
> minimalist.
>
> If sourcing shells and scripts has become a sticky point, then perhaps
> that functionality should be included in init. Which sort of brings up
> the topic of evaluating current init replacements (or, better yet, an
> init, changerunlevel, shutdown system).
I'd need to benchmark some more, but I suspect the delay is because of
a linear sequence of:
- kill -TERM $pid
- wait to see if it's dead
- kill -KILL $pid
for each service, as opposed to a global
- kill -TERM $everything
- wait a second
- kill -KILL $everything
Do it with your services, don't try on mine :-)
Maybe there is a way to say "me too", and " no, not me, I have to shut
down cleanly", and group these process in 2 groups, for the second you
wait the time it needs to.
Simo.
10:30 a.m.
Dnia 2007-09-17, o godz. 15:31:17 Simo Sorce <ssorce(a)redhat.com> napisał(a):
> - kill -TERM $everything
> - wait a second
> - kill -KILL $everything
Do it with your services, don't try on mine :-)
If your service is going to break whenever it gets killed, it's also going to
break whenever the power is lost, whenever the kernel panics and whenever I
accidentaly push the button. I don't believe Fedora ships such broken
software :)
Lam
10:38 a.m.
Leszek Matok (Lam(a)Lam.pl) said:
If your service is going to break whenever it gets killed, it's
also going to
break whenever the power is lost, whenever the kernel panics and whenever I
accidentaly push the button. I don't believe Fedora ships such broken
software :)
Sure, but it's more polite to, for example, shut down your mysql/postgres
database gracefully.
Bill
10:55 a.m.
On Tue, 2007-09-18 at 17:30 +0200, Leszek Matok wrote:
Dnia 2007-09-17, o godz. 15:31:17 Simo Sorce
<ssorce(a)redhat.com> napisał(a):
> > - kill -TERM $everything
> > - wait a second
> > - kill -KILL $everything
>
> Do it with your services, don't try on mine :-)
If your service is going to break whenever it gets killed, it's also going to
break whenever the power is lost, whenever the kernel panics and whenever I
accidentaly push the button. I don't believe Fedora ships such broken
software :)
There are many simple DBs that may break in such situations, and we have
them in Fedora. Usually there are tools to recover them but they are not
always 100% successful. And even if the state of the DB is consistent at
the end of the process you may lose data.
If you are trying to flush something to a file and you get killed you
can't expect to be sure what's in the file when you are done.
A good example is samba. By protocol, clients can and do use oplocks,
which means they don't write data back to the server immediately but
they are allowed to keep everything local and just flush down the data
when requested or when they decide it is time to.
When samba receive a shutdown request, it asks all client to please
flush the data, it may take some time, as the size can be considerable.
So if you kill samba while it is writing data received from clients, as
a consequence you may corrupt files.
A simple recycle may be easier to deal with as clients usually reconnect
and flush data on simple disconnections.
Same is for some tdb files we use or for BDB databases that use big
write caches.
Simo.
12:01 p.m.
On Tue, 2007-09-18 at 17:30 +0200, Leszek Matok wrote:
Dnia 2007-09-17, o godz. 15:31:17 Simo Sorce
<ssorce(a)redhat.com> napisał(a):
> > - kill -TERM $everything
> > - wait a second
> > - kill -KILL $everything
>
> Do it with your services, don't try on mine :-)
If your service is going to break whenever it gets killed, it's also going to
break whenever the power is lost, whenever the kernel panics and whenever I
accidentaly push the button. I don't believe Fedora ships such broken
software :)
There's a difference between powering down and losing power.
It's a fact of life that power loss can cause data loss. But that's
something that's usually accidental and unintentional. Not something
that might regularly be performed.
Shutting down by choice is like kill -TERM. Power loss is like kill
-KILL. With kill -TERM, you're giving the process the chance to do what
it needs to do to shut down cleanly. SIGKILL doesn't even give it the
chance to do anything and should only be used when the administrator is
reasonably certain that the process can no longer exit cleanly with any
of the other signal(7)s ... OR when the process absolutely has to die
like in shutdowns. Some shutdown policies state (though unspoken) that
shutting down the machine is a higher priority over assuring clean exits
(as seem to be the case with Desktops).
Of course, when the service is extremely important (servers where data
integrity has a high monetary figure attached), then they would most
likely opt for a different policy.
--
Richi Plana
1:16 p.m.
Once upon a time, Leszek Matok <Lam(a)Lam.pl> said:
If your service is going to break whenever it gets killed, it's
also going to
break whenever the power is lost, whenever the kernel panics and whenever I
accidentaly push the button. I don't believe Fedora ships such broken
software :)
I use Linux to avoid random OS crashes, I have redundant power to avoid
random power failures, and I don't let others near the boxes to avoid
random button pushes.
I expect my system to shut down cleanly. Databases, filesystems, etc.
are much happier when the rug isn't pulled out from under them.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
2:37 p.m.
On Mon, 2007-09-17 at 15:17 -0400, Bill Nottingham wrote:
I'd need to benchmark some more, but I suspect the delay is
because of
a linear sequence of:
- kill -TERM $pid
- wait to see if it's dead
- kill -KILL $pid
for each service, as opposed to a global
- kill -TERM $everything
- wait a second
- kill -KILL $everything
You're talking academically, right? Because the second scenario is never
going to happen, right?
The second scenario is a fixed-time scenario (1+ second) but is wrong in
a couple of levels. I think we can assume that some services need to be
shut down in a certain sequence if they're to be properly shut down at
all. But even if we disregarded that and let the services shut down as
best they can, killing all processes at the same time could result in
the system thrashing at bottlenecks like harddisk access.
What would the point be of comparing the two speeds, then if the "best
case scenario" isn't actually useful?
There are certain baseline needs that have to be satisfied before any
time comparison are to be made, IMO.
--
Richi Plana
4 p.m.
Richi Plana (myfedora(a)richip.dhs.org) said:
> - kill -TERM $pid
> - wait to see if it's dead
> - kill -KILL $pid
>
> for each service, as opposed to a global
>
> - kill -TERM $everything
> - wait a second
> - kill -KILL $everything
You're talking academically, right? Because the second scenario is never
going to happen, right?
Only somewhat. Did some testing a while back, set up everything that didn't
need controlled shut down to just be killed. It cut shutdown time in half
(13 seconds instead of 26, IIRC).
Bill
1:01 p.m.
On Mon, 2007-09-17 at 15:17 -0400, Bill Nottingham wrote:
Richi Plana (myfedora(a)richip.dhs.org) said:
> Are there use-cases where feedback on service shutdown would be desired?
> It seems that if there were, a couple of lines of text would be
> minimalist.
>
> If sourcing shells and scripts has become a sticky point, then perhaps
> that functionality should be included in init. Which sort of brings up
> the topic of evaluating current init replacements (or, better yet, an
> init, changerunlevel, shutdown system).
I'd need to benchmark some more, but I suspect the delay is because of
a linear sequence of:
- kill -TERM $pid
- wait to see if it's dead
- kill -KILL $pid
for each service, as opposed to a global
- kill -TERM $everything
- wait a second
- kill -KILL $everything
Bill
Baaah... Some services need -time- to shut down. (E.g. save data to the
disk)
Killing everything simultaneously may/will trigger an IO race; some
services just might not be able to save everything before they get
-KILL'ed.
- Gilboa
1:32 p.m.
Gilboa Davara (gilboad(a)gmail.com) said:
Baaah... Some services need -time- to shut down. (E.g. save data to
the
disk)
Killing everything simultaneously may/will trigger an IO race; some
services just might not be able to save everything before they get
-KILL'ed.
... which is why it's opt-in.
Bill
1:23 p.m.
On 9/17/07, Adam Jackson <ajackson(a)redhat.com> wrote:
On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote:
> Not sure if this is the relevant list, but...is there any possibility
> of F8 having a graphical shutdown? Perhaps even just a non-verbose
> shutdown mode? It's just my humble opinion, but I find it looks ugly
> and breaks the experience a bit...
We (Red Hat) haven't looked into that yet. It's certainly a fine idea
though.
My mental model of this is that the X session just stays up until the
computer actually halts, since it's not like the X server maintains any
state that needs to get flushed to disk. You might terminate all the
other clients besides the session leader, and then throw up some
animation so the user knows things are happening.
But that's just a guess. It would take some design first to make sure
we think through the interactions. At this stage of F8 it might be too
late to fold this in before release, but that doesn't mean we shouldn't
work on it.
- ajax
What about going down into and coming back from hibernate?
-Yaakov
1:20 p.m.
On Mon, 2007-09-17 at 14:23 -0400, Yaakov Nemoy wrote:
On 9/17/07, Adam Jackson <ajackson(a)redhat.com> wrote:
> On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote:
> > Not sure if this is the relevant list, but...is there any possibility
> > of F8 having a graphical shutdown? Perhaps even just a non-verbose
> > shutdown mode? It's just my humble opinion, but I find it looks ugly
> > and breaks the experience a bit...
>
> We (Red Hat) haven't looked into that yet. It's certainly a fine idea
> though.
>
> My mental model of this is that the X session just stays up until the
> computer actually halts, since it's not like the X server maintains any
> state that needs to get flushed to disk. You might terminate all the
> other clients besides the session leader, and then throw up some
> animation so the user knows things are happening.
>
> But that's just a guess. It would take some design first to make sure
> we think through the interactions. At this stage of F8 it might be too
> late to fold this in before release, but that doesn't mean we shouldn't
> work on it.
What about going down into and coming back from hibernate?
What about it? That's a different path. Hibernate doesn't terminate
processes at all.
If you mean "can we have a pretty hibernate too", then I suspect the
answer is "that's hard to make X do until we have kernel modesetting".
- ajax
1:39 p.m.
On 9/17/07, Adam Jackson <ajackson(a)redhat.com> wrote:
On Mon, 2007-09-17 at 14:23 -0400, Yaakov Nemoy wrote:
> On 9/17/07, Adam Jackson <ajackson(a)redhat.com> wrote:
> > On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote:
> What about going down into and coming back from hibernate?
What about it? That's a different path. Hibernate doesn't terminate
processes at all.
If you mean "can we have a pretty hibernate too", then I suspect the
answer is "that's hard to make X do until we have kernel modesetting".
*cough*buntu does it. Would it be in our interests to get what ever
patches they use pushed upstream?
-Yaakov
3:50 p.m.
On 9/17/07, Adam Jackson <ajackson(a)redhat.com> wrote:
On Sat, 2007-09-15 at 13:18 +0100, Jonathan Roberts wrote:
> Not sure if this is the relevant list, but...is there any possibility
> of F8 having a graphical shutdown? Perhaps even just a non-verbose
> shutdown mode? It's just my humble opinion, but I find it looks ugly
> and breaks the experience a bit...
We (Red Hat) haven't looked into that yet. It's certainly a fine idea
though.
My mental model of this is that the X session just stays up until the
computer actually halts, since it's not like the X server maintains any
state that needs to get flushed to disk. You might terminate all the
other clients besides the session leader, and then throw up some
animation so the user knows things are happening.
But that's just a guess. It would take some design first to make sure
we think through the interactions. At this stage of F8 it might be too
late to fold this in before release, but that doesn't mean we shouldn't
work on it.
Using my early-gdm scripts, X and gdm are already running their
sockets from a tmpfs. It would be trivial to reverse what I do on
bootup for shutdown and unmount everything from underneath X and gdm.
When the machine completely shutsdown *poof* tmpfs is gone and there
are no ugly sockets or temp files left to cleanup on boot.
I have been playing with this on the side to allow filesystems to do
their maintenance fsck's on shutdown instead of bootup. This gives
you more control over whether you have the time to wait on the
maintenance or not.
Jon
4:19 a.m.
On Mon, Sep 17, 2007 at 09:50:53AM -0400, Adam Jackson wrote:
My mental model of this is that the X session just stays up until
the
computer actually halts, since it's not like the X server maintains any
state that needs to get flushed to disk. You might terminate all the
other clients besides the session leader, and then throw up some
animation so the user knows things are happening.
You probably want to kill X off just before the final power down. A few
boxes get a bit confuddled if the BIOS video mode isn't reset (I've got one
here which objects if you do a hard reboot from inside an X window) - its
fine after a real reset or if you got text mode first
But that's just a guess. It would take some design first to make
sure
we think through the interactions. At this stage of F8 it might be too
late to fold this in before release, but that doesn't mean we shouldn't
work on it.
Hard bit seems to me being sure the old X server is dead dead dead before
the new one begins. Other problem is that X takes longer to start on some
boxes than poweroff to finish....
7:59 a.m.
On 9/18/07, Alan Cox <alan(a)redhat.com> wrote:
On Mon, Sep 17, 2007 at 09:50:53AM -0400, Adam Jackson wrote:
> My mental model of this is that the X session just stays up until the
> computer actually halts, since it's not like the X server maintains any
> state that needs to get flushed to disk. You might terminate all the
> other clients besides the session leader, and then throw up some
> animation so the user knows things are happening.
You probably want to kill X off just before the final power down. A few
boxes get a bit confuddled if the BIOS video mode isn't reset (I've got one
here which objects if you do a hard reboot from inside an X window) - its
fine after a real reset or if you got text mode first
> But that's just a guess. It would take some design first to make sure
> we think through the interactions. At this stage of F8 it might be too
> late to fold this in before release, but that doesn't mean we shouldn't
> work on it.
Hard bit seems to me being sure the old X server is dead dead dead before
the new one begins. Other problem is that X takes longer to start on some
boxes than poweroff to finish....
I think the best way to do this would be to execute the shutdown gui
in the PostLogin session of the first spawn X server. This allows us
to avoid spawning another Xserver just to shut down.
Jon
8:38 a.m.
On Tue, 2007-09-18 at 05:19 -0400, Alan Cox wrote:
On Mon, Sep 17, 2007 at 09:50:53AM -0400, Adam Jackson wrote:
> But that's just a guess. It would take some design first to make sure
> we think through the interactions. At this stage of F8 it might be too
> late to fold this in before release, but that doesn't mean we shouldn't
> work on it.
Hard bit seems to me being sure the old X server is dead dead dead before
the new one begins. Other problem is that X takes longer to start on some
boxes than poweroff to finish....
The waiting bit is done. I fixed X to issue both VT_ACTIVATE and
VT_WAITACTIVE on both startup and shutdown for exactly this reason.
When the X server process exits, it is off the hardware, guaranteed.
If you have startup profiles from reasonable machines where we're taking
more than, oh, four seconds to start, I'd love to see them.
- ajax
12:06 p.m.
On Tue, 2007-09-18 at 09:38 -0400, Adam Jackson wrote:
If you have startup profiles from reasonable machines where we're
taking
more than, oh, four seconds to start, I'd love to see them.
And if that really is unavoidable, then the question becomes "What's
more important: Graphical shutdown screens or fast shutdown processes?"
Another sticky option, but not as crucial as when starting up.
--
Richi Plana
6103
days inactive
6106
days old
39 comments
17 participants
participants (17)
-
Adam Jackson -
Alan Cox -
Bill Nottingham -
Casey Dahlin -
Chris Adams -
Colin Walters -
David Woodhouse -
Gilboa Davara -
Jesse Keating -
Jon Nettleton -
Jonathan Roberts -
Leszek Matok -
Nalin Dahyabhai -
Richi Plana -
Seth Vidal -
Simo Sorce -
Yaakov Nemoy