Even if the bluetooth service was started, the
/dev/rfcomm0 device would not just automatically appear.
At minimum, the bluetooth subsystem would need to know the address of the Bluetooth device and the channel on it, so that a particular
/dev/rfcomm* device name can be bound to a particular Bluetooth device+channel combination.
You can use
rfcomm bind 0 <bdaddr> [channel] to make the binding for
/dev/rfcomm0. If you don't specify the channel number, channel 1 will be used by default. If your version of the
rfcomm still supports the
/etc/bluetooth/rfcomm.conf file and you have the address and channel information for
/dev/rfcomm0 written to it, then you can omit the address and channel information from the command - but you still need to use the command to make the binding.
Newer versions of BlueZ tools no longer seem to document the
/etc/bluetooth/rfcomm.conf file. It might be that you'll have to always use the full form of the
rfcomm bind command to set up your bindings. You might want to add these commands to
/etc/rc.local or some custom start-up script, to make them execute automatically at boot time, as the associations won't persist through a reboot.
It seems that the last major rebuild of BlueZ internals cost us some of the RFCOMM-related features, like the
/etc/bluetooth/rfcomm.conf file. But at least the
rfcomm command is still available and can do the job.