Broken startup scripts after upgrading to 2.1 - DOS line endings

Steve Evans

I have upgraded to 2.1 (thank you for the release!) and found that two services, lcdproc and bandwidthd, were failing to start with the following in the system log.

Sep 21 19:42:50	php: /status_services.php: The command '/usr/local/etc/rc.d/lcdproc.sh stop' returned exit code '2', the output was '/usr/local/etc/rc.d/lcdproc.sh: 18: Syntax error: "}" unexpected (expecting "then")'
Sep 21 19:42:59	php: /status_services.php: The command '/usr/local/etc/rc.d/bandwidthd.sh stop' returned exit code '2', the output was '/usr/local/etc/rc.d/bandwidthd.sh: 39: Syntax error: "}" unexpected (expecting "then")'

I noted that there were '^M' characters in /usr/local/etc/rc.d/lcdproc.sh:

#!/bin/sh
# This file was automatically generated
# by the pfSense service handler.

rc_start() {
        if [ `pgrep -f lcdproc_client.ph` ];then^M
                pkill -f lcdproc_client.ph^M
                sleep 1^M
fi^M
if  [ `pgrep -anx LCDd` ]; then^M
        pkill -anx LCDd ^M
        sleep 1^M
fi^M

        /usr/bin/nice -20 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf -u no
body
        /usr/bin/nice -20 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.ph
p &

}

rc_stop() {
        if [ `pgrep -f lcdproc_client.ph` ];then^M
                pkill -f lcdproc_client.ph^M
                sleep 1^M
fi^M
if  [ `pgrep -anx LCDd` ]; then^M
        pkill -anx LCDd ^M
        sleep 1^M
fi^M

}

case $1 in
        start)
                rc_start
                ;;
        stop)
                rc_stop
                ;;
        restart)
                rc_stop
                rc_start
                ;;
esac

I restored my backup of these files (bacula support is SO useful) to a copy and compared to the original:

#!/bin/sh
# This file was automatically generated
# by the pfSense service handler.

rc_start() {
        if [ `pgrep -f lcdproc_client.ph` ];then
                pkill -f lcdproc_client.ph
                sleep 1
fi
if  [ `pgrep -anx LCDd` ]; then
        pkill -anx LCDd
        sleep 1
fi

        /usr/bin/nice -20 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf -u nobody
        /usr/bin/nice -20 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php &

}

rc_stop() {
        if [ `pgrep -f lcdproc_client.ph` ];then
                pkill -f lcdproc_client.ph
                sleep 1
fi
if  [ `pgrep -anx LCDd` ]; then
        pkill -anx LCDd
        sleep 1
fi

}

case $1 in
        start)
                rc_start
                ;;
        stop)
                rc_stop
                ;;
        restart)
                rc_stop
                rc_start
                ;;
esac

Looks like somebody's been in there with a DOS editor. Removed the DOS line endings and all is well.

As this has affected two distinct packages I'm curious to know if this is a systematic problem likely to affect others.

Steve

jimp

You are not the first to report such things, but the really odd thing is that the newlines are not there on the server nor in the repository, and at least for me, I can't reproduce any issues with those packages.

Steve Evans

Oddly, when I removed and reinstalled bandwidthd the problem was no more. I've left bacula alone with the corrected lines. Perhaps this only affects packages reinstalled after an update?

Steve

phil.davis

I have bandwidthd on a few 2.1-RELEASE systems with no trouble like this. bandwidthd.sh is written on-the-fly by the bandwidthd.inc PHP code, so I don't see how that would get dodgy line endings, since it is pfSense/FreeBSD/PHP that generates it.

Steve Evans

Just been having the same issue with lcdproc-dev. Worked fine until I tried to restart is, which makes me think it's the services menu that's messing it up. I removed the dos line endings, and from the command line the script worked, but then tried to restart the service from the GUI and the script got corrupted again.

Having uninstalled and re-installed the package afresh I now find this behaviour is cured. One of those bugs that vanish when you stare at it long enough!!!

Steve