FS#26534 - [cdemu-daemon] problem with /etc/rc.d/cdemud
Attached to Project:
Community Packages
Opened by Alexsandr Pavlov (kidoz) - Thursday, 20 October 2011, 07:59 GMT
Last edited by Ray Rashif (schivmeister) - Friday, 23 March 2012, 13:23 GMT
Opened by Alexsandr Pavlov (kidoz) - Thursday, 20 October 2011, 07:59 GMT
Last edited by Ray Rashif (schivmeister) - Friday, 23 March 2012, 13:23 GMT
|
Details
Description:
When start cdemud: Failed to parse options: Cannot parse integer value '' for --num-devices In /etc/conf.d/cdemud - NUM_DRIVES In /etc/rc.d/cdemud - --num-devices=$NUM_DEVICES Additional info: * cdemu-daemon 1.4.0-1 Steps to reproduce: Start cdemud |
This task depends upon
Closed by Ray Rashif (schivmeister)
Friday, 23 March 2012, 13:23 GMT
Reason for closing: Fixed
Additional comments about closing: Original issue has been resolved. To be continued at FS#28876
Friday, 23 March 2012, 13:23 GMT
Reason for closing: Fixed
Additional comments about closing: Original issue has been resolved. To be continued at
Output:
:: Loading vhba and loop modules [DONE]
:: Waiting for /dev/vhba_ctl [DONE]
:: Starting cdemud [DONE]
Failed to parse options: Cannot parse integer value '' for --num-devices
Steps to reproduce:
1. install cdemu-daemon (1.4.0-1) and cdemu-client (1.4.0-1)
2. sudo modprobe vhba
3. sudo rc.d start cdemud
I'm on x86_64.
# Read the settings
CONFIG_FILE=/etc/sysconfig/cdemu-daemon
The package is non-operational in this state!
So, after all, this is what I did:
/etc/rc.d/cdemud
change --bus=$SYSTEM to --bus=$BUS
/etc/conf.d/cdemud
change AUDIO_BACKEND to AUDIO_DRIVER
change NUM_DRIVES to NUM_DEVICES
/usr/bin/cdemu-daemon-system.sh and
change /etc/sysconfig/ to /etc/conf.d/ (as sysconfig does not exist on Arch)
change /tmp/ to /var/log/ (if you want logging in default log directory and not tmp)
/usr/bin/cdemu-daemon-session.sh
change to a valid and present file (like in cdemu-daemon-system.sh) and possibly add the file if it's not there already
Anyone experiencing the segfault issue I have, I recommend patching libao (for now)!
Have a look at this bug report: https://sourceforge.net/tracker/?func=detail&aid=3449342&group_id=93175&atid=603423
has to be changed to
KERNEL=="vhba_ctl", NAME="vhba_ctl", MODE="0660", OWNER="root", GROUP="cdemu"
otherwise cdemud@session-bus wont work ;)
Is maintainer dead (for us)/ orphaned this package?
Cheers
http://aur.archlinux.org/packages.php?ID=57115
And I know most of you might use gcdemu right now (gcdemu 1.4 won't work with cdemu-daemon 1.5)
http://aur.archlinux.org/packages.php?ID=57119
ATTENTION this ^^^^^ is an ugly hack!
Both packages are not meant to win a beautiy contest but they should work.
hf
(I hope) I've fixed cdemud (both script and configuration) and cdemu-daemon-system.sh. I'm not maintainer of this package, even not using it, so your feedback would be great.
Great work! Some issues:
1) Is it necessary to add something to /usr/lib/modules-load.d? I thought that automatic loading of bloat is not Arch style :(
2) Add note about cdemu group to post_install
3) Hardcode "system" in /etc/rc.d/cdemud, remove this option from /etc/conf.d/cdemud
4) Add alsa-lib and libpulse to optdepends and remove corresponding message from post_install
5) Blank cdemu-daemon-system.sh and/or replace it's contents with check for daemon state (via "rc.d list") and appropriate error message in case daemon is not launched.
6) Supress whining about missing libs by adding something like "&>/dev/null" to cdemud startup line
7) libdaemon is NOT NEEDED
1) Done: I don't think so. Removed.
2) Done.
3) I'm not so sure about this. Why should we hardcode it?
4) Done, partially: alsa-lib OK, but why libpulse?
5) Why?
6) I don't see any such whinings. Anyway missing libs _should_ error out visibly.
7) Can you verify this?
Thanks everyone for your input. Some packages like this get left behind when maintainers become busy and there's no-one else interested. But you all are Archers not for nothing ;)
>> 3) I'm not so sure about this. Why should we hardcode it?
Are you able to start daemon as root in session mode? I doubt that, D-Bus services, launched by root, are probably meant to be system-wide.
>> why libpulse?
Because it is optdepend. cdemu-daemon works fine without it, but will use it if user install it.
>> I don't see any such whinings. Anyway missing libs _should_ error out visibly.
Most likely because you have libpulse installed. On my machine cdemu-daemon tries to load it, fails but continues to work (as it is needed only for audio disks). If you add libpulse to optdepends with description "audio disks handling", it will be quite visible.
>> 5) Why?
Because package have Arch daemon script, is not it? To prevent conflicts with D-Bus service autostart we should either drop /etc/rc.d/cdemud or modify cdemu-daemon-system.sh script to made it use Arch daemon mechanics. Importing /etc/rc.d/functions and starting daemon via start_daemon in cdemu-daemon-system.sh would be nice.
7) Can you verify this?
Yes, I can.
1) Software author says libdaemon code to be ripped out on his site.
2) On my machine cdemu-daemon works just fine without libdaemon installed.
Also see https://bugs.archlinux.org/task/28876 (should this discussion be moved there?)
the wrapper script for starting a system bus instance naturally would start a service on the system bus. doing otherwise makes absolutely no sense. since it shouldn't be changed it makes sense to hardcode it.
it goes like:
1) client makes a call to the cdemu service on either session or system bus
2) dbus checks if the service is running on that bus and if not starts it (the associated wrapper script)
3) call goes through on the bus that was used.
you guys seem hung up on root or not. it's not important. system bus is available system-wide, and all users can communicate on it, so it doesn't matter if the daemon runs as root or some other user, as long as the dbus configuration says the calling user can invoke methods on that service (on that bus). session bus is naturally restricted to one user's login session. so many users will have their own cdemu instance on their own session bus. users and group and set-UID/GID is mostly just useful to restrict access either for the daemon or access to the HBA control device. the reason system bus instances usually run as root is that it needs access to the CD-images you want to mount. Of course this also represents a security issue, so usually you want to restrict which users are allowed to use the cdemu instance on the system bus. :)
>> why libpulse?
>Because it is optdepend. cdemu-daemon works fine without it, but will use it if user install it.
neither alsa nor pulse is dependencies, that is correct. but i question listing them as optional dependencies since it should be libao who depends upon backends for sound. libao already depends on alsa, and IMO it should also list pulse etc. as optional dependencies.
>> 5) Why?
>Because package have Arch daemon script, is not it? To prevent conflicts with D-Bus service autostart we should either drop /etc/rc.d/cdemud or
>modify cdemu-daemon-system.sh script to made it use Arch daemon mechanics. Importing /etc/rc.d/functions and starting daemon via start_daemon
>in cdemu-daemon-system.sh would be nice.
Hmm. If the service is already running on system bus then dbus won't try to start it a second time. However I did suggest dropping the initscript in another bugreport. https://bugs.archlinux.org/task/28876