Bug 720513

Created attachment 512297 [details]
Native systemd service file for boa

https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
https://fedoraproject.org/wiki/Packaging:Tmpfiles.d

Until there is a good way to handle the conditionals in the same fashion as the sysvinit script, I do not believe it makes sense to migrate this to a system unit service.

I've explained the issue to Lennart, and he's thinking about the best way to support it in systemd.

Created attachment 534065 [details]
Native systemd service file for boa

(In reply to comment #2)
> Until there is a good way to handle the conditionals in the same fashion as the
> sysvinit script, I do not believe it makes sense to migrate this to a system
> unit service.
> 
> I've explained the issue to Lennart, and he's thinking about the best way to
> support it in systemd.

Sorry not following what the problem is here.

The /etc/sysconfig/ file serves no purpose any more given that users and admins alike should just copy the unit file to /etc/systemd/system directory and alter the already existing parameters there or create a new empty one add an .include directive along with any addition they want to make to it.

I see no reason not to simple source the sysconfig.  Mattias, if you have no objections, I'll go ahead with this.

I still haven't written any systemd files yet, so I don't have any idea what the proper solution here is.

Reminder of the problem : Boa doesn't have a configuration file, it expects all of its options on the command line. Spot seemed to imply that this couldn't be easily done for systemd, like it was for the sysv script by sourcing the sysconfig file.

Jon : If you have a clean solution to this, please go ahead!

It's actually very simple, though it may not once have been.  If your sysconfig is /etc/sysconfig/foo and contains

FOO=onceler
BAR=quatrain
BAZ=bicuit

then your unit file can be something like:

[Unit]
Description=A service for doing things
After=syslog.target

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/foo
ExecStart=/usr/sbin/food $FOO $BAR $BAZ
ExecReload=/usr/sbin/food -k restart

And Bob's your uncle.  I can do it if you like.

I like :-)

No, actually, it isn't that simple.

This is how it was executing the daemon in start() in the old initscript:

daemon $exec ${SERVERROOT+" -c $SERVERROOT"}${CHROOT+" -r $CHROOT"}${DEBUG_LEVEL+" -l $DEBUG_LEVEL"} 2>/dev/null

You will note that it does not say:

daemon $exec ${SERVERROOT} ${CHROOT} ${DEBUG_LEVEL} 2>/dev/null

If those variables are set, then specific cmdline flags need to be passed to the daemon. The shell nature of the old initscript made this possible by invoking conditionalized expansions which added the various cmdline flags. Systemd has no such mechanism. boa does not technically _need_ any of these optional flags, but you cannot pass (for example) -c without also telling -c what the $SERVERROOT is, so you can't safely hardcode -c into the unit file.

The only way to make this work is to adjust the sysconfig file such that each of the options becomes a string including cmdline flags e.g.

CHROOT="-r /foo/bar"

The reason I didn't do it that way is because it would break old-style sysconfig files for boa, and since it is marked as a config(noreplace), I'm not sure there is a good way to force that change on everyone without nasty scripting.

Ooohh.  Yuck. :(

Maybe Just Do It and put it in the Release Notes?  I don't love it, but it's got to be done eventually.  Or do an update removing the noreplace, waiting a release, and then moving forward?  Or is that too evil? :)

(In reply to comment #10)
> Ooohh.  Yuck. :(
> 
> Maybe Just Do It and put it in the Release Notes? 

I think this is probably the proper option to choose, although, I suspect it will result in _all_ of the existing boa users filing bugs against it failing to start. I was previously hopeful that systemd would add some sort of conditional mechanism to handle it natively, but I really don't have that hope anymore.

Yeah.

I'll work something up and post it here for review.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

[Unit]
Description=Boa web server
After=network.target

[Service]
ExecStart=/usr/sbin/boa -d

[Install]
WantedBy=multi-user.target

--
Here's a working unit.

Sorry, I've just realized that the same unit was attached to this bug.

Sorry, I am still asleep. The point is that Type=forking is not needed at all.

Hi, 

Any chances of this getting fixed at least by Fedora-20, "Boa" seems to be needed by other packages like moodle and can't configure moodle unless "Boa" is fixed.

Any workaround ? 

Regards
Niranjan

boa-0.94.14-0.21.rc21.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/boa-0.94.14-0.21.rc21.fc19

boa-0.94.14-0.21.rc21.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/boa-0.94.14-0.21.rc21.fc20

Package boa-0.94.14-0.21.rc21.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing boa-0.94.14-0.21.rc21.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17684/boa-0.94.14-0.21.rc21.fc19
then log in and leave karma (feedback).

boa-0.94.14-0.21.rc21.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

boa-0.94.14-0.21.rc21.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.