Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ray Rashif (schivmeister)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

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 
Comment by Alexander F Rødseth (xyproto) (trontonic) - Thursday, 20 October 2011, 11:51 GMT
Confirmed.

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.
Comment by Dyrver Eriksson (dyrvere) - Sunday, 23 October 2011, 11:18 GMT
Possible fix is to enter your config and change NUM_DRIVES= to NUM_DEVICES= instead, the value name has changed since last version.
Comment by Alexsandr Pavlov (kidoz) - Monday, 24 October 2011, 17:37 GMT
This correct decision.
Comment by Dimos (bendersteed) - Tuesday, 25 October 2011, 19:34 GMT
@dyrvere Which config are you refering to?
Comment by Dyrver Eriksson (dyrvere) - Wednesday, 26 October 2011, 01:44 GMT
@Dimos "/etc/conf.d/cdemud" OR "/home/user/.cdemu-daemon" or just delete it and another file made for cdemud in your usr folders will work aka. "/usr/bin/cdemu-daemon-session.sh" "/usr/bin/cdemu-daemon-system.sh"
Comment by Dyrver Eriksson (dyrvere) - Wednesday, 26 October 2011, 01:47 GMT
Oh, now I remember what I did, seems this is default now when running as system-session which is wrong AFAIK. Correct it.
# Read the settings
CONFIG_FILE=/etc/sysconfig/cdemu-daemon
Comment by Swift Geek (swiftgeek) - Sunday, 01 January 2012, 04:08 GMT
And change --bus=$SYSTEM to --bus=$BUS in /etc/rc.d/cdemud
Comment by David Runge (davezerave) - Sunday, 08 January 2012, 14:56 GMT
I think the maintainer should definitely look into this and correct the config files, the destinations set, etc.
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
Comment by Swift Geek (swiftgeek) - Sunday, 08 January 2012, 15:56 GMT
KERNEL=="vhba_ctl", NAME="%k", MODE="0660", OWNER="root", GROUP="cdemu"
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
Comment by Thomas Schneider (BlackLotus) - Monday, 27 February 2012, 21:51 GMT
For everyone who wants to have a working cdemu-daemon here is a package that's "fixed"
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
Comment by Bartłomiej Piotrowski (Barthalion) - Saturday, 10 March 2012, 20:06 GMT
Mind you checking cdemu-daemon-1.5.0-2 from [community-testing]?
(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.
Comment by Alexander (AlexanderR) - Sunday, 11 March 2012, 07:56 GMT
2Bartłomiej Piotrowski (Barthalion)
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
Comment by Ray Rashif (schivmeister) - Wednesday, 21 March 2012, 15:55 GMT
Please see new update in testing.

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 ;)
Comment by Alexander (AlexanderR) - Wednesday, 21 March 2012, 23:00 GMT
2Ray Rashif (schivmeister)
>> 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?)
Comment by Henrik S. (hstokset) - Thursday, 22 March 2012, 20:04 GMT
>> 3) I'm not so sure about this. Why should we hardcode it?

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

Loading...