I'm testing the communication between node.js and executables launched as child processes. An executable will be launched from within node.js via child_process.spawn() and its output will be monitored by node.js. I'm testing this capability both on Linux and Windows OSs.
I've successfully spawned tail -f /var/log/syslog and listened to its output, but my own executables can't seem to write correctly to stdout (in whatever form it exists when captured by node.js).
Test code:
#include <iostream>
#include <stdio.h>
#include <unistd.h>
int main()
{
using namespace std;
long x = 1;
while (true)
{
fprintf(stdout, "xtime - %ld\n", x++);
usleep(1000000);
}
}
(Note: some includes may be useless; I've not checked them)
stdout output is not automatically flushed (at least on *nix) when stdout is not a tty (even if there is a newline in the output, otherwise a newline generally flushes when stdout is a tty).
So you can either disable stdout buffering entirely via setbuf(stdout, NULL); or you can manually flush output via fflush(stdout);.
Related
I am logging a user that is login to a linux system at an interval of 1-minute. The logging will be done using an init.d script owned by root and it auto start at bootup.
I tried using getlogin() and getlogin_r() with a simple init.d script. However, it will work if I run the init.d script via console but when I register the init.d script via chkconfig --add [initscript] and reboot the system, it runs as check via ps -ef but when I checked the log file, the username is empty.
Did I miss something? Is their an alternative approach of getting the login user?
getlogin() returns a pointer to a string containing the name of the user logged in on the controlling terminal of the process, or a null pointer if this information cannot be determined.
A script run through init does not have a controlling terminal. Whereas, if you run a script via console, the console is the controlling (virtual) terminal.
getlogin() does not do what you want to do. I assume you should have a look for users and who commands.
#ypnos,
I did not bother to check the who.c you provided from the link github.com/coreutils/coreutils/blob/master/src/who.c.
I did a different approach from the code snippet below.
#include <stdio.h>
#include <utmpx.h>
#include <time.h>
int main (void)
{
struct utmpx *UtmpxPtr = NULL;
struct tm *TimePtr = NULL;
time_t TimeInSec;
char TimeBuff[32];
printf("...Start \"who logged-in\"...\n");
setutxent();
while ((UtmpxPtr = getutxent()) != NULL)
{
if (UtmpxPtr->ut_type != USER_PROCESS)
{
continue;
}
TimeInSec = UtmpxPtr->ut_tv.tv_sec;
TimePtr = localtime(&TimeInSec);
strftime(TimeBuff, sizeof(TimeBuff), "%Y-%m-%d|%H:%M", TimePtr);
printf("%s|%s|%s\n", UtmpxPtr->ut_user, TimeBuff, UtmpxPtr->ut_host);
fflush(stdout);
}
endutxent();
return 0;
}
How can I get current working directory in strace output, for system calls that are being called with relative paths? I'm trying to debug complex application that spawns multiple processes and fails to open particular file.
stat("some_file", 0x7fff6b313df0) = -1 ENOENT (No such file or directory)
Since some_file exists I believe that its located in the wrong directory. I'd tried to trace chdir calls too, but since output is interleaved its hard to deduce working directory that way. Is there a better way?
You can use the -y option and it will print the full path. Another useful flag in this situation is -P which only traces syscalls relating to a specific path, e.g.
strace -y -P "some_file"
Unfortunately -y will only print the path of file descriptors, and since your call doesn't load any it doesn't have one. A possible workaround is to interrupt the process when that syscall is run in a debugger, then you can get its working directory by inspecting /proc/<PID>/cwd. Something like this (totally untested!)
gdb --args strace -P "some_file" -e inject=open:signal=SIGSEGV
Or you may be able to use a conditional breakpoint. Something like this should work, but I had difficulty with getting GDB to follow child processes after a fork. If you only have one process it should be fine I think.
gdb your_program
break open if $_streq((char*)$rdi, "some_file")
run
print getpid()
It is quite easy, use the function char *realpath(const char *path, char *resolved_path) for the current directory.
This is my example:
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
int main(){
char *abs;
abs = realpath(".", NULL);
printf("%s\n", abs);
return 0;
}
output
root#ubuntu1504:~/patches_power_spec# pwd
/root/patches_power_spec
root#ubuntu1504:~/patches_power_spec# ./a.out
/root/patches_power_spec
I am using x86_64 GNU/Linux with bash
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
system("set > setc"); // A subset of `$ set`
return 0;
}
I can see the file setc contains a subset of $ set.
I am feeling curious as to know how the shell (parent process) decides what to supply to child process and what not to?
What if I want to supply more environ variables to child process? How one can control that?
A shell variable can be either exported or not exported. The shell will only pass exported variables to child processes. In bash, you can export a variable(for example, $var) by executing export var.
My OS Ubuntu 12.04. I wrote this Kernel Module and i use insmod and rmmod command but there isn't anything in /var/log messages. how can i fix this problem?
/*
* hello-1.c - The simplest kernel module.
*/
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
int init_module(void)
{
printk(KERN_INFO "Hello world 1.\n");
/*
* A non 0 return means init_module failed; module can't be loaded.
*/
return 0;
}
void cleanup_module(void)
{
printk(KERN_INFO "Goodbye world 1.\n");
}
Check whether syslog daemon process is running, since this is the process which copies printk messages from kernel ring/log message buffer to /var/log/messages if I am correct. printk messages can be seen using dmesg utility/command or messages will be in /var/log/messages. If correct loglevel is set then printk messages will be displayed on the console right away, no need to use dmesg or no need to check in /var/log/messages. printk debug messages can also be part of /var/log/syslog.
Modern Linux distributions don't use rsyslog (or any other syslog daemon) anymore. They rely on journald which is part of systemd, so the /var/log/messages file is missing and you have to use the journalctl command to read the system log.
Firstly, you should check that whether your module is properly loaded or not, by using this command
lsmod | grep "hello-1" //hello-1 is the name of your module
Since you wrote a kernel module, which prints some message. The messages from kernel and its module can be found in /var/log/syslog or you can view these kind of messages using dmesg command.
As your module prints "Hello World 1.", you should use following command to see message from your module.
dmesg | grep "Hello World 1."
Look for this in /etc/syslog.conf, the *.info... lines. These seem to control what gets logged via printk.
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
I found that /proc/sys/kernel/printk only really controlled the console logging levels, not the logging to the file. And I guess check syslog is running too ;) We had exactly the same issue, KERN_INFO not going to log files and this fixed it. hth
I tried to print the kernel buffer by typing the following command :
dmesg
This will print the data written in printk
Environment:
Ubuntu 10.04 LTS
Gnome Desktop v2.30.2
gcc/g++ 4.4.3
libreadline 6.1
I was building an application that inputs a multiple line of input and process for it and I found that if the size of input is large, readline skips several bytes of characters. To make sure, I made a simple program like this:
#include <stdio.h>
#include <readline/readline.h>
int main() {
while (1) {
char *p = readline("> ");
if (!p) break;
fprintf(stderr, "%s\n", p);
}
return 0;
}
and generated 20000 lines of input, which consists of 120000 bytes.
seq -f "%05g" 1 20000 >gen.txt
and ran the test program on gnome terminal and performed copy-and-paste of the content of gen.txt:
g++ test.cpp -lreadline
./a.out 2>out.txt
[copy-and-paste the content of gen.txt]
I could see that out.txt was smaller than gen.txt, and many bytes are omitted.
wc -c out.txt
119966 out.txt
I want to know which component is flawed, whether gnome terminal or readline, and want to know how many bytes of clipboard content readline and gnome terminal assure that copy-and-paste can be done in that amount without problem.