Hm, I thought pam would silently handle that.

Clearly that change needs to be conditional on the systemd distro feature.

I checked and indeed the library is missing, however I could not reproduce the same way, with my current setup (pulled master yesterday) it breaks gconf complaining about the same thing.

I also tried my systemd branch, which has the systemd.bbclass and it works, so I'm chasing that lead now.

The problem is that pam_systemd only exists in systemd distros, but the pam configuration always refers to it.  I was under the impression that pam would silently handle optional pam modules without error, but that doesn't appear to be the case.

The systemd reference in the pam configuration needs to be conditional on the systemd feature, or truly optional.

Actually, pam.conf says:

"If the type value from the list above is prepended with a - character the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system. This can be useful especially for modules which are not always installed on the system and are not required for correct authentication and authorization of the login session."

Sounds ideal.

ok, missed the part where systemd was disabled.
Looking into pam then.

I could initially reproduce this, but could not anymore after Thursday morning pull.

I can reproduce it with latest master branch:
git rev: ee1f126ad5cb2c6af66815e55720257a1efc5a49

Steps:
##############
1. Add DISTRO_FEATURES_append = " pam" to conf/local.conf and build the image.
2. Boot up the image and check the /var/log/message
##############

Check the message log, I can see the following error:
###############
Feb  6 09:03:29 qemux86 authpriv.err passwd[822]: PAM unable to dlopen(/lib/security/pam_systemd.so): /lib/security/pam_systemd.so: cannot open shared object file: No such file or directory
Feb  6 09:03:29 qemux86 authpriv.err passwd[822]: PAM adding faulty module: /lib/security/pam_systemd.so
###############

(In reply to comment #6)
> I can reproduce it with latest master branch:
> git rev: ee1f126ad5cb2c6af66815e55720257a1efc5a49
> 
> Steps:
> ##############
> 1. Add DISTRO_FEATURES_append = " pam" to conf/local.conf and build the
> image.
> 2. Boot up the image and check the /var/log/message
> ##############
> 
> Check the message log, I can see the following error:
> ###############
> Feb  6 09:03:29 qemux86 authpriv.err passwd[822]: PAM unable to
> dlopen(/lib/security/pam_systemd.so): /lib/security/pam_systemd.so: cannot
> open shared object file: No such file or directory
> Feb  6 09:03:29 qemux86 authpriv.err passwd[822]: PAM adding faulty module:
> /lib/security/pam_systemd.so
> ###############

please dump here the output for "systemctl --version"

I can't reproduce.
I checked that systemd is compiled with pam support and it is. The pam_systemd.so is in it's place and in consequence there is not error message trying to load the library.

Please confirm.

(In reply to comment #8)
> I can't reproduce.
> I checked that systemd is compiled with pam support and it is. The
> pam_systemd.so is in it's place and in consequence there is not error
> message trying to load the library.
> 
> Please confirm.

Hi Radu,

I made a mistake. I didn't set the init manager to systemd in local.conf. After added the line DISTRO_FEATURES_INITMAN ?= "systemd" in local.conf, the error message disappeared. But if we don't use systemd, the pam still want to load pam_systemd.so, is this a bug ? Do we need to fix it ?

Ok, then I'll give a shot to what Ross was suggesting.

(In reply to comment #9)

> Hi Radu,
> 
> I made a mistake. I didn't set the init manager to systemd in local.conf.
> After added the line DISTRO_FEATURES_INITMAN ?= "systemd" in local.conf, the
> error message disappeared. But if we don't use systemd, the pam still want
> to load pam_systemd.so, is this a bug ? Do we need to fix it ?

I've tried this morning a clean build on master with sysvinit enabled (and pam). I could not find any warning/error message in logs with regard to pam_systemd.so or anything related to systemd for that matter.

same on my side.

(In reply to comment #11)
> (In reply to comment #9)
> 
> > Hi Radu,
> > 
> > I made a mistake. I didn't set the init manager to systemd in local.conf.
> > After added the line DISTRO_FEATURES_INITMAN ?= "systemd" in local.conf, the
> > error message disappeared. But if we don't use systemd, the pam still want
> > to load pam_systemd.so, is this a bug ? Do we need to fix it ?
> 
> I've tried this morning a clean build on master with sysvinit enabled (and
> pam). I could not find any warning/error message in logs with regard to
> pam_systemd.so or anything related to systemd for that matter.

Which image type do you test ? The issue happens on sato and sato-sdk image.

tried sato.

DISTRO_FEATURES_append = " pam"

There must be a space between " and pam

I tried qemuarm, still have this issue.

This issue still happens on master: 9ffee9add2d0380f4025e7a678a166f25a7d659e

Reopen it.

asked QA to take a look over

gave another try today, sato and sato-sdk

Build Configuration:
BB_VERSION        = "1.17.1"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS        = "i586-poky-linux"
MACHINE           = "qemux86"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20130402"
TUNE_FEATURES     = "m32 i586"
TARGET_FPU        = ""
meta              
meta-yocto        
meta-yocto-bsp    = "master:92aeb31341b28b193d616ab5cf38af1b9673e37d"

run both images in quemu and grep'd for systemd in /var/log/messages, nothing came up.

@Yi Zhao: Please don't reopen this, let QA team to give it a try, and if they can't please work with them until they do, assuming this is a valid bug.

I can replicate.  The key is that this only happens on sysvinit images.

(In reply to comment #19)
> I can replicate.  The key is that this only happens on sysvinit images.

so a clean build with systemd disabled should do it, right?

Yep, or an autobuilt image.  Annoying prefixing the pam line with - doesn't seem to work, this machine I just tried it on won't start X anymore.

Could not reproduce on master branch, commit ID: fe336b149552b1f4f24d979c40302653298b98cc

tried again following builds (core-image-sato) (clean builds)

Build Configuration:
BB_VERSION        = "1.19.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS        = "i586-poky-linux"
MACHINE           = "qemux86"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20130513"
TUNE_FEATURES     = "m32 i586"
TARGET_FPU        = ""
meta              
meta-yocto        
meta-yocto-bsp    = "master:f7afeeb75993b159bb8959e0309bc5eb3978a8fb"

Build Configuration:
BB_VERSION        = "1.19.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS        = "powerpc-poky-linux"
MACHINE           = "qemuppc"
DISTRO            = "poky"
DISTRO_VERSION    = "1.3+snapshot-20130513"
TUNE_FEATURES     = "m32 fpu-hard ppc603e"
TARGET_FPU        = ""
meta              
meta-yocto        
meta-yocto-bsp    = "master:f7afeeb75993b159bb8959e0309bc5eb3978a8fb"

Still happening:

Sep 19 11:31:54 genericx86 login[1329]: PAM unable to dlopen(/lib/security/pam_systemd.so): /lib/security/pam_systemd.so: cannot open shared object file: No such file or directory

Will investigate.

Patch sent to oe-core.

Merged in oe-core 3ccb0855a7a6b147e5025855c6376747ba72986a.

Verified in master branch.
Commit ID: 4d8ab87d25ea6e59dc88375813ef88ee0ac813d0
No errors in /var/log/messages.