Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd conf.d vs. PACKAGING.md and the aur package for 2.7 #51

Closed
ajs124 opened this issue Aug 17, 2014 · 6 comments
Closed

systemd conf.d vs. PACKAGING.md and the aur package for 2.7 #51

ajs124 opened this issue Aug 17, 2014 · 6 comments

Comments

@ajs124
Copy link
Contributor

ajs124 commented Aug 17, 2014

I'm in the process of updating the AUR package to 2.7 and noticed that the systemd.conf.d, as well as the init/default/rpimonitor, although it's commented there, file point to config files that don't exist in 2.7 (/etc/rpimonitor/rpimonitord.conf + /etc/rpimonitor/rpimonitord.conf.d/default.conf).
In the case of systemd this prevents the daemon from starting. The PACKAGING.md claims that /etc/rpimonitor/*.conf is parsed automatically, so what purpose do /etc/default/rpimonitor and the systemd conf.d file serve? Are there still relevant parameters to pass to /usr/bin/rpimonitord?

@XavierBerger
Copy link
Owner

I didn't create the systemd script so I didn't modify it when I did create Version 2.7.
As I don't have OS running systemd, I don't know the required modification for this start script and I'm not able to test it.
If somebody propose a pull request with an updated version of systemd script, I'll merge it.
/etc/default/rpimonitor is containing parameters dedicated to the sysVinit script (this is something usual into debian based OS).

@ajs124
Copy link
Contributor Author

ajs124 commented Aug 17, 2014

I know. I probably created that script. What I'd like to know is, if the "CONFFILE" variable in /etc/default/rpimonitor still serves a purpose. As in, are there still parameter one might want to pass to /usr/bin/rpimonitord that way? If not tools/systemd/systemd.conf.d can be deleted and the service file modified accordingly.

@XavierBerger
Copy link
Owner

A quick answer before going to bed: CONFFILE can be removed. I’ll review and update startup scripts tomorrow and certainly delete systemd.conf.d which is not needed.

Sent from my tablet.

@XavierBerger
Copy link
Owner

I did create a branch named FixIssue51 and I did update systemd files according to my understanding.
Can you confirm these changes fix the bug and if yes, close this issue?
I'll then merge this fix to the master branch.

@Yamakaky
Copy link

You also have to remove the EnvironmentFile directive. And the Type directive is unnecessary, as simple is the default value. After that, you can merge.

Woh, I didn't know you could put spaces around = !

@XavierBerger
Copy link
Owner

Update merged in master branch. I did add a tag v2.7.1 that could be usefull for package mainteners needing a valide systemd startup script.
Note: Version 2.7.1 will not be released as debian/raspbian package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants