Journalctl returns 1 when service_managed is enabled (default)
NeatNerdPrime opened this issue · 8 comments
Hello @butlern,
First of all, thanks for making this module, it is very useful.
However, i run into the following issue:
When the mdadm class is included with it's default settings, it always runs into the following error thrown (timestamps are taken at that moment):
Error: Execution of 'journalctl -n 50 --since '5 minutes ago' -u mdadm --no-pager' returned 1: -- Logs begin at Fri 2017-05-26 14:20:51 CEST, end at Fri 2017-05-26 15:15:21 CEST. -- Error: /Stage[main]/Mdadm::Service/Service[mdadm]/ensure: change from stopped to running failed: Execution of 'journalctl -n 50 --since '5 minutes ago' -u mdadm --no-pager' returned 1: -- Logs begin at Fri 2017-05-26 14:20:51 CEST, end at Fri 2017-05-26 15:15:21 CEST. --
This prevents the puppet run to assemble/create the raid array, failing any other declarations depending on the raid assembly. To mitigate this, the class must be declared with the parameter service_manage set to 'false' like so:
class { 'mdadm': service_manage => false, }
This iMHO is not safe since it bypasses mdadm checks. Preferrable it should successfully run with as little modification as possible.
Do you have any suggestions to point in the correct way? I'm grinding my brain-gears on this one.
Thank you in advance for your feedback.
Hi @NeatNerdPrime, thanks for posting this. I'm unable to repro on my end. What distro are you on? Is there anything regarding either the journalctl or mdadm failures in syslog or dmesg?
As far as it preventing the assembly/creation of the raid array, I'm not sure about this. There is no explicit dependency in mdadm::array on mdadm, it only does an include mdadm so if there are runtime failures in mdadm, mdadm::array should still execute. Unless I'm mistaken about something, it's been awhile since I've looked at this module. I'll verify this though.
We are having the same issue. It is on Debian Jessie and Stretch. It looks to us that because there are no mdadm devices the services fails to start. And the module by default tries to start the service. So it looks like the systemd/init script isn't correct.
Ah, so you mean if you're not managing any devices with mdadm::array but just including mdadm?
Yes!
Interesting, I suspect it's a systemd related thing since we run a version of jessie (albeit ubuntu trusty) and haven't run into this issue (since trusty is still on upstart). If it is indeed an issue with the package maintained init scripts I'm not sure yet of a good solution aside from service_managed => false. Open to suggestions though :)
For now we have put in common.yaml:
mdadm::service_manage: false
Ok, we'll be upgrading to bionic soon which is systemd and I'll take a look at the package scripts. I'm a bit hesitant to add overrides in this module for them since they're a moving target. Gonna close this issue for now but feel free to re-open if you come across anything.
So I looked into this further and it's because under systemd the mdadm service is actually called mdmonitor. The mdadm service itself is masked which means it's linked to /dev/null and can't be started.
vagrant@bionicnate:~$ ls -l /lib/systemd/system/mdadm.service
lrwxrwxrwx 1 root root 9 Mar 7 02:43 /lib/systemd/system/mdadm.service -> /dev/null
So under systemd we want to start the mdmonitor service instead. Should be a relatively simple change since we can set the service name in params.pp. I'll patch that today.