Error Starting Service Boulder -SA-1

Help
1

Hello All,

I am trying to install and run the latest boulder on my local system

and i am getting an error this way attached the screenshots

image
image1201×438 138 KB

Error starting service and existing boulder-1 container
is there any way i can debug what is going wrong here ?

just for more information i am attaching more details screenshots

image
image1046×372 97.4 KB

image
image1047×443 241 KB

Can anybody help me to debug this issue ? what might be going wrong for stopping this services ?

2

Please consider copy and pasting text instead of screenshots. Screenshots are difficult to read and not easy to copy from.

The problem is stated in the message:

Unix syslog delivery error.

If boulder is configured to use syslog, it requires that to be available.

Syslog configuration docs:

the docker-compose setup used for Boulder development comes with a syslog daemon that's configured properly. If you're running elsewhere, setting SyslogLevel to -1 to disable syslog is probably easiest, assuming you've got stdout/stderr collection set up.

6 Likes
3

Thank you for your reply,

i could see that under boulder-tools on the build.sh it added rsyslog to the image and as i see the build is successful
apt-get install -y --no-install-recommends
mariadb-client-core-10.3
rsyslog
build-essential
...

still it says the "Unix syslog delivery error"

If I want to disable the syslog level, does it need to be done in each service's configuration file? For example, if it's for VA, should it be in va.json? If so, then I would have to disable logging for all modules, and I won't be able to see any logs or transactions during execution.

I am actually running this version on the redhat based (Photon os) env, just for more info

expecting your kind support for any lead, thanks in advance.

4

Note that Boulder has two logging mechanisms: it can log to syslog, and it can log to stdout. You can disable the former (by setting its log level to -1) while leaving the latter in place. But yes, you do have to do this in every service.

4 Likes
5

Thank you very much for your kind support.

It looks like Boulder is running now.

As you mentioned, I changed the syslogLevel to -1 in all the config files under test/config, but I also had to modify a couple of other files because syslog errors were still being displayed.

On the mail-test-srv, I had to explicitly add SyslogLevel: -1:

go

srv := mailSrv{
	closeFirst: *closeFirst,
	logger:     cmd.NewLogger(cmd.SyslogConfig{StdoutLevel: 7, SyslogLevel: -1}),
}

The other change was in the log-validator.json config. It originally had only stdoutLevel, so I had to explicitly define "syslogLevel": -1:

json

{
	"syslog": {
		"stdoutLevel": 7,
		"syslogLevel": -1
	}
}

These changes are based on my observations, but they worked for me.

i have noticed another few Warning and error while compose setup up

Access denied for user 'proxysql'@'10.77.77.3' 

bmysql-1     | 2025-05-16 11:29:02 0 [Note] Added new Master_info '' to hash table
bmysql-1     | 2025-05-16 11:29:02 0 [Note] mysqld: ready for connections.
bmysql-1     | Version: '10.5.28-MariaDB-ubu2004-log'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
bmysql-1     | 2025-05-16 11:29:08 3 [Warning] Access denied for user 'proxysql'@'10.77.77.3' (using password: NO)
bmysql-1     | 2025-05-16 11:29:18 4 [Warning] Access denied for user 'proxysql'@'10.77.77.3' (using password: NO)
bmysql-1     | 2025-05-16 11:29:28 5 [Warning] Access denied for user 'proxysql'@'10.77.77.3' (using password: NO)
bmysql-1     | 2025-05-16 11:29:38 6 [Warning] Access denied for user 'proxysql'@'10.77.77.3' (using password: NO)
bmysql-1     | 2025-05-16 11:29:48 7 [Warning] Access denied for user 'proxysql'@'10.77.77.3' (using password: NO)
bmysql-1     | 2025-05-16 11:29:58 8 [Warning] Access denied for user 'proxysql'@'10.77.77.3' (using password: NO)
bmysql-1     | 2025-05-16 11:29:58 9 [Warning] Access denied for user 
'proxysql'@'10.77.77.3' (using password: NO)
bproxysql-1  | 2025-05-16 11:29:58 MySQL_Monitor.cpp:1298:monitor_connect_thread(): [ERROR] Server boulder-mysql:3306 is returning "Access denied" for monitoring user
boulder-1    | rsyslog startup failure, child did not respond within startup timeout (60 seconds)
boulder-1    |    ...done.
bmysql-1     | 2025-05-16 11:29:58 10 [Warning] Aborted connection 10 to db: 'unconnected' user: 'unauthenticated' host: '10.77.77.77' (This connection closed normally without authentication)
boulder-1    | Connected to boulder-mysql:3306
boulder-1    | Connected to bproxysql:6032
boulder-1    | Connected to bpkilint:80
boulder-1    |
boulder-1    | boulder_sa_test
boulder-1    | Doesn't exist - creating
boulder-1    | Applied 7 migrations
boulder-1    | Added users from ../db-users/boulder_sa.sql
boulder-1    |
boulder-1    | boulder_sa_integration
boulder-1    | Doesn't exist - creating
boulder-1    | Applied 7 migrations
boulder-1    | Added users from ../db-users/boulder_sa.sql

