Hide Forgot
Description of problem: dscreate CLI is not creating an instance and failing with the error: Job for dirsrv@t<instance_name>.service failed because of unavailable resources or another system error. Version-Release number of selected component (if applicable): 389-ds-base-1.4.0.20-9.module+el8.0.0+3000+3c84e334.x86_64 How reproducible: Every time Steps to Reproduce: 1. dscreate from-file <file_name>.inf OR dscreate interactive Actual results: Failing to create Directory Server's instance. Expected results: It should create the instance successfully without any error. Additional info:
I'm stumped. I built rpms from scratch on your test system using the same source code that is in 1.4.0.20-9 and it installs fine every time.
(In reply to mreynolds from comment #2) > I'm stumped. I built rpms from scratch on your test system using the same > source code that is in 1.4.0.20-9 and it installs fine every time. I am still facing the same issue while trying the same on the test machine. [root@vm-idm-005 ~]# dscreate interactive Install Directory Server (interactive mode) =========================================== Enter system's hostname [vm-idm-005.lab.eng.pnq.redhat.com]: Use strict hostname verification (set to "no" if using GSSAPI behind a load balancer) [yes]: yes Enter the instance name []: test Enter port number [389]: Create self-signed certificate database [yes]: Enter secure port number [636]: Enter Directory Manager DN [cn=Directory Manager]: Enter the Directory Manager password: Confirm the Directory Manager Password: Enter the database suffix (or enter "none" to skip) [dc=vm-idm-005,dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com]: dc=example,dc=com Create sample entries in the suffix [no]: yes Do you want to start the instance after the installation? [yes]: yes Are you ready to install? [no]: yes Starting installation... Created symlink /etc/systemd/system/multi-user.target.wants/dirsrv@test.service → /usr/lib/systemd/system/dirsrv@.service. Job for dirsrv@test.service failed because of unavailable resources or another system error. See "systemctl status dirsrv@test.service" and "journalctl -xe" for details. Error: Command '['systemctl', 'start', 'dirsrv@test']' returned non-zero exit status 1. Also with the inf file. [root@vm-idm-005 ~]# dscreate from-file instance.inf Starting installation... Job for dirsrv@dsinstance.service failed because of unavailable resources or another system error. See "systemctl status dirsrv@dsinstance.service" and "journalctl -xe" for details. Error: Command '['systemctl', 'start', 'dirsrv@dsinstance']' returned non-zero exit status 1.
I think I'm testing on a different system: vm-idm-033.lab.eng.pnq.redhat.com Is there another one I should be using?
Okay, I apparently was sabotaging my own testing. For some reason when I was building my test RPMS on the beaker systems, those builds were updating the filesystem in a way that "fixed" the problem. So every RPM I tested after that "worked". This obviously gave me inconsistent test results, and sent me looking in the wrong direction. Only after trying a fresh RHEL 8 system with rpms built on a different system was the problem still present. I was able to verify that this problem is fixed upstream, and I'm pretty sure fix is found in these two related tickets: https://pagure.io/389-ds-base/issue/50123 - with_tmpfiles_d is associated to systemd https://pagure.io/389-ds-base/issue/50125 - perl fix ups for tmpfiles I will be confirming this tomorrow
There was a regression that appears was introduced in 1.4.0.20-8 - this is now fixed.
Build Tested: 389-ds-base-1.4.0.20-10.module+el8.0.0+3096+101825d5.x86_64 1) Creating an instance using the inf file. [root@vm-idm-005 ~]# dscreate from-file instance.inf Starting installation... Created symlink /etc/systemd/system/multi-user.target.wants/dirsrv@dsinstance-new.service → /usr/lib/systemd/system/dirsrv@.service. Completed installation for dsinstance-new [root@vm-idm-005 ~]# status-dirsrv Status of instance "dsinstance-new" ● dirsrv@dsinstance-new.service - 389 Directory Server dsinstance-new. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2019-04-24 22:33:51 IST; 5s ago 2) Creating an instance in interactive mode. [root@vm-idm-005 ~]# dscreate interactive Install Directory Server (interactive mode) =========================================== Enter system's hostname [vm-idm-005.lab.eng.pnq.redhat.com]: Use strict hostname verification (set to "no" if using GSSAPI behind a load balancer) [yes]: Enter the instance name [vm-idm-005]: Enter port number [389]: Create self-signed certificate database [yes]: Enter secure port number [636]: Enter Directory Manager DN [cn=Directory Manager]: Enter the Directory Manager password: Confirm the Directory Manager Password: Enter the database suffix (or enter "none" to skip) [dc=vm-idm-005,dc=lab,dc=eng,dc=pnq,dc=redhat,dc=com]: dc=example,dc=com Create sample entries in the suffix [no]: yes Are you ready to install? [no]: yes Starting installation... Created symlink /etc/systemd/system/multi-user.target.wants/dirsrv@vm-idm-005.service → /usr/lib/systemd/system/dirsrv@.service. Completed installation for vm-idm-005 The instance is up and running, marking this as VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:3401