Lambda Container Image Won't Run dbus

0

I'm trying to get my custom container image to run in lambda, and I can't get the lambda to start dbus. My dbus command is:

dbus-daemon --config-file=/usr/share/dbus-1/system.conf

However, I'm getting:

dbus-daemon[26]: Failed to start message bus: Could not get UID and GID for username "messagebus" 

I'm including my own copy of /etc/passwd and /etc/group in my build:

COPY passwd group /etc/

and it seems this build step is running fine, but when I cat /etc/passwd from my handler function at runtime I see a different /etc/passwd file. Is it possible to provide my own password and group files? How can I get dbus to run?

asked a year ago466 views
1 Answer
0

Hi there,

You can provide your own password and group files in your container image by copying them to the correct location in your Dockerfile. The COPY command you have included in your question appears to be correct, so it's likely that the issue is with how the files are being used at runtime.

One thing to check is whether the user that is trying to run dbus has the correct permissions to read and use the password and group files that you have provided. You can check this by running ls -l /etc/passwd and ls -l /etc/group in your container to see who has permission to read and write to these files.

Additionally, it's worth checking whether the messagebus user that dbus is trying to use actually exists in your /passwd file. You can do this by running grep messagebus /etc/passwd to see if the user is listed in the file. If the user does not exist, dbus will not be able to start as it will not be able to get the UID and GID for the messagebus user.

Finally, it's possible that dbus is not able to start because it is not being run with the correct privileges. The dbus daemon typically requires root privileges to start, so you may need to run your dbus command with sudo to give it the necessary privileges. For example:

sudo dbus-daemon --config-file=/usr/share/dbus-1/system.conf

This should allow dbus to start properly and use the passwd and group files that you have provided in your container.

Hope this helps!

AWS
answered a year ago
  • It seems clear on further testing that /etc/passwd is NOT being replaced as expected, although /etc/group is replaced as expected. "ls -l /etc/passwd" is showing a timestamp of October for this file, while /etc/group is showing a current timestamp. So, it seems there's something else required here to get the "messagebus" user into the password file.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions