Prior to the current version, cdemu would automatically launch cdemu-daemon when needed, via DBUS I believe. As of 3.2.5, this no longer works, and cdemu essentially just hangs and times out when called: $ cdemu status ERROR: Failed to connect to CDEmu daemon: g-io-error-quark: Error calling StartServiceByName for net.sf.cdemu.CDEmuDaemon: Timeout was reached (24) If I manually run cdemu-daemon, then suspend and tell bash to run it in the background (it doesn't seem to have a proper 'background' or 'daemon' mode option, which seems odd given what it is), then cdemu does seem to work properly, though the systemd piece seems to only be related to autostarting the daemon. Note that I'm having trouble finding any specific news or announcements about this change. I'm basing this on the following ubuntu bug report and comments from the developer: https://bugs.launchpad.net/cdemu/+bug/1926303 I tried downgrading to cdemu[-daemon]-3.2.4, and autostart worked as expected. Note that cdemu-3.2.4 lists only python 3.8 compatibility; I modified that to reference both python 3.8 and 3.9 (identical to 3.2.5) and it seems to work fine with python 3.9. I don't know exactly what's happening under the covers to make autostart work with 3.2.5 and systemd, but it'd be great if we could continue supporting non-systemd users with newer versions. Going to remain on 3.2.4 myself for not, but that's obviously not a long-term solution. Reproducible: Always Steps to Reproduce: 1. On a non-systemd system, install or upgrade to cdemu/cdemu-daemon 3.2.5. 2. modprobe vhba 3. Run cdemu status (or any other cdemu command) - you should receive the same timeout message I posted above Actual Results: cdemu does not run correctly because the underlying daemon service is not started Expected Results: cdemu-daemon should be auto-started as needed so cdemu can run successfully
Yes, that's what postinst says. Upstream has removed explicit support for non-systemd systems. You're on your own.
