When I do /stop, my server console will not close. It saves and all that, then I have to cmd-opt-esc (open force quit menu) and force quit the console. When I restart it, everything is saved, but the only problem is that force-quitting just does not feel right. I'll edit this if it comes out not saving. I am running a mac OSX Mountain Loin. Thanks.
P.s. It closes normally if there is no one on the server.
CONSOLE OUTPUT:
[11:22:39 INFO]: Stopping server
[11:22:39 INFO]: Saving players
[11:22:39 INFO]: Saving worlds
[11:22:39 INFO]: Saving chunks for level 'New Creative Server Photos'/Overworld
[11:22:40 INFO]: Saving chunks for level 'New Creative Server Photos'/Nether
[11:22:40 INFO]: Saving chunks for level 'New Creative Server Photos'/The End
[11:22:40 INFO]: Stopping server
at the 'Stopping server' part it does nothing else and won't close unless I force quit the console.
Linked issues
Comments

I can confirm this is an issue. The console output is the same except it doesn't exit.
SIGTERM is ignored so I have to SIGKILL.
Tested on:
CentOS 6.5
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-0)
OpenJDK 64-Bit Server VM (build 25.0-b57-internal, mixed mode)
I just did a few tests and it only happens if people are still connected when you do /stop. Entering the command into an empty server (i.e. 0 players online) will successfully exit.
Also confirmed on:
Kubuntu 14.04
java version "1.8.0_11"
Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)
Also happens for me on latest (32b, 32c crashes everyone for me) when there are online players.
This makes zero-maintenance batch-restarters useless, because when I remotely /stop I'm still online and it locks up, requiring me to get to the physical machine.
If command blocks could /stop, this would have a workaround.
A usable workaround, though, would be to have a sniffer program look up a magic word on server log files and kill java when it finds that.
Was this fixed? I am currently using a sniffer to manually kill the server due to being unable to stop from inside.

Not fixed, see MC-69402
Hmm, If this is not fixed for release I might have to rely on a separate tool to shutdown the server from inside. I have been using a Game Maker executable to kill java when it finds a passphrase on the server logs to accomplish this. Might write a dedicated tool on a more appropriate platform.
If command blocks could run all commands this would not be a problem too.
this is a problem for us as well, running 1.8 pre-release 3, the shutdown will hang if players are still connected at 'saving players....'... please fix, pretty please 🙂
Yeah, this is a major problem for remotely managed or zero-config servers. Specially since sometimes the server will overload and then the target machine is saturated, preventing remote connections to stop the server.
Yeah, adding the console output after doing /stop now. Its still going in the pre-releases!
Well this is bad. Bumping for visibility.
I will now try to find a sequence of ingame actions that crashes the server, and try to automate that.
I'm experiencing this issue on my server, or what seems to be a similar issue.
My server has scheduled restarts and as it goes into the restart it 'hangs'.
23:00:08 CONSOLE: [INFO] Saving worlds
23:00:08 CONSOLE: [INFO] Saving chunks for level 'Huggercraft'/Overworld
23:00:08 CONSOLE: [INFO] Saving chunks for level 'Huggercraft'/Nether
23:00:08 CONSOLE: [INFO] Saving chunks for level 'Huggercraft'/The End
23:00:10 CONSOLE: Shutdown Thread/INFO]: Stopping server
23:00:10 CONSOLE: Shutdown Thread/INFO]: Saving players
At this point it's shut-down and has not initiated the restart sequence, I have to manually log in and restart myself.
i had to change my scheduled restart to 'when no one is on' until this is resolved and sneak in a few manual reboots when i can.
im still getting this on 1.8 release just hangs there scheduled restarts are usless atm
For anyone using linux and bash scripts to restart servers
this command below will help stop the server so it can run freely again after stop
feel free to remove ; screen -wipe if you dont use screens
ps -ef | grep java | grep -v grep | awk '{print $2}' | xargs kill -9 ; screen -wipe
at least then you can have servers restart and not worry about having to be online to do it your self, cause if you use rcon like i do the next java instace will still be running rcon, which means it may be more then just the fact it dosent stop it could be hanging due to something else
I can confirm this issue too, for me it actually caused all my player files to not save, so for some reason all player files where gone. It wasn't a huge deal since i have frequent backups, but seriously, this isn't a snapshot, this is a final release... this needs to be fixed ASAP.
here is some log i use a 64 gig dedicated server i get lag alot but i benn getting alot of errors latly here is a error that i noticed during one of the stops
[02:00:31] [Server thread/INFO]: Stopping the server
[02:00:32] [Server thread/INFO]: Stopping server
[02:00:32] [Server thread/INFO]: Saving players
[02:00:32] [Server thread/INFO]: Saving worlds
[02:00:32] [Server thread/INFO]: Saving chunks for level 'world'/Overworld
[02:00:33] [Server thread/INFO]: Saving chunks for level 'world'/Nether
[02:00:33] [Server thread/INFO]: Saving chunks for level 'world'/The End
Sep 08, 2014 2:00:34 AM io.netty.util.concurrent.DefaultPromise notifyListener0
WARNING: An exception was thrown by rk.operationComplete()
io.netty.util.concurrent.BlockingOperationException: DefaultChannelPromise@4bf99325(uncancellable)
at io.netty.util.concurrent.DefaultPromise.checkDeadLock(DefaultPromise.java:397)
at io.netty.channel.DefaultChannelPromise.checkDeadLock(DefaultChannelPromise.java:157)
at io.netty.util.concurrent.DefaultPromise.awaitUninterruptibly(DefaultPromise.java:290)
at io.netty.channel.DefaultChannelPromise.awaitUninterruptibly(DefaultChannelPromise.java:135)
at io.netty.channel.DefaultChannelPromise.awaitUninterruptibly(DefaultChannelPromise.java:28)
at gr.a(SourceFile:199)
at rk.operationComplete(SourceFile:125)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:682)
at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:607)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:565)
at io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:413)
at io.netty.channel.DefaultChannelPromise.trySuccess(DefaultChannelPromise.java:82)
at io.netty.channel.ChannelOutboundBuffer.safeSuccess(ChannelOutboundBuffer.java:608)
at io.netty.channel.ChannelOutboundBuffer.remove(ChannelOutboundBuffer.java:344)
at io.netty.channel.socket.nio.NioSocketChannel.doWrite(NioSocketChannel.java:283)
at io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:694)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.forceFlush(AbstractNioChannel.java:321)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:515)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
at java.lang.Thread.run(Thread.java:744)
still a big issue really hope someone fixes this

Based on the comment above, it could be related to MC-37586 which is when the server thinks a player hasn't left when they actually have, causing ghost players.
@Jono it's not related to that bug. If I start a server and join it, then do nothing else except try and stop the server, this bug is duplicated. And like Adrian above said, it has deleted all the player and stat files at one point when the console was forcefully quit which is a major problem, esp. for people not smart enough to make backups.
chris is correct there two differant bugs and we should not have to make doggy scripts to kill processes to get servers to full stop

Fair enough, but let's not forget the possibility that they might be related. Code does some weird things sometimes.
Bug is still present 🙂
Is this fixed in 1.8.1-pre3?
According to MC-72806 it's fixed.
Also I can not reproduce it in 1.8.1-pre3 any more while I can in earlier versions.
It's fixed 🙂
Thanks a lot for fixing this bug!
It really helps
Can someone change 'fix versions' to 1.8.1 pre-3?

Resolved as duplicate of MC-72806
Cannot confirm, getting that in the console:
Please attach your console output after issuing "stop"