Re: Mistype into shell..........
Sometimes I type something, slip and ahead of the command I type a character accidentally like '. The shell responds with I can type anything I want into that shell and it responds with How do I get out of that without killing the shell and bringing up a new one? Type another ' to close the string or hit CTRL-C. The same with double quotes. HTH. Dirk -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e6862de.1030...@weinhardt.biz
Re: How does apt select and priotize translations?
According to 'man apt.conf', Acquire::Languages can be set to declare
which translations one wants downloading. The pseudo-language
environment (which is part of the default setting) specifies that apt
should check $LC_MESSAGES. However, if this doesn't include a de
language, then it might actually be that Acquire::Languages was set at
install time.
Thank you for pointing me to the apt.conf man page. Even after reading
through the Languages section I cannot make sense of apt-get's behavior.
Check /etc/apt/apt-conf.d/* for Acquire::Languages.
Acquire::Languages is not set in any file in /etc/apt/apt-conf.d. I
added the following line to /etc/apt/apt-conf.d/70debconf and re-ran
apt-get update:
Acquire::Languages { en };
But apt-get still is querying German translations. Passing -o
Acquire::Languages=en to apt-get update does not change the behavior
either.
locale output:
LANG=en_US.utf8
LANGUAGE=en_US.utf8
LC_CTYPE=en_US.utf8
LC_NUMERIC=en_US.utf8
LC_TIME=en_US.utf8
LC_COLLATE=en_US.utf8
LC_MONETARY=en_US.utf8
LC_MESSAGES=en_US.utf8
LC_PAPER=en_US.utf8
LC_NAME=en_US.utf8
LC_ADDRESS=en_US.utf8
LC_TELEPHONE=en_US.utf8
LC_MEASUREMENT=en_US.utf8
LC_IDENTIFICATION=en_US.utf8
LC_ALL=en_US.utf8
Finally I noticed that /var/lib/apt/lists contained a few files with
names ending with Translation-de. After removing this folder apt-get
update does not query any translations any longer and also does not
re-create any -de files in /var/lib/apt/lists. Looks like apt-get is
trying to update all lists it ever had cached before.
Cheers, Dirk
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e5fe4fc.6050...@weinhardt.biz
How does apt select and priotize translations?
Hello list, I am about to install a particular package from wheezy on a squeeze system. Packages from wheezy should be pinned to a priority of 50. While configuring and testing apt I found that apt searches for German translations although the system's locale is en_US.utf8 and pinning priorities seem not to be applied to translations. I have added wheezy main to sources.list: deb http://ftp.debian.org/debian wheezy main And I have assigned a pin priority of 50 to testing in apt's preferences: Package: * Pin: release a=testing Pin-Priority: 50 The system's local initially was de_DE and I have changed that to en_US.utf8 by running dpkg-reconfigure locales. locale shows LANG=en_US.utf8 and locale -a does not list any de locale. Why is apt still querying German translations and how can that be avoided? Furthermore, wheezy translations are assigned a priority of 500. I would expect them to have a priority of 50. apt-cache policy output: Package files: 100 /var/lib/dpkg/status release a=now 500 http://ftp.debian.org/debian/ wheezy/main Translation-de 50 http://ftp.debian.org/debian/ wheezy/main i386 Packages release o=Debian,a=testing,n=wheezy,l=Debian,c=main origin ftp.debian.org 500 http://ftp.debian.org/debian/ squeeze-updates/non-free i386 Packages release o=Debian,a=stable-updates,n=squeeze-updates,l=Debian,c=non-free origin ftp.debian.org [snip] 500 http://ftp.debian.org/debian/ squeeze/main Translation-de 500 http://ftp.debian.org/debian/ squeeze/non-free i386 Packages release v=6.0.2.1,o=Debian,a=stable,n=squeeze,l=Debian,c=non-free origin ftp.debian.org 500 http://ftp.debian.org/debian/ squeeze/contrib i386 Packages release v=6.0.2.1,o=Debian,a=stable,n=squeeze,l=Debian,c=contrib origin ftp.debian.org 500 http://ftp.debian.org/debian/ squeeze/main i386 Packages release v=6.0.2.1,o=Debian,a=stable,n=squeeze,l=Debian,c=main origin ftp.debian.org Pinned packages: Or should I not care about this at all since these translations only contain package descriptions? Thanks for your assistance, Dirk -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5a2c8d.7080...@weinhardt.biz
Re: Dropped Connections and Failed to create cgroup nnnn: -17 Kernel Message When vsftpd Spawning a New Process
Hi, just in case anyone comes across this thread: I have filed a bug report for this issue under #639453. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639453 Dirk -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e58d769.40...@weinhardt.biz
Dropped Connections and Failed to create cgroup nnnn: -17 Kernel Message When vsftpd Spawning a New Process
Hello list,
I am experiencing the following issue with a Debian squeeze based server
and the most recent squeeze-backports kernel:
I realized that some vstfpd daemons randomly drop connections (sending a
FIN right after the initial TCP hand shake was completed). Furthermore,
a Failed to create cgroup : -17 message is logged by the kernel.
Furthermore, I am observing a steadily increasing number of directories
named like pids being created in the root of the cgroup virtual
filesystem (mounted at /cgroup). For each connection attempt to a vsftpd
daemon a new directory is created. Those directories seem to be never
deleted. After a few days of uptime there are about 7,500 directories
while there constantly are only about 150 processes running (more or
less idling, this server usually has low load).
When stracing vsftpd the call that fails seems to be this one (full
output below):
clone(child_stack=0, flags=0x2800|SIGCHLD) = -1 EEXIST (File exists)
Which makes me believe that those zombie directories in /cgroup might
conflict with the new pid . The longer the server is up the more likely
it becomes that connections are dropped.
Side note: The affected vsftpd daemons are running on a server that also
is hosting an LXC-based virtual server. I have experienced a steadily
increasing soft IRQ load on the server while a cgroup virtual filesystem
being mounted. I have upgraded to the recent squeeze-backports kernel
which seems not to suffer from this soft IRQ issue. vsftpd daemons
running inside LXC containers do not drop connections.
Anyone experiencing a similar issue or has any suggestions? When
reporting a bug for this issue would this need to be reported against
the kernel package?
Below is some information I thought might be useful. If required, I will
gladly provide any additional information.
Cheers,
Dirk
I am using vsftpd 2.3.2-3 which AFAIK is the most recent version
available from the squeeze and squeeze-backports repositories.
uname -a output:
Linux x 2.6.39-bpo.2-amd64 #1 SMP Tue Jul 26 10:35:23 UTC 2011
x86_64 GNU/Linux
strace vsftpd /etc/vsftp.conf output (successful connection attempt):
alarm(1)= 0
rt_sigreturn(0x1) = -1 EINTR (Interrupted system call)
alarm(0)= 1
wait4(-1, NULL, WNOHANG, NULL) = 6385
wait4(-1, NULL, WNOHANG, NULL) = -1 ECHILD (No child processes)
accept(3, {sa_family=AF_INET, sin_port=htons(46631),
sin_addr=inet_addr(xxx.xxx.xxx.xxx)}, [16]) = 4
clone(child_stack=0, flags=0x2800|SIGCHLD) = 6387
close(4)= 0
accept(3, 0x7fffc3ecdf70, [28]) = ? ERESTARTSYS (To be restarted)
strace vsftpd /etc/vsftp.conf output (failed connection attempt):
alarm(1)= 0
rt_sigreturn(0x1) = -1 EINTR (Interrupted system call)
alarm(0)= 1
wait4(-1, NULL, WNOHANG, NULL) = 6387
wait4(-1, NULL, WNOHANG, NULL) = -1 ECHILD (No child processes)
accept(3, {sa_family=AF_INET, sin_port=htons(47917),
sin_addr=inet_addr(xxx.xxx.xxx.xxx)}, [16]) = 4
clone(child_stack=0, flags=0x2800|SIGCHLD) = -1 EEXIST (File exists)
close(4)= 0
accept(33, 0x7fffc3ecdf70, [28]) = ? ERESTARTSYS (To be restarted)
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e54188c.6060...@weinhardt.biz
