The /etc/init.d/asterisk after 23.0 profile profile and changing to merge usr. It started to work again after replacing "/usr/sbin" with "/usr/bin" in the init.d script. I attached copy of the modified file. Reproducible: Always Steps to Reproduce: 1. Update to profile default/linux/amd64/23.0/split-usr/desktop/plasma 2. Change from split usr to merge usr 3. Update to profile default/linux/amd64/23.0/desktop/plasma 4. /etc/init.d/asterisk start Actual Results: Failed to start Expected Results: Not to fail
Created attachment 888345 [details] modified /etc/init.d/asterisk
Hi, Can you please confirm your version of asterisk and asterisk-base? Kind regards, Jaco
# emerge -pv asterisk asterisk-base These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 7.30 s (backtrack: 0/20). [ebuild R ] net-misc/asterisk-21.1.0:0/21::gentoo USE="bluetooth caps iconv ilbc lua speex ssl vorbis -blocks -calendar -cluster -codec2 -curl (-dahdi) -debug -doc -freetds -gtalk -http -ldap -mysql -newt -odbc -pjproject -portaudio -postgres -radius (-selinux) -snmp -span -srtp -static -statsd -systemd -unbound -xmpp" LUA_SINGLE_TARGET="lua5-1 -lua5-3 -lua5-4" VOICEMAIL_STORAGE="-imap -odbc" 0 KiB [ebuild R ] net-misc/asterisk-base-2::gentoo 0 KiB
The ebuild does this: newsbin "${FILESDIR}/asterisk_wrapper-2" asterisk_wrapper So that should be installed in /usr/sbin/ Did you also need to edit asterisk_wrapper to update the path for asterisk binary? Not using merge-usr myself, so please bear with me. Output of the following commands please: which -a asterisk which -a asterisk_wrapper ls -lahd /{usr/,}{s,}bin As I understand /bin, /sbin and one or two others(?) becomes symlinks to /usr/bin and /usr/sbin, but afaik there should be no change w.r.t. bin vs sbin, which is what seems to be happening here.
(In reply to Jaco Kroon from comment #4) > The ebuild does this: > > newsbin "${FILESDIR}/asterisk_wrapper-2" asterisk_wrapper > > So that should be installed in /usr/sbin/ > > Did you also need to edit asterisk_wrapper to update the path for asterisk > binary? > No > Not using merge-usr myself, so please bear with me. > > Output of the following commands please: > > which -a asterisk # which -a asterisk /usr/bin/asterisk > which -a asterisk_wrapper > ls -lahd /{usr/,}{s,}bin # ls -lahd /{usr/,}{s,}bin lrwxrwxrwx 1 root root 7 Mar 24 17:58 /bin -> usr/bin lrwxrwxrwx 1 root root 7 Mar 24 17:58 /sbin -> usr/bin drwxr-xr-x 2 root root 140K Mar 25 10:47 /usr/bin lrwxrwxrwx 1 root root 3 Mar 24 17:58 /usr/sbin -> bin > > As I understand /bin, /sbin and one or two others(?) becomes symlinks to > /usr/bin and /usr/sbin, but afaik there should be no change w.r.t. bin vs > sbin, which is what seems to be happening here. I know. Everything else is running ok.
(In reply to email200202 from comment #5) > (In reply to Jaco Kroon from comment #4) > > Did you also need to edit asterisk_wrapper to update the path for asterisk > > binary? > > > > No OK Good. That leaves more questions than answers in my head, but let's see how we address that. Questions at this stage are good, it gives something to scratch at. Output from: equery files asterisk-base I *suspect* everything that I expect to be /usr/sbin/ will be /usr/bin/ due to the symbolic links. Was there any error output trying to start asterisk with the unedited init script? > > which -a asterisk > > # which -a asterisk > /usr/bin/asterisk OK, I'm assuming /sbin, /bin and /usr/sbin is no longer in $PATH? > > which -a asterisk_wrapper > > ls -lahd /{usr/,}{s,}bin > > # ls -lahd /{usr/,}{s,}bin > lrwxrwxrwx 1 root root 7 Mar 24 17:58 /bin -> usr/bin > lrwxrwxrwx 1 root root 7 Mar 24 17:58 /sbin -> usr/bin > drwxr-xr-x 2 root root 140K Mar 25 10:47 /usr/bin > lrwxrwxrwx 1 root root 3 Mar 24 17:58 /usr/sbin -> bin This confirms the symlinks, I did not expect /usr/sbin to be symlink to bin, but this also implies that any binary that gets referenced as /usr/sbin/whatever which is actually in /usr/bin/whatever should work. You effectively did a search and replace for /usr/sbin/ in the init script and updated to /usr/bin/ - yet, same was not required in asterisk_wrapper. This confuses me, a LOT, since as per above, /usr/sbin/whatever should by implication reference the same thing as /usr/bin/whatever. Let's confirm your shell first (not expecting that this will really reveal something, but you never know): ls -lah /bin/sh; readlink -f /bin/sh I'm wondering if perhaps the shell is being told to NOT follow symlinks during interpretation thus preventing /usr/sbin/asterisk_wrapper from being translated to /usr/bin/asterisk_wrapper ... > > As I understand /bin, /sbin and one or two others(?) becomes symlinks to > > /usr/bin and /usr/sbin, but afaik there should be no change w.r.t. bin vs > > sbin, which is what seems to be happening here. > > I know. Everything else is running ok. I don't see why asterisk should be an exception. What happens with: ls -lahd /usr/sbin/{asterisk,asterisk_wrapper,sendmail} If this all hits executable files I really don't see why the relevant change would be required at all. This could be either my understanding of what's happening that's wrong (I've been dealing with Linux approaching 25 years next year, so I think I've got a fair understanding of symlinks and PATH), or there is some funny symlink protection in the openrc-run "shell" (which I highly doubt), which loops me back to this doesn't make sense, and plainly I'm overlooking something. Can you possibly check the values of: sysctl fs.protected_hardlinks fs.protected_symlinks I'm wondering if ownership of one of more files isn't perhaps causing crap with those settings? Can't see how, as the symlinks aren't towards those binaries/scripts, bur rather the containing folders ...
(In reply to Jaco Kroon from comment #6) > (In reply to email200202 from comment #5) > > (In reply to Jaco Kroon from comment #4) > > > Did you also need to edit asterisk_wrapper to update the path for asterisk > > > binary? > > > > > > > No > > OK Good. That leaves more questions than answers in my head, but let's see > how we address that. Questions at this stage are good, it gives something > to scratch at. > > Output from: equery files asterisk-base > # equery files asterisk-base * Searching for asterisk-base ... * Contents of net-misc/asterisk-base-2: /etc /etc/conf.d /etc/conf.d/asterisk /etc/init.d /etc/init.d/asterisk /etc/logrotate.d /etc/logrotate.d/asterisk /etc/systemd /etc/systemd/system /etc/systemd/system/asterisk.service.d /etc/systemd/system/asterisk.service.d/00gentoo.conf /lib /lib/systemd /lib/systemd/system /lib/systemd/system/asterisk.service /usr /usr/lib /usr/lib/tmpfiles.d /usr/lib/tmpfiles.d/asterisk.conf /usr/sbin /usr/sbin/asterisk_wrapper # ls -l /usr/sbin/asterisk_wrapper -rwxr-xr-x 1 root root 7225 Sep 15 2023 /usr/sbin/asterisk_wrapper # ls -l /usr/bin/asterisk_wrapper -rwxr-xr-x 1 root root 7225 Sep 15 2023 /usr/bin/asterisk_wrapper # ls -ld /usr/sbin/ drwxr-xr-x 2 root root 143360 Mar 25 10:47 /usr/sbin/ # ls -ld /usr/sbin lrwxrwxrwx 1 root root 3 Mar 24 17:58 /usr/sbin -> bin > I *suspect* everything that I expect to be /usr/sbin/ will be /usr/bin/ due > to the symbolic links. > > Was there any error output trying to start asterisk with the unedited init > script? > Just the message "ERROR: asterisk failed to start". > > > > which -a asterisk > > > > # which -a asterisk > > /usr/bin/asterisk > > OK, I'm assuming /sbin, /bin and /usr/sbin is no longer in $PATH? No # echo $PATH /usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/18/bin:/usr/lib/llvm/17/bin:/usr/lib64/subversion/bin:/etc/eselect/wine/bin:/opt/Android/Sdk/platform-tools/:/opt/basex/bin:/opt/cgtkcalc:/root/bin: > > > > which -a asterisk_wrapper > > > ls -lahd /{usr/,}{s,}bin > > > > # ls -lahd /{usr/,}{s,}bin > > lrwxrwxrwx 1 root root 7 Mar 24 17:58 /bin -> usr/bin > > lrwxrwxrwx 1 root root 7 Mar 24 17:58 /sbin -> usr/bin > > drwxr-xr-x 2 root root 140K Mar 25 10:47 /usr/bin > > lrwxrwxrwx 1 root root 3 Mar 24 17:58 /usr/sbin -> bin > > This confirms the symlinks, I did not expect /usr/sbin to be symlink to bin, > but this also implies that any binary that gets referenced as > /usr/sbin/whatever which is actually in /usr/bin/whatever should work. > > You effectively did a search and replace for /usr/sbin/ in the init script > and updated to /usr/bin/ - yet, same was not required in asterisk_wrapper. > This confuses me, a LOT, since as per above, /usr/sbin/whatever should by > implication reference the same thing as /usr/bin/whatever. > > Let's confirm your shell first (not expecting that this will really reveal > something, but you never know): > > ls -lah /bin/sh; readlink -f /bin/sh > # ls -lah /bin/sh; readlink -f /bin/sh lrwxrwxrwx 1 root root 4 Mar 24 17:58 /bin/sh -> bash /usr/bin/bash > I'm wondering if perhaps the shell is being told to NOT follow symlinks > during interpretation thus preventing /usr/sbin/asterisk_wrapper from being > translated to /usr/bin/asterisk_wrapper ... > It looks like it follow the symlink # /usr/sbin/asterisk_wrapper Initializing asterisk_wrapper Waiting for inactivity to perform halt > > > As I understand /bin, /sbin and one or two others(?) becomes symlinks to > > > /usr/bin and /usr/sbin, but afaik there should be no change w.r.t. bin vs > > > sbin, which is what seems to be happening here. > > > > I know. Everything else is running ok. > > I don't see why asterisk should be an exception. > > What happens with: > > ls -lahd /usr/sbin/{asterisk,asterisk_wrapper,sendmail} > # ls -lahd /usr/sbin/{asterisk,asterisk_wrapper,sendmail} -rwxr-xr-x 1 root root 2.9M Feb 7 14:36 /usr/sbin/asterisk -rwxr-xr-x 1 root root 7.1K Sep 15 2023 /usr/sbin/asterisk_wrapper -rwxr-xr-x 1 root root 36K May 15 2022 /usr/sbin/sendmail > If this all hits executable files I really don't see why the relevant change > would be required at all. This could be either my understanding of what's > happening that's wrong (I've been dealing with Linux approaching 25 years > next year, so I think I've got a fair understanding of symlinks and PATH), > or there is some funny symlink protection in the openrc-run "shell" (which I > highly doubt), which loops me back to this doesn't make sense, and plainly > I'm overlooking something. > > Can you possibly check the values of: > > sysctl fs.protected_hardlinks fs.protected_symlinks > # sysctl fs.protected_hardlinks fs.protected_symlinks fs.protected_hardlinks = 1 fs.protected_symlinks = 1 > I'm wondering if ownership of one of more files isn't perhaps causing crap > with those settings? Can't see how, as the symlinks aren't towards those > binaries/scripts, bur rather the containing folders ...
The problem is in is_running() function is_running() { [ -r "${ast_rundir}/asterisk.pid" ] || return 1 PID="$(cat "${ast_rundir}/asterisk.pid")" [ -d "/proc/${PID}" ] || return 1 EXE="$(readlink -f /proc/${PID}/exe)" EXE="${EXE% (deleted)}" # in case asterisk got upgraded and we're still looking at an old one. [ "${EXE}" = /usr/sbin/asterisk ] || return 1 # pid got re-used for another process. # PID reported in pidfile is active, and is still an asterisk instance. return 0 } The variable ${EXE} is assigned value "/usr/bin/asterisk" by the command readlink -f /proc/${PID}/exe. This causes the condition [ "${EXE}" = /usr/sbin/asterisk ] to fail The condition should be modified to : [ "${EXE}" = /usr/bin/asterisk ] || [ "${EXE}" = /usr/sbin/asterisk ] || return 1 I tested it and it works.
Created attachment 888536 [details, diff] usr-merge.patch
YES!!!!!!!!!!! Good spot. > The condition should be modified to : > > [ "${EXE}" = /usr/bin/asterisk ] || [ "${EXE}" = /usr/sbin/asterisk ] || > return 1 > > I tested it and it works. Alternatively, would you mind testing: [ "${EXE}" = "$(readlink -f /usr/sbin/asterisk)" ] This avoids a very unlikely but possible issue on split-usr where /usr/bin/asterisk is something other than the correct asterisk :). Of course any kind of readlink related stories has symlink race conditions, so perhaps your variant is better, let me confirm with core devs what would be preferable. At least I see I covered the "upgrade" variation of the same problem where /proc/${pid}/exe has " (deleted)" in the name.
# readlink -f /usr/sbin/asterisk /usr/bin/asterisk
(In reply to email200202 from comment #11) > # readlink -f /usr/sbin/asterisk > /usr/bin/asterisk I knew this was going to be the case, but instead of doing a long || chain like "[ ... ] || [ ... ] || return 1" I was thinking rather to: [ "${EXE}" = "$(readlink -f /usr/sbin/asterisk)" ] || return 1 Keeping in mind if the {/usr,}/{s,}bin links change we're back in the same boat, and it gets harder to read the longer that chain becomes. Waiting on feedback from core dev.
>Alternatively, would you mind testing: > >[ "${EXE}" = "$(readlink -f /usr/sbin/asterisk)" ] It works. What will happen if the /usr/sbin/ link is removed in the future.
(In reply to email200202 from comment #13) > >Alternatively, would you mind testing: > > > >[ "${EXE}" = "$(readlink -f /usr/sbin/asterisk)" ] > > It works. > > What will happen if the /usr/sbin/ link is removed in the future. Thanks! I suspect it can't go away until dosbin is dead, and I believe the reality is that split-usr as a whole is unlikely to completely go away any time soon (there are stalwarts like myself that insist on at least having some basic tools working even with just / mounted without /usr, but to be honest, this is becoming harder and harder every year).
Opted to go with your approach. PR created.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fb9136bf44fa3b159042598a7cb90d861e2f0be3 commit fb9136bf44fa3b159042598a7cb90d861e2f0be3 Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2024-03-26 10:23:32 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2024-04-21 13:17:54 +0000 net-misc/asterisk-base: add 3 Minor change to init script to accomodate merged-usr. A few other changes as suggested by Michał, including externalizing the codebase into it's own package (now at https://github.com/jkroonza/asterisk-base). Closes: https://github.com/gentoo/gentoo/pull/35925 Closes: https://bugs.gentoo.org/927663 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Signed-off-by: Michael Orlitzky <mjo@gentoo.org> net-misc/asterisk-base/Manifest | 1 + net-misc/asterisk-base/asterisk-base-3.ebuild | 39 +++++++++++++++++++++++++++ net-misc/asterisk-base/metadata.xml | 3 +++ 3 files changed, 43 insertions(+)
