Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stderr being printed out for Rex::Service instead of captured for $running_upstart #1612

Open
VVelox opened this issue Jan 23, 2024 · 1 comment
Labels
bug Confirmed bugs

Comments

@VVelox
Copy link
Contributor

VVelox commented Jan 23, 2024

Describe the bug

sh: initctl: not found gets printed out any time Rex::Service->get is called.

Expected behavior

Redirects stderr to stdout to avoid

How to reproduce it

perl -e 'use Rex::Commands::Service; service snmpd=>"start";'
sh: initctl: not found
sh: initctl: not found
[2024-01-22 22:37:29] INFO - Service snmpd started.

Code example

use Rex::Commands::Service;
service snmpd=>"start";

Additional context

So looks like Rex::Commands::Service->service calls Rex::Service->get to get the object to use for it. When this happen a bit of code is ran to test for OS and if initctl and systemctl are usable.

I am lost as to why the systemctl check does not also do it.

Likely the best option here is to add which initctl > /dev/null && before it and likely do the same with systemctl as well.

[root@nibbles0]1|/src/ports/head>which initctl > /dev/null && echo test
[root@nibbles0]1|/src/ports/head>which ls > /dev/null && echo test     
test
[root@nibbles0]0|/src/ports/head>

Double check to make sure this issue is not caused by how it is being packaged and when reinstalled via cpanm --reinstall Rex the same thing happens.

Rex version

1.14.3

Perl version

v5.36.3

Operating system running rex

FreeBSD nibbles0.vulpes.vvelox.net 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC amd64

Operating system managed by rex

FreeBSD and Linux

How rex was installed?

package manager

@VVelox VVelox added the triage needed A potential bug that needs to be reproduced and understood label Jan 23, 2024
@ferki
Copy link
Member

ferki commented May 12, 2024

Thanks for the report!

TL;DR

Using service and any other Rex commands outside a task is curious, although I could also reproduce it in a task. I believe it boils down to how Rex is assumed to handle STDERR/STDOUT of commands in different cases.

Could you try your use case with use Rex -feature => [ 'no_tty' ];, please?

Longer version

Handling the STDERR and STDOUT of commands largely depends on the circumstances.

Rex historically used to allocate a tty when executing commands, and over time that proved to be largely incompatible with many environment.

To keep backwards compatibility with existing code, the no_tty feature flag was introduced to disable allocating a tty.

This is also the default behavior when the 1.0 or later feature flag bundle is enabled.

See the documentation of Feature flags for more details.

Most feature flags map to corresponding Rex::Config options, and you may prefer setting set_no_tty directly like Rex::Config->set_no_tty(1); instead, depending on your use case.

For reference, I recommend using use Rex -feature => [ '1.4', 'exec_autodie' ]; as a general starting point for any project.

@ferki ferki added bug Confirmed bugs and removed triage needed A potential bug that needs to be reproduced and understood labels May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bugs
Projects
None yet
Development

No branches or pull requests

2 participants