Sometimes just after I do "su - nobody", I get instantly logged back out. It's like I accidentally sent a ^D to the shell. At first I thought it might be my emacs shell buffer sending junk, but it happens in xterm too. And it happens or doesn't happen without any pattern as to when. And there's nothing funny in /var/log/auth.log. Sorry if you can't reproduce it. Just wanted to let you know. Below we see one bad and two goods. # su - nobody No directory, logging in with HOME=/ nobody@jidanni1:/$ logout <--------------I did not type this. 17:02 ~# su -l nobody No directory, logging in with HOME=/ nobody@jidanni1:/$ exit logout 17:02 ~# su -l nobody No directory, logging in with HOME=/ nobody@jidanni1:/$ exit logout Yes, I typed the "exit"s. -l or - have the same probability. Maybe there's a race condition that sometimes kills such a shell?
tags 476519 unreproducible thanks Hello, I could not reproduce it in my terminals, even in a few 1000s of tries. Could you try with the attached expect script? Best Regards,
Thanks, I tried your script with PS1=#\ ENV= HOME=/tmp ./test.exp but for 20 instead of 2000 passes, but didn't trigger the bug. Maybe there are some bugs expect(1) cannot trigger like real users. Yes it is a mystery to me.
Do you have any signal handling customization in your shell rc files? What does stty -a say (I'm thinking of tostop)?
speed 38400 baud; rows 39; columns 111; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke # trap # Plus su - nobody shouldn't read any rc files, as nobody has no home directory to put them. In /var/log/auth.log, note the seconds: Apr 17 20:36:30 jidanni1 su[11105]: Successful su for nobody by root Apr 17 20:36:30 jidanni1 su[11105]: + pts/1 root:nobody Apr 17 20:36:30 jidanni1 su[11105]: pam_unix(su:session): session opened for user nobody by jidanni(uid=0) Apr 17 20:36:30 jidanni1 su[11105]: pam_unix(su:session): session closed for user nobody Apr 17 20:36:33 jidanni1 su[11109]: Successful su for nobody by root Apr 17 20:36:33 jidanni1 su[11109]: + pts/1 root:nobody Apr 17 20:36:33 jidanni1 su[11109]: pam_unix(su:session): session opened for user nobody by jidanni(uid=0) Apr 17 20:36:34 jidanni1 su[11109]: pam_unix(su:session): session closed for user nobody Here we see me getting logged off the same second I login -- bad. Then three seconds later I hit ^P RET and one second after that ^D -- normal.
I could not reproduce it when run by hand neither. Could you reproduce it with another user? Could you reproduce it with another terminal (console)? Are you using special PAM modules? You mentioned no messages in /var/log/auth.log, are there messages in /var/log/syslog? What's your probability of occurrence? (1 out of 3?) Can you try to get a systrace of su when it fails and compare it with a successful session.
Holy moly, I can reproduce that. I apologize to emacs & co. It is a su bug. Dear http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476519 team: please see http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-04/msg00080.html First fix that and then maybe 476519 will get fixed in the process. Regarding 476519: NF> Could you reproduce it with another user? No, but yes with the "e" bug. NF> Could you reproduce it with another terminal (console)? tty1: no, but didn't try hard. "e" bug: yes. NF> Are you using special PAM modules? I don't know, I just installed vanilla sid several years ago and don't play around with the advanced parts. NF> You mentioned no messages in /var/log/auth.log, Just the normal ones I posted. On a different machine I get pam_env(su:session): Unable to open env file: /etc/environment: No such file or directory but that doesn't affect if the bug occurs or not. NF> are there messages in /var/log/syslog? No. NF> What's your probability of occurrence? (1 out of 3?) Seems to come in clumps... maybe 5 bads in a row, then good until close the shell window. But not always. Or bad to nobody, good to user2, then bad to nobody. NF> Can you try to get a systrace of su when it fails and compare it with a NF> successful session. If you mean strace, well, whenever I try it the bug doesn't occur, under strace. Anyway, fix the "e" bug and maybe 476519 will get fixed in the process. Actually, it's the first character typed, and not just "e".
Hello, I can't reproduce it neither with emacs nor the "first character" bug. Another idea: What is the shell used by root or by nobody once logged in (echo $SHELL), and what's the default shell on the system?
Sven, can you help out with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476519 I am "out of the office" this week.
I've played a bit around with this bug. Meanwhile bash got upgraded to 3.2 and behaves somewhat differently: when logging in as root on the console and typing "su - nobody", nobody is immediately logged out on the first keystroke, as if C-d had been typed. However, I could not reproduce it after moving /root/.bashrc out of the way. I figured out that sourcing /etc/bash_completion triggers the problem with the following minimal /root/.profile and no /root/.bashrc:
As http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476519 says, maybe it is a bash bug: with Debian sid's BASH_VERSION=3.2.33(1)-release about half the time the below works normally, the other half some magic hand sends "exit" to it, logging me out right away. The first letter of which gets bitten off or something, here in an emacs shell window: 03:44 ~# env - su - nobody bash: xit: command not found (I do not have the bash-completion package installed, as per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468858 )
Try
sudo env -i SHELLOPTS=xtrace su -p - nobody
nobody's shell is sh (being bash) or bash, right?
$ getent passwd nobody
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
$ dpkg -S "$(command -v su)"
login: /bin/su
Which su is your su? Is it using PAM?
$ ldd /bin/su
linux-gate.so.1 => (0xb8021000)
libpam.so.0 => /lib/libpam.so.0 (0xb7fed000)
libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7fea000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7e9c000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7e98000)
/lib/ld-linux.so.2 (0xb8022000)
$ grep '^[^#]' /etc/pam.d/su
auth sufficient pam_rootok.so
session required pam_env.so readenv=1
session required pam_env.so readenv=1 envfile=/etc/default/locale
session optional pam_mail.so nopen
@include common-auth
@include common-account
@include common-session
(also check the included files).
SC> Try SC> sudo env -i SHELLOPTS=xtrace su -p - nobody (I don't use sudo) uid=0(root) gid=0(root) groups=0(root) # env -i SHELLOPTS=xtrace su -p - nobody + PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games + '[' /bin/sh ']' + PS1='\u@\h:\w\$ ' + export PATH + umask 022 nobody@jidanni2:/root$ kill -1 $$ + kill -1 6215 # env -i SHELLOPTS=xtrace su -p - nobody + PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games + '[' /bin/sh ']' + PS1='\u@\h:\w\$ ' + export PATH + umask 022 nobody@jidanni2:/root$ logout # Above on my first attempt the shell stayed alive, so I typed kill -1 $$ (instead of exit, so it would be clear that I typed it, as that is something the "magic hand" never uses.) On the second and later attempts, some magic hand typed "logout" for me. The magic hand also sometimes types "exit"... SC> nobody's shell is sh (being bash) or bash, right? SC> $ getent passwd nobody SC> nobody:x:65534:65534:nobody:/nonexistent:/bin/sh Same here. SC> $ dpkg -S "$(command -v su)" SC> login: /bin/su Same here. $ ls -og /bin/sh lrwxrwxrwx 1 4 2008-04-29 07:04 /bin/sh -> bash SC> Which su is your su? Is it using PAM? SC> $ ldd /bin/su same here except for the hex numbers. SC> $ grep '^[^#]' /etc/pam.d/su Same here. SC> (also check the included files). Never touched them. $ cd /etc/pam.d&&find * -atime -1 -type f|xargs ls -og -rw-r--r-- 1 392 2005-07-26 16:48 common-account -rw-r--r-- 1 436 2005-07-26 16:48 common-auth -rw-r--r-- 1 1097 2005-07-26 16:48 common-password -rw-r--r-- 1 372 2005-07-26 16:48 common-session -rw-r--r-- 1 289 2005-07-05 22:45 cron -rw-r--r-- 1 2843 2006-09-17 15:22 login -rw-r--r-- 1 520 2003-09-01 06:21 other -rw-r--r-- 1 2305 2006-07-14 19:05 su -rw-r--r-- 1 289 2007-08-13 23:54 xdm The only thing I tampered with is probably just making a $ ls -og /etc/environment -rw-r--r-- 1 0 2008-05-02 03:37 /etc/environment to stop the warning in /var/log/auth.log if it is absent. The pam stuff came with my Debian sid installation and apt-get says removing it "should NOT be done unless you know exactly what you are doing!" i.e., not me, so I dare not touch it.
[...] Does that happen straight away or after a delay? The "logout" thing looks a bit like eof from the terminal. It could be the "read" being interupted by a signal or something like that. strace would probably help then: sudo env -i strace -vfo /tmp/strace.out /bin/su - nobody And look at the last read(0 in /tmp/strace.out It could be worth checking the ulimits as well.
[...] Could be a tty setting as well. stty min 0 time 10 -icanon could reproduce that if bash was built without readline I think. With readline, bash is meant to reset those min and time parameters before each prompt. Maybe it fails to do so in which case strace will tell you as well. What does stty -a tell you?
Here we see the typical deal. You asked me about ulimit. I tried to get a shell oh, six times this time before the magic hand stopped logging me out. Whereupon it bites off the first character of what I type and logs me out, saving the message for after the next prompt. Then I get a shell again to give you the answer. # su - nobody No directory, logging in with HOME=/ nobody@jidanni2:/$ logout # su - nobody No directory, logging in with HOME=/ nobody@jidanni2:/$ logout # su - nobody No directory, logging in with HOME=/ nobody@jidanni2:/$ logout # su - nobody No directory, logging in with HOME=/ nobody@jidanni2:/$ logout # su - nobody No directory, logging in with HOME=/ nobody@jidanni2:/$ logout # su - nobody No directory, logging in with HOME=/ nobody@jidanni2:/$ ulimit logout # su - nobody bash: limit: command not found # No directory, logging in with HOME=/ nobody@jidanni2:/$ ulimit unlimited nobody@jidanni2:/$ stty speed 38400 baud; line = 0; erase = <undef>; kill = <undef>; -brkint -imaxbel -onlcr -echo Happens also in xterm, where # stty speed 38400 baud; line = 0; -brkint -imaxbel iutf8 SC> Does that happen straight away or after a delay? The logout happens instantaneously, no waiting for me to type my first command as nobody. SC> The "logout" thing looks a bit like eof from the terminal. Very much so. SC> strace would probably help then: No. Every time I use strace I get a shell that sticks around. The bug is not triggered. I'll send you one anyway. SC> And look at the last read(0 in /tmp/strace.out SC> Could be a tty setting as well. SC> stty min 0 time 10 -icanon Ho ho ho, that even eats through all the shells stacked up in my emacs shell buffer exiting each one. SC> With readline Has readline. I'll send you shopt output.
Stephane Chazelas wrote: [...] You beat met to it. :-) Does this happen only in an emacs shell-mode window? If that is the case, then readline doesn't enter into the picture -- bash disables line editing when it can tell it's being run by emacs -- and uses read(2). read can return failure right away (-1/EAGAIN) or 0 (no data available) if it's called with the tty in non-canonical mode and those tty settings. Either value will be translated to EOF and cause the shell to exit. Chet
CR> Does this happen only in an emacs shell-mode window? No. It happens also in xterm. Today it at least allowed me to do -c date. I did not type exit or logout. The magic hand did. # su - nobody -c date No directory, logging in with HOME=/ Sat May 3 01:03:10 CST 2008 # su - nobody -c 'sh -i' No directory, logging in with HOME=/ sh-3.2$ exit # su - nobody No directory, logging in with HOME=/ nobody@jidanni2:/$ logout #
[..] Could you try ulimit -a? Have you got a lot of processes running as "nobody"? $ ps -fjlLunobody $ sudo lsof -u nobody Or maybe it could be "su" that exits and bash gets killed because it is orphaned or something like that? Too many processes running as root? You would see other problems. Could be the number of open files by the process. Do you get it from the Linux console (emacs -nw)? Have you tried changing nobody's shell?
jidanni@jidanni.org wrote: FWIW, I can't reproduce this on Fedora 8, the version of Linux I have available. This really looks like a terminal process group problem -- read will return -1/EIO if the process doing the read isn't in the same process group as the terminal and the process is blocking SIGTTIN, which interactve shells do by default. Does su do anything with process groups? Chet
SC> Could you try ulimit -a? # su - nobody -c ulimit\ -a|grep -v unlimited core file size (blocks, -c) 0 scheduling priority (-e) 0 pending signals (-i) 1791 max locked memory (kbytes, -l) 32 open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 max user processes (-u) 1791 No directory, logging in with HOME=/ # ps -fjlLunobody; lsof -u nobody both show nothing. No lots of processes for me. SC> Do you get it from the Linux console (emacs -nw)? Yes, just tired it in emacs -nw -f shell and after 10 good logins I got a bad one. SC> Have you tried changing nobody's shell? I don't want to. CR> Does su do anything with process groups? That is an advanced question not for little me. Anyway, the only other human to have reproduced any of this mess is http://bugs.debian.org/476519#52 Nobody :-) has responded to the points of that message #52.
On Sun, May 04, 2008 at 10:14:26AM +0800, jidanni@jidanni.org wrote: [...] Then, can you try: su - nobody -c ksh su - nobody -c pdksh su - nobody -c zsh Also, what about: perl -e '$<=$>=$(=$)=65534; exec sh' perl -e '$<=$>=$(=$)=65534; system sh' Not as far as the strace output can tell. The poster seems to say that what makes a difference is what *root* does before calling su. That would be /etc/bash_completion? Not sure how what bash_completion does could have an impact on su. You've already ruled out the environment by running "env -i", you could check the open files with lsof -p "$$", you've already checked stty -a. You could try running ps to see if it left some processes running behind. I see "mesg n" in Sven's post. That command is meant to change the tty permissions to allow writes to the owner only, in that case root, but I can't see how that could affect nobody's sh. For sh to get a SIGTTIN upon the "read", it would have not to be in the foreground process group of the terminal. bash does put itself in the foreground process group by a: ioctl(255, TIOCSPGRP, getpid()) 255 being a dup(dup(2)). And it reads from 0. So one way to get that behavior could be if stderr is redirected to a different terminal as stdin... seems like a bit far fetched. running out of ideas here...
All I have installed else is dash: 4 successes 0 failures.
SC> perl -e '$<=$>=$(=$)=65534; exec sh'
That gets a shell without triggering the error.
SC> perl -e '$<=$>=$(=$)=65534; system sh'
That filled emacs with \377's with luckily a little CPU left over that
I could kill emacs... *
SC> Not sure how what bash_completion does could have an impact on su.
I observed the bug with and without the bash-completion package installed.
# lsof -p $$|wc -l
18
pstree shows no processes running left behind.
I observe the bug with both mesg y and n
SC> running out of ideas here...
Me too so I hereby wait for Sven to chime in with what else he sees.
*This side issue only happened in emacs's shell, (and not with
LC_ALL=C, but yes with my zh locale) and is one of the reasons I now
use a different HISTORY file there... piped thru cat -v.
# sleep 22 && kill -1 $$& #Safety first, also makes the \377s go away.
[1] 16017
# perl -we '$<=$>=$(=$)=65534;system q(sh)'
05:40 ~$ Use "exit" to leave the shell.
05:40 ~$ sh: syntax error near unexpected token `('
05:40 258 ~$ sh:M-CM-^CM-BM-^@0: command not found
05:40 127 ~$ sh: syntax error near unexpected token `('
Anyway, no I don't believe in UFOs. Never mind this side issue. Bye.
Hello, http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2008-May/006585.html http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2008-May/006587.html It was reported to appear on kernel 2.6.24.5 and 2.6.25, on i386 single processor systems. It was reported to be OK with kernel 2.6.18, 2.6.23.16 or on x86_84 or on multi-processor systems. Jidanni and Sven, do you see similarities in your configuration and the ones used by Siim (mentioned in the above links)
Yes, I have kernel 2.6.24.6 and an i386 single processor system. Can try different kernels, but no SMP or 64 bit system -- unless you send me the money to buy one, that is. ;-) Sven
For the record, I'm running a Debian kernel 2.6.24-6, or 2.6.23-1~mtu1 on a Intel(R) Core(TM)2 Duo CPU E6550 (According to its changelog, 2.6.24-6 seems to be a 2.6.24.4) So I might be using a too old kernel to reproduce the bug, or it does not occur on dual cores. Are you using a Debian kernel? Or an home-compiled kernel? If instead of receiving answers by email, I receive computer to reproduce this bug, I will share with you ;)
2.6.24.4 should not be too old, when the bug was reported four weeks ago
I ran it myself.
Home-compiled.
Cheers,
Sven
Yes, those http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2008-May/006589.html etc. are all the same bug. You can merge them. It says yes it does, and also on product: AMD Duron(tm) processor size: 1GHz $ COLUMNS=1111 dlocate -l linux-image|perl -alnwe 'print "@F[0,1]" if /^ii/' ii linux-image-2.6-686 ii linux-image-2.6.24-1-686 ii linux-image-686
notfound 476519 1:4.1.1-1
tags 476519 -unreproducible
reassign 476519 bash
found 476519 3.2-4
thanks
I finally could reproduce this bug on one machine (not all), with:
* su - nobody
* perl -e '$<=$>=$(=$)=65534; system bash'
+ from an su - root session
+ from an ssh root session
sometimes, I get a "exit" message and return to the original shell,
sometimes, I get a prompt ("$ "), but it fails after I type the first
character,
sometimes, I get a valid shell for the user nobody.
Thus I don't think su is involved in this bug, but this looks more like a
bash bug.
I tried to reproduce it with an strace, but could not, however I could
reproduce it with an strace and the execution of bash --noediting.
(see the attached strace.ok and strace.fail logs)
I did not find any useful differences between these two strace logs.
Best Regards,
notfound 476519 1:4.1.1-1
tags 476519 -unreproducible
reassign 476519 bash
found 476519 3.2-4
thanks
I finally could reproduce this bug on one machine (not all), with:
* su - nobody
* perl -e '$<=$>=$(=$)=65534; system bash'
+ from an su - root session
+ from an ssh root session
sometimes, I get a "exit" message and return to the original shell,
sometimes, I get a prompt ("$ "), but it fails after I type the first
character,
sometimes, I get a valid shell for the user nobody.
Thus I don't think su is involved in this bug, but this looks more like a
bash bug.
I tried to reproduce it with an strace, but could not, however I could
reproduce it with an strace and the execution of bash --noediting.
(see the attached strace.ok and strace.fail logs)
I did not find any useful differences between these two strace logs.
Best Regards,
Hi, I can reproduce this on a fresh installed Lenny box (mung'd host/users): user@homer:~/ 0-$ su homer:/home/guard/ 0-# iexit <- i'm typing 'iptables', but get user@host:~/ 0-$ ptables -L kicked out almost immediately -bash: ptables: command not found user@host:~/ 0-$ /var/log/auth.log displays: Dec 3 17:14:16 host su[2590]: Successful su for root by user Dec 3 17:14:16 host su[2590]: + pts/0 guard:root Dec 3 17:14:16 host su[2590]: pam_unix(su:session): session opened for user root by user(uid=1000) Dec 3 17:14:18 host su[2590]: pam_unix(su:session): session closed for user root Just like Nicolas wrote in #147 in this bugreport: "sometimes, I get a "exit" message and return to the original shell, sometimes, I get a prompt but it fails after I type the first character, sometimes, I get a valid shell" Which of the 3 happens seems completely random. I've seen this behaviour on one other box, but on another dozen I administer daily (with afaik identical configuration) it does never ever happen. If I can help or do more specific test, let me know. Hans van Kranenburg P.S.: Linux host 2.6.26-1-xen-amd64 #1 SMP Sat Nov 8 21:20:04 UTC 2008 x86_64 GNU/Linux ii linux-image-2.6.26-1-xen-amd64 2.6.26-10 ii linux-modules-2.6.26-1-xen-amd64 2.6.26-10 ii bash 3.2-4 this is a Xen dom0
I've seen this bug on a 1 CPU lenny xen domU, with both dom0 and domU running the standard lenny 2.6.26 kernel on a dual-quadcore system (E5310 CPUs). It goes away when I give the guest 2 CPUs instead of 1. Also, you probably already know this, but this seems to be the same bug as http://bugs.gentoo.org/show_bug.cgi?id=232630 and https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/224802.
I am using a SID chroot on a Lenny system. In the chroot I experienced the problem that 'su user' would end after any keystroke and return to the root environment. The problem does not occur with shell /bin/sh but only with /bin/bash as user shell. The problem disappeared after rm /home/user/.bashrc I boiled down the users .bashrc until it contained only the following two lines: [ -x /usr/bin/lesspipe ] && eval "$(lesspipe)" PROMPT_COMMAND='echo -n ">"' If any of the above lines is removed the error disappears. /usr/bin/lesspipe returns: export LESSOPEN="| /usr/bin/lesspipe %s"; export LESSCLOSE="/usr/bin/lesspipe %s %s"; Best regards Xypron
We just hit that very same issue on Host running Lenny(inside an VMware ESX4 Host). The exact conditions for this to trigger here are: * exactly ONE cpu/core configured on the host * exactly 16GB RAM (using 8, 14 or 18GB does not cause the issue to appear) * bash as the shell removing one of the above variables cures the issue here so I would argue that this actually might be a kernel bug Stefan
Same issue here: Linux 2.6.26-2-amd64 #1 SMP Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux GNU bash, version 3.2.39(1)-release (x86_64-pc-linux-gnu) i.e.: su - nobody su - postgres logs me out really often on first key pressed. su - seems to work. Cheers -Rolf
Hi, it has been 1.5 years since the bug was reported. As I'm hitting the bug everyday, I would like to ask if there was any progress. regards marian
Now 2 years since this was reported. Experiencing this infrequently on a number of WMWare hosts, single CPU, 2GB Ram. Linux evo7-dvmh-web-05 2.6.26-2-686 #1 SMP Wed Feb 10 08:59:21 UTC 2010 i686 GNU/Linux Cheers, Stig
Hi,
I got the same Problem on a freshly installed Debian 5-box.
# uname -a
Linux mail3 2.6.26-2-amd64 #1 SMP Thu Sep 16 15:56:38 UTC 2010 x86_64 GNU/Linux
trying:
# su cyrus
cyrus@mail3:/tmp$ dexit
however, if I tried to strace it, it won't happen:
# strace su cyrus
....
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], NULL, 8) = 0
rt_sigaction(SIGTERM, {0x402420, [], SA_RESTORER, 0x7fca4965ff60}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [ALRM TERM], NULL, 8) = 0
wait4(-1,
(now typing 'd's an press return)
dddddddddddddd
bash: dddddddddddddd: command not found
cyrus@mail3:/tmp$ exit
[{WIFEXITED(s) && WEXITSTATUS(s) == 127}], WSTOPPED, NULL) = 13167
getuid() = 108
gettimeofday({1287048698, 560056}, NULL) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
socket(PF_FILE, SOCK_DGRAM, 0) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sa_family=AF_FILE, path="/dev/log"...}, 110) = 0
sendto(3, "<86>Oct 14 11:31:38 su[13166]: pa"..., 82, MSG_NOSIGNAL, NULL, 0) = 82
munmap(0x7fca489f2000, 2099928) = 0
munmap(0x7fca485d3000, 2107528) = 0
munmap(0x7fca483d1000, 2104616) = 0
munmap(0x7fca481b8000, 2197472) = 0
munmap(0x7fca487d6000, 2209368) = 0
munmap(0x7fca47f80000, 2322880) = 0
exit_group(127) = ?
I've found the same bugreport for gentoo:
http://bugs.gentoo.org/show_bug.cgi?id=232630
they mentioned, it may be some kind of timing issue, but there is no fix for it.
I installed some other boxes from the same repository (also Debian 5) and there
is no such behaviour.
kind regards
jm
kind regards
jm
Hallo, ich bin Frau Elizabeth Liu, wenn Sie als vor der Covid-19-Epidemie geschützt markiert wurden, meine Gebete mit Ihnen. Ich möchte Ihnen ein Geschäft im Wert von $7,400,000.00 USD anbieten. Wenn Sie interessiert sind, kontaktieren Sie mich privat. E-Mail: elizabethliu@winghangbnk.com Elizabeth Liu
Hallo, ich bin Frau Elizabeth Liu, wenn Sie als vor der Covid-19-Epidemie geschützt markiert wurden, meine Gebete mit Ihnen. Ich möchte Ihnen ein Geschäft im Wert von $7,400,000.00 USD anbieten. Wenn Sie interessiert sind, kontaktieren Sie mich privat. E-Mail: elizabethliu@winghangbnk.com Elizabeth Liu