Problem with random generated password in evo-skin

[shanti]

Hi,

we lately found at our server that generating random passwords (email, ftp,...) doesnt work anymore

as soon as clicking the dice-icon , it generates multiple lines of this in error.log

2023:10:20-01:09:24: pid 3628553 killed by signal 11 ()
2023:10:20-01:09:25: pid 3628554 killed by signal 11 ()
2023:10:20-01:09:25: pid 3628563 killed by signal 11 ()

edit: running DA in debug

Last wrote=0 writing remaining 2554 bytes
Just wrote=2554 writing remaining 0 bytes
pid 1688365 killed by signal 11 ()
check_difficult_password('nNPi=f!zUSW1OwqIp'): returned 11: ''
Generate difficult password (try=20): <br>

send_ajax_error(snd, id='(null)', str='(null)', focus='passwd2', error=1)
send_ajax_error(snd, id='passwd_result', str='Vorgaben für schweres Passwort wurden nicht erfüllt.', focus='passwd', error=1)
Command::doCommand(/CMD_AJAX_CHECK_PASSWORD) : finished
Command::run: finished /CMD_AJAX_CHECK_PASSWORD

we cannot find any further clue only its happening since an upgrade to version 1.653

operating difficult_password.php from cli works fine for root and diradmin

php -v

PHP 8.1.23 (cli) (built: Oct 11 2023 02:32:01) (NTS)

directadmin o
version: 1.653
commit sha: ae65930790d34180f07d3bc5d0470b942630aefa
OS slug: linux_amd64
detected OS slug: debian11_amd64
package: directadmin_ae65930790d34180f07d3bc5d0470b942630aefa_linux_amd64.tar.gz
gettext support: yes
gettext path: /usr/local/directadmin/data/lang
eol timestamp: 1788220800
eol time: Sep  1 00:00 2026

massive thankyou for any helpful input
-c-

edit: not a virtual environment
edit: it doesnt matter what skin is in use

 

[shanti]

fixed kindly by @roman from support:

da config-set enforce_difficult_passwords 0

whyever - but that nailed the segvault

 

[fln]

@shanti I do not think disabling the difficult password check is a good solution here. Based from the limited information here I would guess there is some kind if problem that prevents DA from executing PHP scripts. Checking for password being difficult or not is being performed by the scripts/difficult_password.php. If problem is caused by DA not being able to execute PHP scripts this will only hide the problem instead of fixing it.

I have seen similar problems when latest ioncube loaders PHP extension is used in combination with opcache PHP extentions being enabled for CLI scripts. In DA 1.653 we are disabling opcache in CLI mode by default.

A quick check if your system has this issue is trying to execute PHP script by passing its contents to standard input (this is the mode DA executes PHP scripts), with command:

php <<< '<?php echo "hello world\n";'

If it crashes you are most likely using latest ioncube loaders with opcache enabled in CLI mode. If that is the case make sure you have not customizations that would force enable opcache in CLI mode. Defaults comes from /usr/local/directadmin/custombuild/configure/opcache/opcache.ini, make sure you have not customized them by creating /usr/local/directadmin/custombuild/custom/opcache/opcache.ini file.

 

[shanti]

setting this option 0 totally fixed it .. thank you a lot

my best regards