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@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@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
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
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
- 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
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
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.
On Mon, 17 Sep 2007 15:19:41 +0100 David Woodhouse dwmw2@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 (jkeating@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
On Mon, 2007-09-17 at 13:49 -0400, Bill Nottingham wrote:
Jesse Keating (jkeating@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
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@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.
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@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
seth vidal (skvidal@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
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
Richi Plana (myfedora@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
On Mon, 2007-09-17 at 15:14 -0400, Bill Nottingham wrote:
Richi Plana (myfedora@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
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
On Mon, 17 Sep 2007 13:49:27 -0400 Bill Nottingham notting@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?
On 9/17/07, Bill Nottingham notting@redhat.com wrote:
Jesse Keating (jkeating@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
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
On Mon, 17 Sep 2007 12:12:05 -0600 Richi Plana myfedora@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.
On Mon, 2007-09-17 at 14:29 -0400, Jesse Keating wrote:
On Mon, 17 Sep 2007 12:12:05 -0600 Richi Plana myfedora@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
On Mon, 2007-09-17 at 14:29 -0400, Jesse Keating wrote:
On Mon, 17 Sep 2007 12:12:05 -0600 Richi Plana myfedora@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
Richi Plana (myfedora@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
On Mon, 2007-09-17 at 15:17 -0400, Bill Nottingham wrote:
Richi Plana (myfedora@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.
Dnia 2007-09-17, o godz. 15:31:17 Simo Sorce ssorce@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
Leszek Matok (Lam@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
On Tue, 2007-09-18 at 17:30 +0200, Leszek Matok wrote:
Dnia 2007-09-17, o godz. 15:31:17 Simo Sorce ssorce@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.
On Tue, 2007-09-18 at 17:30 +0200, Leszek Matok wrote:
Dnia 2007-09-17, o godz. 15:31:17 Simo Sorce ssorce@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
Once upon a time, Leszek Matok Lam@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.
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
Richi Plana (myfedora@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
On Mon, 2007-09-17 at 15:17 -0400, Bill Nottingham wrote:
Richi Plana (myfedora@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
Gilboa Davara (gilboad@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
On 9/17/07, Adam Jackson ajackson@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
On Mon, 2007-09-17 at 14:23 -0400, Yaakov Nemoy wrote:
On 9/17/07, Adam Jackson ajackson@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
On 9/17/07, Adam Jackson ajackson@redhat.com wrote:
On Mon, 2007-09-17 at 14:23 -0400, Yaakov Nemoy wrote:
On 9/17/07, Adam Jackson ajackson@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
On 9/17/07, Adam Jackson ajackson@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
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....
On 9/18/07, Alan Cox alan@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
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
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