FreeBSD equivalent of Linux tail -f /proc/{PID}/fd/1

[hulleyrob]

trying to see what is going to stdout of a running python process.

Whats command or package is the best way to do this?

I did see a stack overflow post saying do x but cannot find it again.

Any help or ideas appreaciated.

Thanks
Rob

 

[Argentum]

trying to see what is going to stdout of a running python process.

Whats command or package is the best way to do this?

I did see a stack overflow post saying do x but cannot find it again.

Any help or ideas appreaciated.

With FreeBSD you can have /proc mounted by putting the following line in /etc/fstab

proc                    /proc           procfs  rw              0       0

procfs(5)

 

[covacat]

ktrace, truss and friends works as an emergency solution

 

[grahamperrin]

Also devel/linux-c7-strace

% strace
strace: Command not found.
% pkg info --list linux-c7-strace | grep bin/
        /compat/linux/usr/bin/strace
        /compat/linux/usr/bin/strace-log-merge
%

FreeBSD bug 259029 – devel/linux-c7-strace no manual entry for strace

 

[hulleyrob]

Argentum thanks I did that but it doesn't use the file descriptors in the same way as linux unfortunately.

covacat I had little success trying to trace the pid to get the stdout of in this case a python script running via cron

grahamperrin that was a bust due to "kernel missing 64-bit Linux support"

Any other ideas?

 

[SirDice]

to get the stdout of in this case a python script running via cron

Look in the mail of the user that ran that cron. Any output of a cron job is mailed to the user that ran it.

 

[hulleyrob]

no messages for root or the account that ran the cron

 

[SirDice]

Is the output redirected to /dev/null perhaps? Then just redirect it to a log file instead.

0 * * * * mycommand > /var/log/mycommand.log

Note I specifically don't redirect stderr in cronjobs. Because I want to get notified if there are errors, those errors will then get mailed.

 

[hulleyrob]

Is the output redirected to /dev/null perhaps? Then just redirect it to a log file instead.

yeah I think your right. the thing is I have the same script running on a raspberry pi and was just able to tail the file descriptor. ive been trying to do the same with the script on freebsd on and off over the weekend to no avail.

I dont really want to manage a log file for this script. but on the very odd occasion something goes wrong being able to do the equivalent of tailing the file descriptor would help me easily solve any problems.

 

[SirDice]

I dont really want to manage a log file for this script.

It depends on how things are set up. For debugging purposes just redirect it to a file. Then you'll know what it does. Once you figure out what's wrong with it and fixed it you can redirect it back to /dev/null again.

Or use > instead of >>, the first will create a new file with every run, the second will append to the log file (which could then grow unintentionally large, but you could manage that with newsyslog(8) for example).

 

[hulleyrob]

thanks will take a look, ive used log rotate for this before but it really doesn't need to be outputting all that junk unless there is a problem.

The > might work however this is a 1 minute cron that fires up checks for a pidlock for its own process then either exits or does what it is meant to do depending on some other factors so im not sure I would see the file before its overwritten which is why im trying to see what the last x lines of stdout were for that process. it seems it is much more difficult than on the pi.

 

[SirDice]

but it really doesn't need to be outputting all that junk unless there is a problem.

That why you should first make sure the script itself doesn't output anything unless there is a problem. Problems should be printed to stderr.

it seems it is much more difficult than on the pi.

The hardware it runs on is irrelevant. It's a cronjob running on FreeBSD. That works the same on any version and any architecture.

However, you are mentioning a one minute interval, the Pi is a rather slow device, so it's possible your one minute cronjob might actually run for longer than a minute. And that might cause it to run multiple times concurrently (which could be the reason for the PID file contention).

 

[Argentum]

thanks will take a look, ive used log rotate for this before but it really doesn't need to be outputting all that junk unless there is a problem.

The > might work however this is a 1 minute cron that fires up checks for a pidlock for its own process then either exits or does what it is meant to do depending on some other factors so im not sure I would see the file before its overwritten which is why im trying to see what the last x lines of stdout were for that process. it seems it is much more difficult than on the pi.

I have also used | logger in crontab. See logger(1). That will write the output to system log. Usually logs are rotated anyway.

 

[hulleyrob]

interesting idea, thanks might give that a go