Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 642106 - sys-power/nut: upslog fails to start due to missing options in init script.
Summary: sys-power/nut: upslog fails to start due to missing options in init script.
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Robin Johnson
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-23 13:03 UTC by Gustav Schaffter
Modified: 2018-01-01 19:07 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gustav Schaffter 2017-12-23 13:03:41 UTC
The init script for sys-power/nut doesn't pick up the UPSLOG_OPTS variable from /etc/conf.d/upslog or doesn't correctly forward the information to the upslog binary.

(Alternatively the variable is not named correctly in the provided /etc/conf.d/upslog configuration file?)




I had to fiddle around with the init script to get upslog started.

=> Original contents of /etc/init.d/upslog :

start() {
        ebegin "Starting upslog"
        start-stop-daemon --start --quiet --exec ${bin}
        eend $?
}


=> The following works (but may not necessarily adhere to 'best practices'. I'm not an init-script developer.)
My solution was to add the ' -- ${UPSLOG_OPTS}' part of the start-stop-daemon command.

start() {
        ebegin "Starting upslog"
        start-stop-daemon --start --quiet --exec ${bin} -- ${UPSLOG_OPTS}
        eend $?
}


=> Removing the --quiet was very helpful during the investigations:

start() {
        ebegin "Starting upslog"
        #start-stop-daemon --start --exec ${bin}
        eend $?
}


Don't know what the final standardized and proper solution will be, but my work-around should put some lights on the problem.
Furthermore, there should probably be some code to verify the existence of the /etc/conf.d/upslog file plus that the variable UPSLOG_OPTS is set to something (like: if [[ ! -z "${UPSLOG_OPTS}" ]])

Still, it *could* just be that the variable UPSLOG_OPTS is given the wrong name in the package-provided /etc/conf.d/upslog configuration file.


The above is equally valid in versions 2.6.5-r1 and (~)2.7.4-r1 but I haven't verified the intermediate versions.