You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our test servers are running on AWS with the AMI image (Flatcar-beta-3602.1.0-hvm).
They are unable to start sssd.service with the error message: sssd[5968]: Could not open file [/var/log/sssd/sssd.log]. Error: [2][No such file or directory]
Impact
We integrate the EC2 machine with our authentication server.
Work around: mkdir -p /var/log/sssd before starting sssd.service
The downstream patch we apply uses tmpfiles instead of the keepdir ebuild directive: flatcar/scripts@3e25e23
However, it forgot this very folder.
I think we might just use keepdir because we have some logic to generate tmpfile directives from the created folders, what do you think, @krnowak?
Edit: This package has some legacy mechanisms, I hope upstream/Gentoo has improvements with newer versions.
Also, with the /etc overlay we probably can use insinto /etc/sssd again and drop this downstream change.
The downstream patch we apply uses tmpfiles instead of the keepdir ebuild directive: flatcar/scripts@3e25e23 However, it forgot this very folder. I think we might just use keepdir because we have some logic to generate tmpfile directives from the created folders, what do you think, @krnowak?
Yeah, I'd agree in general, but I suppose that the quickest fix right now is to add the missing entry to the sssd tmpfiles config file.
Edit: This package has some legacy mechanisms, I hope upstream/Gentoo has improvements with newer versions. Also, with the /etc overlay we probably can use insinto /etc/sssd again and drop this downstream change.
That's something I'd do when trying to move this package to portage-stable. Or at least minimize the amount of Flatcar modifications that we make in this ebuild. It's a material for a separate PR, I'd say.
Description
Our test servers are running on AWS with the AMI image (Flatcar-beta-3602.1.0-hvm).
They are unable to start
sssd.service
with the error message:sssd[5968]: Could not open file [/var/log/sssd/sssd.log]. Error: [2][No such file or directory]
Impact
We integrate the EC2 machine with our authentication server.
Work around:
mkdir -p /var/log/sssd
before startingsssd.service
Environment and steps to reproduce
a. systemctl start sssd.service
The text was updated successfully, but these errors were encountered: