Getting the following error when trying to send a test e-mail using SMTP Legacy Auth:
[18-Aug-2022 22:02:11 UTC] PHP Fatal error: Uncaught Error: Class "Mailer" not found in /var/www/html/bootstrap.php:317
Stack trace:
#0 /var/www/html/bootstrap.php(203): Bootstrap::croak()
#1 /var/www/html/main.inc.php(28): Bootstrap::connect()
#2 /var/www/html/scp/staff.inc.php(20): require_once('/var/www/html/m...')
#3 /var/www/html/scp/admin.inc.php(16): require_once('/var/www/html/s...')
#4 /var/www/html/scp/emailtest.php(16): require('/var/www/html/s...')
#5 {main}
thrown in /var/www/html/bootstrap.php on line 317

Update: This does not happen after removing the OAUTH2 plugin.

  • KevinTheJedi replied to this.

  • Issue resolved, needed to rebuild ost__search table with:

    ALTER TABLE ost__search ENGINE=InnoDB;

    For those who may read this for their production environments: Always make a backup first!

    rblake

    I actually have this error on my list to address. @ntozier ran into this and pointed it out to me a few or more days ago.

    The true issue is your instance can’t connect to the database as it’s calling Bootstrap::croak(). This is only called when the system can’t start properly and is typically due to not being able to connect to the database. The reason it’s throwing the error is because it’s trying to email the admin the error preventing the system from starting but class mailer isn’t found.

    Cheers.

        KevinTheJedi Shouldn't I then expect osTicket to not work if the database isn't operational? Because it's working fine for the most part, just when trying to do a mail function is when it "croaks" (aptly named function).

            rblake

            Yes, if you search the code the only places we call croak is when it can’t start/load the config or when it can’t connect to the database. In your stack trace you can see it tries Bootstrap::connect() and then croaks so it can’t connect to the database.

            You should be able to var_dump the real error before it errors out in croak.

            Cheers.

                KevinTheJedi It appears that another error happening was causing a loss of connectivity to the database briefly, which throws this error message. I haven't been able to reproduce it since making the change to output the error to my filesystem (using var_dump) as opposed to sending an e-mail.

                You probably already are working on this as well but Diagnostic e-mail sending is working fine but sending e-mails out automatically after new tickets are created is not working. Tried without SMTP auth using a relay server and using O365. Both work with diagnostic but not through regular osticket calls.

                    rblake

                    Send us an email mentioning this thread and we can schedule a call with you to look into the issue.

                    Cheers.

                        KevinTheJedi Certainly, e-mail sent but no confirmation received. I'm presuming that's intentional.

                          FYI: Did a packet capture and narrowed down the issue to a malformed packet response from the MariaDB SQL instance. An INSERT statement is sent to the ost_audit table and the response is the malformed packet. Further INSERT queries go through fine.

                          @rblake

                          When I Google this it hints a few different causes one being your MySQL client is out of date/buggy another being the max_allowed_packet and innodb_log_file_size settings. You can try googling to see if the suggested fixes work for you.

                          Cheers.

                            KevinTheJedi

                            I actually tried the Google results suggestions to no avail.

                            However, I am now seeing an error in the mariadb logs:

                            Version: '10.10.1-MariaDB-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
                            2022-08-22 8:43:54 0 [Note] InnoDB: Buffer pool(s) load completed at 220822 8:43:54
                            2022-08-22 8:44:18 7 [ERROR] InnoDB: (Duplicate key) writing word node to FTS auxiliary index table osticket.ost__search
                            2022-08-22 08:44:18 0x7fabe8135700 InnoDB: Assertion failure in file /home/buildbot/buildbot/padding_for_CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX/mariadb-10.10.1/storage/innobase/que/que0que.cc line 728
                            InnoDB: Failing assertion: trx->error_state == DB_SUCCESS
                            InnoDB: We intentionally generate a memory trap.
                            InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
                            InnoDB: If you get repeated assertion failures or crashes, even
                            InnoDB: immediately after the mariadbd startup, there may be
                            InnoDB: corruption in the InnoDB tablespace. Please refer to
                            InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
                            InnoDB: about forcing recovery.
                            220822 8:44:18 [ERROR] mysqld got signal 6 ;
                            This could be because you hit a bug. It is also possible that this binary
                            or one of the libraries it was linked against is corrupt, improperly built,
                            or misconfigured. This error can also be caused by malfunctioning hardware.

                            To report this bug, see https://mariadb.com/kb/en/reporting-bugs

                            We will try our best to scrape up some info that will hopefully help
                            diagnose the problem, but since we have already crashed,
                            something is definitely wrong and this may fail.

                            Server version: 10.10.1-MariaDB-log
                            key_buffer_size=134217728
                            read_buffer_size=131072
                            max_used_connections=1
                            max_threads=153
                            thread_count=1
                            It is possible that mysqld could use up to
                            key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 468010 K bytes of memory
                            Hope that's ok; if not, decrease some variables in the equation.

                            Thread pointer: 0x7fab80000c58
                            Attempting backtrace. You can use the following information to find out
                            where mysqld died. If you see no messages after this, something went
                            terribly wrong...
                            stack_bottom = 0x7fabe8134c18 thread_stack 0x49000
                            ??:0(my_print_stacktrace)[0x562ee37b5dbe]
                            ??:0(handle_fatal_signal)[0x562ee32ae1d5]
                            ??:0(restore_rt)[0x7fabf5376cf0]
                            :0(                            GI_raise)[0x7fabf46d1aff]
                            :0(GI_abort)[0x7fabf46a4ea5]
                            ??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x562ee2f17755]
                            ??:0(Wsrep_server_service::log_dummy_write_set(wsrep::client_state&, wsrep::ws_meta const&))[0x562ee2f04408]
                            ??:0(void std::vector<unsigned long, std::allocator<unsigned long> >::M_realloc_insert<unsigned long>(                            gnu_cxx::normal_iterator<unsigned long, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long&&))[0x562ee3724d79]
                            ??:0(void std::vector<unsigned long, std::allocator<unsigned long> >::                            M_realloc_insert<unsigned long>(gnu_cxx::normal_iterator<unsigned long, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long&&))[0x562ee371280f]
                            ??:0(void std::vector<unsigned long, std::allocator<unsigned long> >::M_realloc_insert<unsigned long>(                            gnu_cxx::normal_iterator<unsigned long, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long&&))[0x562ee3716e59]
                            ??:0(void std::vector<unsigned long, std::allocator<unsigned long> >::                            M_realloc_insert<unsigned long>(gnu_cxx::normal_iterator<unsigned long, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long&&))[0x562ee371898e]
                            ??:0(void std::vector<unsigned long, std::allocator<unsigned long> >::M_realloc_insert<unsigned long>(                            gnu_cxx::normal_iterator<unsigned long, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long&&))[0x562ee3718bf5]
                            ??:0(void std::vector<unsigned long, std::allocator<unsigned long> >::                            M_realloc_insert<unsigned long>(gnu_cxx::normal_iterator<unsigned long, std::vector<unsigned long, std::allocator<unsigned long> > >, unsigned long&&))[0x562ee3718d88]
                            ??:0(main)[0x562ee2f79218]
                            ??:0(std::Rb_tree<unsigned int, unsigned int, std::Identity<unsigned int>, std::less<unsigned int>, std::allocator<unsigned int> >::M_erase(std::Rb_tree_node<unsigned int>))[0x562ee366ba7b]
                            ??:0(std::Rb_tree<unsigned int, unsigned int, std::Identity<unsigned int>, std::less<unsigned int>, std::allocator<unsigned int> >::M_erase(std::Rb_tree_node<unsigned int>                            ))[0x562ee366bc6f]
                            ??:0(wsrep_notify_status(wsrep::server_state::state, wsrep::view const))[0x562ee3557058]
                            ??:0(ha_check_and_coalesce_trx_read_only(THD                            , Ha_trx_info, bool))[0x562ee32b2023]
                            ??:0(ha_commit_trans(THD                            , bool))[0x562ee32b3005]
                            ??:0(trans_commit_stmt(THD))[0x562ee319c0a3]
                            ??:0(mysql_execute_command(THD                            , bool))[0x562ee307e371]
                            ??:0(mysql_parse(THD, char, unsigned int, Parser_state))[0x562ee3071822]
                            ??:0(dispatch_command(enum_server_command, THD                            , char, unsigned int, bool))[0x562ee307b708]
                            ??:0(do_command(THD                            , bool))[0x562ee307ce21]
                            ??:0(do_handle_one_connection(CONNECT, bool))[0x562ee318c777]
                            ??:0(handle_one_connection)[0x562ee318cabd]
                            ??:0(MyCTX_nopad::finish(unsigned char                            , unsigned int*))[0x562ee34b20ad]
                            ??:0(start_thread)[0x7fabf536c1ca]
                            :0(                            GI___clone)[0x7fabf46bce73]

                            Trying to get some variables.
                            Some pointers may be invalid and cause the dump to abort.
                            Query (0x7fab80010950): REPLACE INTO ost__search SET object_type='T', object_id=6725, content='Test 55', title='HR305042 Test 55'

                            Connection ID (thread ID): 7
                            Status: NOT_KILLED

                            Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off

                            The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
                            information that should help you find out what is causing the crash.
                            Writing a core file...
                            Working directory at /var/lib/mysql
                            Resource Limits:
                            Limit Soft Limit Hard Limit Units
                            Max cpu time unlimited unlimited seconds
                            Max file size unlimited unlimited bytes
                            Max data size unlimited unlimited bytes
                            Max stack size 8388608 unlimited bytes
                            Max core file size 0 unlimited bytes
                            Max resident set unlimited unlimited bytes
                            Max processes 14776 14776 processes
                            Max open files 32768 32768 files
                            Max locked memory 65536 65536 bytes
                            Max address space unlimited unlimited bytes
                            Max file locks unlimited unlimited locks
                            Max pending signals 14776 14776 signals
                            Max msgqueue size 819200 819200 bytes
                            Max nice priority 0 0
                            Max realtime priority 0 0
                            Max realtime timeout unlimited unlimited us
                            Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e

                            Kernel version: Linux version 4.18.0-408.el8.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 8.5.0 20210514 (Red Hat 8.5.0-14) (GCC)) #1 SMP Mon Jul 18 17:42:52 UTC 2022

                            2022-08-22 8:44:23 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
                            2022-08-22 8:44:23 0 [Note] InnoDB: Number of transaction pools: 1
                            2022-08-22 8:44:23 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
                            2022-08-22 8:44:23 0 [Note] InnoDB: Using Linux native AIO
                            2022-08-22 8:44:23 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
                            2022-08-22 8:44:23 0 [Note] InnoDB: Completed initialization of buffer pool
                            2022-08-22 8:44:23 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes)
                            2022-08-22 8:44:23 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2066992865
                            2022-08-22 8:44:23 0 [Note] InnoDB: Starting final batch to recover 36 pages from redo log.
                            2022-08-22 8:44:23 0 [Note] InnoDB: 128 rollback segments are active.
                            2022-08-22 8:44:23 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
                            2022-08-22 8:44:23 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
                            2022-08-22 8:44:23 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
                            2022-08-22 8:44:23 0 [Note] InnoDB: log sequence number 2066998282; transaction id 4258448
                            2022-08-22 8:44:23 0 [Note] Plugin 'FEEDBACK' is disabled.
                            2022-08-22 8:44:23 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
                            2022-08-22 8:44:23 0 [Note] Server socket created on IP: '127.0.0.1'.
                            2022-08-22 8:44:23 0 [Note] /usr/sbin/mariadbd: ready for connections.
                            Version: '10.10.1-MariaDB-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
                            2022-08-22 8:44:24 0 [Note] InnoDB: Buffer pool(s) load completed at 220822 8:44:24
                            !<

                              Issue resolved, needed to rebuild ost__search table with:

                              ALTER TABLE ost__search ENGINE=InnoDB;

                              For those who may read this for their production environments: Always make a backup first!

                              Write a Reply...