´´´´
Another Error
´´´´
bproxysql-1  | 2025-05-16 11:30:30 MySQL_Session.cpp:6567:handler___status_WAITING_CLIENT_DATA___STATE_SLEEP___MYSQL_COM_QUERY_qpo(): [ERROR] Unable to parse query. If correct, report it as a bug: SET max_statement_time=13.300000
bproxysql-1  | 2025-05-16 11:30:30 MySQL_Session.cpp:6567:handler___status_WAITING_CLIENT_DATA___STATE_SLEEP___MYSQL_COM_QUERY_qpo(): [ERROR] Unable to parse query. If correct, report it as a bug: SET long_query_time=11.200000
bproxysql-1  | 2025-05-16 11:30:30 MySQL_Session.cpp:6567:handler___status_WAITING_CLIENT_DATA___STATE_SLEEP___MYSQL_COM_QUERY_qpo(): [ERROR] Unable to parse query. If correct, report it as a bug: SET long_query_time=11.200000
bproxysql-1  | 2025-05-16 11:30:30 MySQL_Session.cpp:6567:handler___status_WAITING_CLIENT_DATA___STATE_SLEEP___MYSQL_COM_QUERY_qpo(): [ERROR] Unable to parse query. If correct, report it as a bug: SET max_statement_time=13.300000

and another error Generating CR Failed Error

boulder-1    | 11:35:05.224532 3 crl-updater nN-Cpws [AUDIT] Generating CRL failed: id=[{"issuerID":6762885421992935,"shardIdx":3,"crlNumber":1747395305222271849}] err=[computing shardmap: rpc error: code = Unknown desc = certificateStatus table notAfter column is empty]
boulder-1    | 11:35:25.038810 3 crl-updater tbzLtgs [AUDIT] Generating CRL failed: id=[{"issuerID":6762885421992935,"shardIdx":1,"crlNumber":1747395325037197675}] err=[computing shardmap: rpc error: code = Unknown desc = certificateStatus table notAfter column is empty]
boulder-1    | 11:36:27.837695 3 crl-updater lYXC7wI [AUDIT] Generating CRL failed: id=[{"issuerID":56183656833365902,"shardIdx":8,"crlNumber":1747395387836013849}] err=[computing shardmap: rpc error: code = Unknown desc = certificateStatus table notAfter column is empty]
boulder-1    | 11:37:28.407929 3 crl-updater tPfDsgk [AUDIT] Generating CRL failed: id=[{"issuerID":56560759852043581,"shardIdx":9,"crlNumber":1747395448405355647}] err=[computing shardmap: rpc error: code = Unknown desc = certificateStatus table notAfter column is empty]
boulder-1    | 11:46:47.506953 3 crl-updater i8bY8wQ [AUDIT] Generating CRL failed: id=[{"issuerID":43104258997432926,"shardIdx":8,"crlNumber":1747396007503936288}] err=[computing shardmap: rpc error: code = Unknown desc = certificateStatus table notAfter column is empty]
´´´´


Do these errors affect or disrupt any of Boulder's processes?
Do I need to change anything to fix them?
6

The first set of warnings you report are benign, those are just because the docker-compose environment spins up multiple containers simultaneously, and it takes a moment for them to establish connections to each other.

The second set of errors is because the database contains zero issued certificates. The crl-updater considers the situation where zero certificates exist to be so cosmically unlikely (given that we issue 7 million certificates every day) that it must be the result of an error.

Note that the environment you're running is not intended to be a production deployment environment. The docker-compose.yml file and all of the //test/config[-next]/service.json files are designed around the requirements of our integration test environment. We have wholly separate, unfortunately not open-source, infrastructure and configuration for our production environment.

At the end of the day, we are a very small team who develop Boulder (and its test environment) for our own purposes. I'm very happy to see you running Boulder for your own project, but we cannot provide extensive support or debugging for situations that fall outside our core use-case.

6 Likes
7

Thank you very much, it helps a lot.
Yes, I understand — I have read the Boulder documentation.

2 Likes
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.