buster's behaviour, in terms of ENV setup differs, when one performs 'su
-' versus 'su root'.

Due to this, 'sbin' paths are not in a 'su root' $PATH.  This means that
this happens, when one does an apt-get upgrade as 'su root':

Restarting services...
 invoke-rc.d ssh restart
Can't exec "invoke-rc.d": No such file or directory at /usr/sbin/needrestart line 1081, <STDIN> line 11.

As well, needrestart doesn't seem to notice the error, and simply
presumes all went well.

Of note is that apt-get is in a normal user's path.  So someone with root
privileges can still run it, even if 'sbin' deriviates aren't in the
path.  In as needrestart is run quite often from apt-get... this does
seem to be an issue.

In as needrestart doesn't flag the error, and also presents a lot of info
to the user, the above error often 'flies' by on the terminal very fast.
The result is that the end-user is left thinking that services have been
restarted, when in fact needrestart did not succeed in doing so.

More than anything, the lack of error catching is what concerns me.

There are more reasons than just 'su - versus su root' where invoke-rc.d
might fail, yet needrestart check for any return code, etc.