Today I updated my 13.2 kernel to 13.6.7-7-desktop. After a reboot, several things have happened:
How do I recover?
That’s totally unrelated to the kernel update.
13.2 does not install any syslog daemon by default, only systemd’s journal is used.
Run “journalctl” to view it.
If you want /var/log/messages back, install one of rsyslog, syslog-ng or syslogd.
My Subsonic server refuses to start
What’s Subsonic?
How did you install it? How are you starting it?
What error messages do you get?
If there’s a kernel module involved, you might have to re-compile that for the new kernel.
reboot seems to go to a command line login prompt rather than a reboot
You mean, when you run “reboot”, the system does not reboot?
Does shutdown work?
Try to run “systemctl reboot”. Does that work?
Thanks for the fast response. I figured out about the rsyslogd, and installed it. And reboot seems to work if I wait long enough.
Subsonic 5.0 was installed from an rpm (subsonic.org). What happens now is that the log shows that its port (4040) is in use, even after a fresh reboot. Part of the problem may be that Subsonic really does not support Java 1.8. Is there some way to set things up so that only subsonic uses Java 1.7?
[GC 89349K->72472K(124928K), 0.0022890 secs]9592 [main] INFO org.springframework.web.servlet.DispatcherServlet - FrameworkServlet 'subsonic': initialization completed in 669 ms
9598 [main] WARN org.mortbay.log - failed SelectChannelConnector@0.0.0.0:4040
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at org.mortbay.jetty.nio.SelectChannelConnector.open(SelectChannelConnector.java:211)
at org.mortbay.jetty.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:309)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.Server.doStart(Server.java:228)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at net.sourceforge.subsonic.booter.deployer.SubsonicDeployer.deployWebApp(SubsonicDeployer.java:133)
at net.sourceforge.subsonic.booter.deployer.SubsonicDeployer.<init>(SubsonicDeployer.java:65)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)
at
Also, its .lck file at /var/subsonic/db is there, even though I deleted it before the reboot, so it cannot connect to its database.
So apparently something is hanging?
See here for how to debug shutdown problems:
http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
Subsonic 5.0 was installed from an rpm (subsonic.org). What happens now is that the log shows that its port (4040) is in use, even after a fresh reboot. Part of the problem may be that Subsonic really does not support Java 1.8. Is there some way to set things up so that only subsonic uses Java 1.7?
Yes, run “update-alternatives --all” and select 1.7 as java version. Or uninstall the 1.8 packages, I don’t think anything in the distribution need them explicitely.
But the default java should not be changed by a kernel update… 
Also, its .lck file at /var/subsonic/db is there, even though I deleted it before the reboot, so it cannot connect to its database.
Hm. The output you posted would look to me like port 4040 is already in use, so it cannot bind to it:
9598 [main] WARN org.mortbay.log - failed SelectChannelConnector@0.0.0.0:4040 java.net.BindException: Address already in use
Any idea what may use port 4040?
Try “sudo netstat -tulpen | grep 4040”.
This doesn’t seem to be related to the kernel update at all then though, I’d say.
Yes. I knew 4040 was in use. But nothing else besides Subsonic uses it. I tracked it down using
netstat -lptuan
to a java process. I stopped Subsonic, killed the process using 4040, removed the db lock file, and this time subsonic worked.
But since I have not changed the subsonic configuration at all, why is it finding the port in use from a cold reboot?
It is also strange that Subsonic is working better than it did before (yesterday). Now that it has started, it displays the album artwork, which it did not do before.
With respect to Java, I need Java 8 for my software development, so update-alternatives will not do the trick.
Thanks again,
Jim
Well, maybe the subsonic that is started during boot is in fact using that port. AIUI, subsonic is a java application, so you’d see some java process using the port of course.
Is that output you posted from trying to run subsonic manually?
And you still haven’t told me how you are actually running it during boot.
Does it come with a systemd or sysvinit service file?
Maybe it is starting too early when the network is not up yet or something like this?
It did work before the kernel update, right? (Even in this case I don’t think it’s actually the kernel update that caused the problem though. Maybe you installed other updates as well?)
This is in /etc/init.d:
#!/bin/bash#
# subsonic This shell script takes care of starting and stopping Subsonic
#
# chkconfig: - 80 20
#
### BEGIN INIT INFO
# Provides: subsonic
# Required-Start: $network $syslog
# Required-Stop: $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Subsonic daemon
# Description: Starts the Subsonic daemon. Subsonic is a web-based
# music streamer, jukebox and Podcast receiver.
# See http://subsonic.org for more details.
### END INIT INFO
# Author: Sindre Mehus <sindre@activeobjects.no>
# To change the startup parameters of Subsonic, modify the service
# configuration file /etc/sysconfig/subsonic rather than this file.
-r /etc/sysconfig/subsonic ] && . /etc/sysconfig/subsonic
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="Subsonic Daemon"
NAME=subsonic
PIDFILE=/var/run/$NAME.pid
LOCKFILE=/var/lock/subsys/$NAME
DAEMON=/usr/bin/$NAME
DAEMON_ARGS="--pidfile=$PIDFILE $SUBSONIC_ARGS"
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed.
-x "$DAEMON" ] || exit 0
# Run as root if SUBSONIC_USER is not set.
"$SUBSONIC_USER" = "" ] && SUBSONIC_USER=root
# Source function library.
#. /etc/init.d/functions
#
# Function that starts the daemon/service
#
do_start()
{
# Check if daemon is already running.
if -e $PIDFILE ]
then
ps -p $(cat $PIDFILE) > /dev/null
"$?" = 0 ] && return 1
fi
touch $PIDFILE
chown $SUBSONIC_USER $PIDFILE
-e /var/subsonic ] && chown -R $SUBSONIC_USER /var/subsonic
-e /tmp/subsonic ] && chown -R $SUBSONIC_USER /tmp/subsonic
echo $"Starting $NAME ..."
su -c "$DAEMON $DAEMON_ARGS" $SUBSONIC_USER
RETVAL=$?
echo
$RETVAL -eq 0 ] && touch $LOCKFILE
return $RETVAL
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Check if pidfile exists
! -e $PIDFILE ] && return 1
echo -n $"Stopping $NAME ..."
killproc -p $PIDFILE $DAEMON
RETVAL=$?
echo
$RETVAL -eq 0 ] && rm -f $LOCKFILE
return $RETVAL
}
case "$1" in
start)
do_start
;;
stop)
do_stop
;;
status)
status -p $PIDFILE "$NAME"
;;
restart|force-reload)
do_stop
do_start
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
exit 3
;;
esac
:
So it has an old-style sysvinit script.
Does it work when you run “sudo /etc/init.d/subsonic restart” after boot? (without killing anything)
The dependencies seem to look ok though.
But as it depends on $syslog, installing rsyslog might have made a difference. Although AFAIK, systemd-logger (should be installed by default) comes with a compatibility init script that implements $syslog.