Re: ps and AIX field descriptors
David Wright writes:
> On Mon 20 Feb 2023 at 10:39:21 (+0100), Andreas Leha wrote:
>> Greg Wooledge writes:
>> > On Sun, Feb 19, 2023 at 12:04:22PM -0600, David Wright wrote:
>> >> But even that's not enough
>> >> because the field width is somewhat variable: try ps -eo '%c | %z |
>> >> %a'
>> >> (We can still use | to make the problem somewhat more obvious.)
>> >
>> > Oh wow. Yeah, OK, that's not really solvable.
>> >
>> > For those who don't want to try to reverse engineer David's conclusion,
>> > or who don't just happen to stumble upon it with their current process
>> > list, here's what I'm seeing:
>> >
>> > COMMAND | VSZ | COMMAND
>> > systemd | 164140 | /sbin/init
>> > kthreadd | 0 | [kthreadd]
>> > rcu_gp | 0 | [rcu_gp]
>> > rcu_par_gp | 0 | [rcu_par_gp]
>> > [...]
>> > steamwebhelper | 4631064 | /home/greg/.steam/debian-installation/[...]
>> > [...]
>> > chrome_crashpad | 33567792 |
>> > /opt/google/chrome/chrome_crashpad_handler[...]
>> > [...]
>> > kworker/3:0-eve | 0 | [kworker/3:0-events]
>> >
>> > ps appears to guess an initial maximum width for the VSZ field, but
>> > when a value comes along that exceeds the guessed maximum, it simply
>> > shoves the field barrier over. It doesn't even become the new maximum,
>> > with all of the fields aligning after that. It's just a one-time shove,
>> > breaking the current line only.
>> >
>> > Therefore, parsing the header line cannot give us enough information to
>> > insert field separators correctly in body lines after the fact.
>>
>>
>> Dear all,
>>
>> Thanks for chiming in. The example was indeed simplified and I am using
>> %a which can contain internal whitespace.
>>
>> This is the command I was using previously:
>>
>> ps -eo '%p|%c|%C' -o "%mem" -o '|%a' --sort=-%cpu
>>
>> I now replaced it with
>>
>> ps -eo '%p %c %C' -o "%mem" -o ' %a' --sort=-%cpu | sed -E 's/([0-9]+)
>> (.+) ([0-9]+.?[0-9]?) ([0-9]+.?[0-9]?) (.+)/\1|\2|\3|\4|\5/'
>>
>> This works, but is of course cumbersome to maintain.
>>
>> Again, thanks for all the comments!
>
> I think there are a few too many assumptions in there;
> in particular, numbers in %a will match patterns designed
> to match cpu and mem, because you can't prevent sed from
> being greedy (except with the [^ … … ]+ construction, to
> restrict what it matches).
>
> This version makes a few assumptions as well:
> . that the new format matches the old one (mine) if the
> delimiters given are a single space (like '%p %c %C'),
> or stripped (like "%mem" and '%a', but not ' %a').
> . the short command is always 15 chars wide even if all
> the commands in the table are shorter, eg with ps -o.
> . I don't have any of those new-fangled extra-long PIDs
> yet today.
>
> It might well break if a CPU or MEM is running at 100%.
> That's not easily tested here.
>
> I've reordered the columns on the first pass, so that the
> numeric ones (with their limited character set) come first,
> which means I can use an auxiliary character for
> correcting the spacing. (The spaces between the columns get
> comingled with the leading spaces of numbers.) The second
> pass sorts that out and processes the heading.
>
> $ ps -eo '%p %c %C' -o "%mem" -o '%a' --sort=-%cpu | sed -E 's/( *[0-9]+)
> (.{15})( +[0-9.]+ +[0-9.]+) (.*$)/\1~\3~\2\4/;' | sed -E 's/([^~]+)~
> ([^~]+)~(.{15})(.*)/\1|\3|\2|\4/;s/^( *PID) (COMMAND) /\1|\2|/;s/%MEM
> COMMAND/%MEM|COMMAND/;' | less
> $
>
> This is the same, except I deliberately chose _ for the auxiliary
> character, knowing that short commands are stuffed with underscores:
>
> $ ps -eo '%p %c %C' -o "%mem" -o '%a' --sort=-%cpu | sed -E 's/( *[0-9]+)
> (.{15})( +[0-9.]+ +[0-9.]+) (.*$)/\1_\3_\2\4/;' | sed -E 's/([^_]+)_
> ([^_]+)_(.{15})(.*)/\1|\3|\2|\4/;s/^( *PID) (COMMAND) /\1|\2|/;s/%MEM
> COMMAND/%MEM|COMMAND/;' | less
> $
>
> Examples:
>
> PID|COMMAND|%CPU %MEM|COMMAND
>9798|firefox-esr| 2.5 5.8|firefox-esr
> 16143|Isolated Web Co| 1.8 2.2|/usr/lib/firefox-esr/firefox-esr
> -contentproc -childID 11 -isForBrowser -prefsLen 47676 -prefMapSize 232307
> -jsInitLen 277276 -parentBuildID 20230214011352 -appDir
> /usr/lib/firefox-esr/browser 9798 true tab
>1242|Xorg | 1.0 1.4|/usr/lib/xorg/Xorg
xdm not autostarting
Hi all,
Unfortunately I can't trace exactly how I got myself in this situation,
but right now, xdm does not autostart for me.
Largely, what I did: Install bullseye without GUI but install xdm later
manually. I also upgraded to bookworm (for other reasons). It might
well be that the issue is not bookworm specific, though, but rather was
present before the upgrade.
When I reboot I am left at the text console (Xorg.0.log) attached. It
seems that the xdm service fails because of 'no screens found'.
When I log in as root then and run 'service xdm start' xdm starts fine.
('systemctl get-default' returns 'graphical.target')
What should be my next steps to resolve this?
Thanks in advance!
Andreas
[15.544]
X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
[15.544] Current Operating System: Linux ukes-ams-93 6.1.0-3-amd64 #1 SMP
PREEMPT_DYNAMIC Debian 6.1.8-1 (2023-01-29) x86_64
[15.544] Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-3-amd64
root=/dev/mapper/ukes--ams--93--vg-root ro quiet
[15.544] xorg-server 2:21.1.7-1 (https://www.debian.org/support)
[15.544] Current version of pixman: 0.42.2
[15.544]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[15.544] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[15.544] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 18 15:52:45
2023
[15.544] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[15.546] (==) No Layout section. Using the first Screen section.
[15.546] (==) No screen section available. Using defaults.
[15.546] (**) |-->Screen "Default Screen Section" (0)
[15.546] (**) | |-->Monitor ""
[15.547] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[15.547] (==) Automatically adding devices
[15.547] (==) Automatically enabling devices
[15.547] (==) Automatically adding GPU devices
[15.547] (==) Automatically binding GPU devices
[15.547] (==) Max clients allowed: 256, resource mask: 0x1f
[15.548] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[15.548]Entry deleted from font path.
[15.550] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[15.550] (==) ModulePath set to "/usr/lib/xorg/modules"
[15.550] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable
AutoAddDevices.
[15.550] (II) Loader magic: 0x56371c015f00
[15.550] (II) Module ABI versions:
[15.550]X.Org ANSI C Emulation: 0.4
[15.550]X.Org Video Driver: 25.2
[15.550]X.Org XInput driver : 24.4
[15.550]X.Org Server Extension : 10.0
[15.550] (++) using VT number 7
[15.550] (II) systemd-logind: logind integration requires -keeptty and
-keeptty was not provided, disabling logind integration
[15.553] (--) PCI:*(0@0:2:0) 8086:9b41:1028:09be rev 2, Mem @
0x604a00/16777216, 0x40/268435456, I/O @ 0x3000/64, BIOS @
0x/131072
[15.553] (II) LoadModule: "glx"
[15.553] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[15.558] (II) Module glx: vendor="X.Org Foundation"
[15.558]compiled for 1.21.1.7, module version = 1.0.0
[15.558]ABI class: X.Org Server Extension, version 10.0
[15.558] (==) Matched modesetting as autoconfigured driver 0
[15.558] (==) Matched fbdev as autoconfigured driver 1
[15.558] (==) Matched vesa as autoconfigured driver 2
[15.558] (==) Assigned the driver to the xf86ConfigLayout
[15.558] (II) LoadModule: "modesetting"
[15.558] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[15.558] (II) Module modesetting: vendor="X.Org Foundation"
[15.558]compiled for 1.21.1.7, module version = 1.21.1
[15.558]Module class: X.Org Video Driver
[15.558]ABI class: X.Org Video Driver, version 25.2
[15.558] (II) LoadModule: "fbdev"
[15.558] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[15.559] (II) Module fbdev: vendor="X.Org Foundation"
[15.559]compiled for 1.21.1.3, module version = 0.5.0
[15.559]Module class: X.Org Video Driver
[15.559]ABI class: X.Org Video Driver, version 25.2
[15.559] (II) LoadModule: "vesa"
[15.559] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[15.559] (II) Module vesa: vendor="X.Org Foundation"
[15.559]compiled for 1.21.1.3, module version = 2.5.0
[15.559]Module class: X.Org Video Driver
[
Re: ps and AIX field descriptors
Greg Wooledge writes: > On Sun, Feb 19, 2023 at 12:04:22PM -0600, David Wright wrote: >> But even that's not enough >> because the field width is somewhat variable: try ps -eo '%c | %z | %a' >> (We can still use | to make the problem somewhat more obvious.) > > Oh wow. Yeah, OK, that's not really solvable. > > For those who don't want to try to reverse engineer David's conclusion, > or who don't just happen to stumble upon it with their current process > list, here's what I'm seeing: > > COMMAND | VSZ | COMMAND > systemd | 164140 | /sbin/init > kthreadd | 0 | [kthreadd] > rcu_gp | 0 | [rcu_gp] > rcu_par_gp | 0 | [rcu_par_gp] > [...] > steamwebhelper | 4631064 | /home/greg/.steam/debian-installation/[...] > [...] > chrome_crashpad | 33567792 | > /opt/google/chrome/chrome_crashpad_handler[...] > [...] > kworker/3:0-eve | 0 | [kworker/3:0-events] > > ps appears to guess an initial maximum width for the VSZ field, but > when a value comes along that exceeds the guessed maximum, it simply > shoves the field barrier over. It doesn't even become the new maximum, > with all of the fields aligning after that. It's just a one-time shove, > breaking the current line only. > > Therefore, parsing the header line cannot give us enough information to > insert field separators correctly in body lines after the fact. Dear all, Thanks for chiming in. The example was indeed simplified and I am using %a which can contain internal whitespace. This is the command I was using previously: ps -eo '%p|%c|%C' -o "%mem" -o '|%a' --sort=-%cpu I now replaced it with ps -eo '%p %c %C' -o "%mem" -o ' %a' --sort=-%cpu | sed -E 's/([0-9]+) (.+) ([0-9]+.?[0-9]?) ([0-9]+.?[0-9]?) (.+)/\1|\2|\3|\4|\5/' This works, but is of course cumbersome to maintain. Again, thanks for all the comments! Best, Andreas
Re: ps and AIX field descriptors
Reco writes:
> Hi.
>
> On Fri, Feb 17, 2023 at 07:46:23AM +0100, Andreas Leha wrote:
>> Now my question: How can I restore the previous behaviour that allowed
>> other than whitespace separators between fields?
>
> diff -purw procps-3.3.17/ps/sortformat.c procps-4.0.2/src/ps/sortformat.c
> shows me that:
>
> @@ -128,22 +127,24 @@ static const char *aix_format_parse(sf_n
>items = 0;
>walk = sfn->sf;
>/* state machine */ {
> - int c;
> + int c = *walk++;
>initial:
> -c = *walk++;
> if(c=='%')goto get_desc;
> if(!c)goto looks_ok;
>/* get_text: */
> items++;
> - get_more_text:
> + get_more:
> c = *walk++;
> if(c=='%')goto get_desc;
> -if(c) goto get_more_text;
> +if(c==' ')goto get_more;
> +if(c) goto aix_oops;
> goto looks_ok;
>get_desc:
> items++;
> c = *walk++;
> -if(c) goto initial;
> +if(c&!=' ') goto initial;
> +return _("missing AIX field descriptor");
> + aix_oops:
> return _("improper AIX field descriptor");
>looks_ok:
> ;
>
> If you look at "get_more" label, you'll notice that "old" version of
> procps (bullseye's) checked for any character after "%" block.
> "New" one (bookworm's) explicitly checks for space, and goes to
> "aix_oops" in any other case.
>
> And there is no #ifdefs, no environment variable checks, no options
> etc.
>
>
> So, to answer your question - currently the only way to restore the
> behaviour you want is to patch procps and rebuild it.
>
> Reco
Dear Reco,
Thanks for the fast and accurate answer! What a shame for this change...
Best,
Andreas
ps and AIX field descriptors
Hi all, I am facing a strange issue. This command used to work ps -eo '%p|%C' Now, on a debian testing machine only ps -eo '%p %C' works. Running ps -eo '%p|%C' results in this error: error: improper AIX field descriptor ps --version says 'ps from procps-ng 4.0.2' Now my question: How can I restore the previous behaviour that allowed other than whitespace separators between fields? Thanks in advance! Andreas
Re: re-compiling package twice errors out
Roberto C. Sánchez writes: > On Thu, Feb 16, 2023 at 10:37:00AM +0100, Andreas Leha wrote: >> >> Dear Tomas, >> >> Thanks for the swift reply! >> >> OK, then I should do `quilt pop -a` before the second compilation, >> right? >> >> But that leads to another error message: >> > > This can be considered a bug in the package. The idea is that debuild > run 'debian/rules clean' first and the 'clean' target is expected to > restore the source tree to the same state as what it was freshly > unpacked (and all the quilt patches applied). This package apparently > doesn't do this correctly (or at all), and so you are forced to start by > unpacking each team in order to have a clean build. The correct > solution is to fix the 'clean' target so that you can repeatedly run the > build without having to remove the package directory and unpack it > again. > > Regards, > > -Roberto Thanks for all responses!
Re: re-compiling package twice errors out
writes: > On Thu, Feb 16, 2023 at 10:05:54AM +0100, Andreas Leha wrote: >> Dear all, >> >> I am re-compiling xscreensaver. >> >> Re-compiling once works fine: >> >> apt-get source xscreensaver >> cd xscreensaver-6.0.6+dfsg1 >> LANG=C debuild -us -uc >> >> >> Re-compiling a second time errors out, though: >> >> > LANG=C debuild -us -uc >> (skipped lines) >> dpkg-source: info: using source format '3.0 (quilt)' >> dpkg-source: info: building xscreensaver using existing >> ./xscreensaver_6.06+dfsg1.orig.tar.xz >> dpkg-source: info: using patch list from debian/patches/series >> dpkg-source: error: cannot represent change to hacks/fonts/OCRAStd.otf: >> binary file contents changed >> dpkg-source: error: add hacks/fonts/OCRAStd.otf in >> debian/source/include-binaries if you want to store the modified binary in >> the debian >> tarball >> dpkg-source: warning: newly created empty file >> 'po/.intltool-merge-cache.lock' will not be represented in diff >> dpkg-source: error: unrepresentable changes to source >> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit >> status 1 >> debuild: fatal error at line 1182: >> dpkg-buildpackage -us -uc -ui failed >> >> >> What am I missing here? > > It is trying to apply the patches to an already patched source. > > If you run the whole thing (debuild etc) you best start from > a freshly unpacked source package. > > Otherwise you want to jump into the middle of the package > build (e.g. patches already applied or so). Then you'll have > to understand how that specific build system works (e.g. > configure, make or similar). > > Cheers Dear Tomas, Thanks for the swift reply! OK, then I should do `quilt pop -a` before the second compilation, right? But that leads to another error message: > apt-get source xscreensaver > cd xscreensaver-6.0.6+dfsg1 > LANG=C debuild -us -uc > quilt pop -a -f > LANG=C debuild -us -uc dpkg-buildpackage -us -uc -ui dpkg-buildpackage: info: source package xscreensaver dpkg-buildpackage: info: source version 6.06+dfsg1-2 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Tormod Volden dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 10_upstream_skip_retired_hacks.patch dpkg-source: info: applying 12_upstream_man_beats_speereev_backslash.patch dpkg-source: info: applying 20_hacks_man_section.patch dpkg-source: info: applying 20_skip_install-pam.patch dpkg-source: info: applying 50_debian_branding.patch dpkg-source: info: applying 51_generalize_external_commands.patch dpkg-source: info: applying 52_standard_time_format.patch dpkg-source: info: applying 53_default_newLoginCommand.patch dpkg-source: info: applying 55_add_unicode_hack.patch dpkg-source: info: applying 57_grabDesktopImages_default_off.patch dpkg-source: info: applying 75_Makefile_in-ignore-alien-platforms.patch dpkg-source: info: applying 81_hacks_deterministic_file_order.patch dpkg-source: info: applying 90_remove_Easter_egg_about_version.patch dpkg-source: info: applying 92_hacks_images_distclean.patch dpkg-source: info: applying 94_allow_unrecognized_conf_opts.patch dpkg-source: info: applying 96_nogl-build-for-nogl-config.patch dpkg-source: info: applying 98_daemon_desktop_file.patch dpkg-source: info: applying 100_configure_allow_warnings.patch fakeroot debian/rules clean dh clean --without autoreconf debian/rules override_dh_auto_clean make[1]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1' [ ! -f Makefile ] || /usr/bin/make distclean make[2]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1' make[3]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/utils' rm -f *.o a.out core make[3]: Leaving directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/utils' make[3]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/jwxyz' rm -f *.o a.out core make[3]: Leaving directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/jwxyz' make[3]: Entering directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/hacks/images' Makefile:64: *** target file 'distclean' has both : and :: entries. Stop. make[3]: Leaving directory '/home/aleha/tmp/xscreensaver2/xscreensaver-6.06+dfsg1/hacks/images' make[2]:
re-compiling package twice errors out
Dear all, I am re-compiling xscreensaver. Re-compiling once works fine: apt-get source xscreensaver cd xscreensaver-6.0.6+dfsg1 LANG=C debuild -us -uc Re-compiling a second time errors out, though: > LANG=C debuild -us -uc (skipped lines) dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building xscreensaver using existing ./xscreensaver_6.06+dfsg1.orig.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: error: cannot represent change to hacks/fonts/OCRAStd.otf: binary file contents changed dpkg-source: error: add hacks/fonts/OCRAStd.otf in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: warning: newly created empty file 'po/.intltool-merge-cache.lock' will not be represented in diff dpkg-source: error: unrepresentable changes to source dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 1 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui failed What am I missing here? Thanks in advance. Andreas
Re: Why does my ssh session terminate immediately?
Hi all, thanks for all your suggestions and help. I chose to re-install now, as I am not able to spend more time on this issue. Although I would have loved to know what caused the error in the end, the re-install fixed it and was cheaper than a continued search for the cause. Thanks again for all the help. Regards, Andreas -- 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/87vc7271rd@med.uni-goettingen.de
Re: Why does my ssh session terminate immediately?
Hi Vincent, thanks again for all your help. Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-24 23:38:06 +0200, Andreas Leha wrote: Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-24 05:03:53 +0200, Andreas Leha wrote: Vincent Lefevre vinc...@vinc17.net writes: BTW, does ssh -t localhost work on both machines? I am not sure. On the 'client' it does. On the 'server' I get this: , | ssh root@192.168.2.109 bash | ssh -t localhost | Pseudo-terminal will not be allocated because stdin is not a terminal. | Host key verification failed. ` That's normal if you don't have a tty in the first place. Don't you have some kind of console? I am not sure I understand that question. Is there some kind of terminal access without needing ssh or telnet? No, unfortunately not. Only via network. $ ssh -t root@192.168.2.109 ls -l /dev/pts Here, I get , | total 0 | crw--w 1 root tty 136, 0 Apr 24 21:19 0 | c- 1 root root 5, 2 Jan 1 1970 ptmx | Connection to 192.168.2.109 closed. ` One can see that pts/0 has been created and used. You can also try whether telnet over SSH works... Or just simple telnet if the local network is secure. If this works, you can try again ssh -t localhost (or just ssh localhost, since -t is implied without a command) from there. I get the same problem using telnet: , | telnet 192.168.2.109 | Trying 192.168.2.109... | Connected to 192.168.2.109. | Escape character is '^]'. | Debian GNU/Linux 6.0 | debian login: andreas | Password: | Last login: Wed Apr 24 21:35:35 UTC 2013 from 192.168.2.101 on pts/0 | Linux debian 2.6.32-5-kirkwood #1 Sun May 6 16:57:51 UTC 2012 armv5tel | | The programs included with the Debian GNU/Linux system are free software; | the exact distribution terms for each program are described in the | individual files in /usr/share/doc/*/copyright. | | Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent | permitted by applicable law. | Connection closed by foreign host. ` So, it seems that pts/0 has correctly been allocated. But in both cases (ssh and telnet), there's a problem. Since it happens also with telnet, I doubt there's any problem with sshd. Perhaps a bug related to the (pseudo-)ttys. Look at /var/log/messages on the remote machine to see if there is any error message. Just in case... I have no file '/var/log/messages' You can also search Google for Connection closed by foreign host. According to http://www.geexbox.org/forum/topic/telnet-connection-closed-by-foreign-host/ there was a recent bug affecting Raspberry Pi (ARM). Your machine is also ARM-based. It might be related... Thanks for that pointer. I got the corresponding commit: , | hangeset f7753f053449 in /var/www/hg/openbricks | author: warped-rudi r.i...@s-t.de | details: http://hg.openbricks.org/openbricks?cmd=changeset;node=f7753f053449 | description: | [RPi] kernel: enable telnetd | diffstat: | | config/platforms/arm/bcm2708/linux.conf | 3 ++- | 1 files changed, 2 insertions(+), 1 deletions(-) | | diffs (13 lines): | | diff -r 0329ffe73d78 -r f7753f053449 config/platforms/arm/bcm2708/linux.conf | --- a/config/platforms/arm/bcm2708/linux.confTue Feb 05 23:36:10 2013 +0100 | +++ b/config/platforms/arm/bcm2708/linux.confWed Feb 06 19:58:17 2013 +0100 | @@ -1483,7 +1483,8 @@ | CONFIG_VT_HW_CONSOLE_BINDING=y | CONFIG_UNIX98_PTYS=y | # CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set | -# CONFIG_LEGACY_PTYS is not set | +CONFIG_LEGACY_PTYS=y | +CONFIG_LEGACY_PTY_COUNT=16 | # CONFIG_SERIAL_NONSTANDARD is not set | # CONFIG_N_GSM is not set | # CONFIG_TRACE_SINK is not set ` I did the same (which took a while as I have no prior experience in cross compiling). Now the newly compiled kernel booted ok, but things did not change :-( , | ssh root@192.168.2.109 | Linux debian 3.2.41-dockstar #1 Sun Apr 28 15:16:21 CEST 2013 armv5tel | | The programs included with the Debian GNU/Linux system are free software; | the exact distribution terms for each program are described in the | individual files in /usr/share/doc/*/copyright. | | Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent | permitted by applicable law. | Last login: Sun Apr 28 19:26:38 2013 from 192.168.2.101 | Connection to 192.168.2.109 closed. ` Well, at least I learned sth about cross compiling. Regards, Andreas PS: I'd still be grateful for more pointers -- 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/874neqwieg@med.uni-goettingen.de
Re: Why does my ssh session terminate immediately?
Hi Jean-Marc, thanks for your suggestions. See the results inline. Jean-Marc jean-m...@6jf.be writes: On Wed, 24 Apr 2013 05:03:53 +0200, Andreas Leha andreas.l...@med.uni-goettingen.de wrote: Hi Andreas, Did you check your sshd config' ? You can do it running: sshd -t I get nothing -- which I think is good in this case. You can also make tests by running you sshd in debug mode. Just start it on another port to not disturb the main one: sshd -de -p 8022 and try a connection on this SSH from your client: ssh -p 8022 yourhost and check what happens on your server. I did that, here is the result: ,[ on the server -- before a connection attempt ] | /usr/sbin/sshd -de -p 8022 | debug1: sshd version OpenSSH_5.5p1 Debian-6+squeeze3 | debug1: read PEM private key done: type RSA | debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 | debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 | debug1: private host key: #0 type 1 RSA | debug1: read PEM private key done: type DSA | debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 | debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 | debug1: private host key: #1 type 2 DSA | debug1: rexec_argv[0]='/usr/sbin/sshd' | debug1: rexec_argv[1]='-de' | debug1: rexec_argv[2]='-p' | debug1: rexec_argv[3]='8022' | Set /proc/self/oom_adj from 0 to -17 | debug1: Bind to port 8022 on 0.0.0.0. | Server listening on 0.0.0.0 port 8022. | debug1: Bind to port 8022 on ::. | Server listening on :: port 8022. ` ,[ on the server -- during a connection attempt ] | debug1: Server will not fork when running in debugging mode. | debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 | debug1: sshd version OpenSSH_5.5p1 Debian-6+squeeze3 | debug1: read PEM private key done: type RSA | debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 | debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 | debug1: private host key: #0 type 1 RSA | debug1: read PEM private key done: type DSA | debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 | debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 | debug1: private host key: #1 type 2 DSA | debug1: inetd sockets after dupping: 3, 3 | Connection from 192.168.2.101 port 55650 | debug1: Client protocol version 2.0; client software version OpenSSH_6.0p1 Debian-4 | debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH* | debug1: Enabling compatibility mode for protocol 2.0 | debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze3 | debug1: permanently_set_uid: 101/65534 | debug1: list_hostkey_types: ssh-rsa,ssh-dss | debug1: SSH2_MSG_KEXINIT sent | debug1: SSH2_MSG_KEXINIT received | debug1: kex: client-server aes128-ctr hmac-md5 none | debug1: kex: server-client aes128-ctr hmac-md5 none | debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received | debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent | debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT | debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent | debug1: SSH2_MSG_NEWKEYS sent | debug1: expecting SSH2_MSG_NEWKEYS | debug1: SSH2_MSG_NEWKEYS received | debug1: KEX done | debug1: userauth-request for user root service ssh-connection method none | debug1: attempt 0 failures 0 | debug1: PAM: initializing for root | debug1: PAM: setting PAM_RHOST to 192.168.2.101 | debug1: PAM: setting PAM_TTY to ssh | Failed none for root from 192.168.2.101 port 55650 ssh2 | debug1: userauth-request for user root service ssh-connection method publickey | debug1: attempt 1 failures 0 | debug1: test whether pkalg/pkblob are acceptable | debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 | debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 | debug1: temporarily_use_uid: 0/0 (e=0/0) | debug1: trying public key file /root/.ssh/authorized_keys | debug1: fd 4 clearing O_NONBLOCK | debug1: matching key found: file /root/.ssh/authorized_keys, line 1 | Found matching RSA key: 47:7c:14:dd:25:54:14:0d:d8:cf:c5:24:44:d4:7b:c2 | debug1: restore_uid: 0/0 | Postponed publickey for root from 192.168.2.101 port 55650 ssh2 | debug1: userauth-request for user root service ssh-connection method publickey | debug1: attempt 2 failures 0 | debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 | debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 | debug1: temporarily_use_uid: 0/0 (e=0/0) | debug1: trying public key file /root/.ssh/authorized_keys | debug1: fd 4 clearing O_NONBLOCK | debug1: matching key found: file /root/.ssh/authorized_keys, line 1 | Found matching RSA key: 47:7c:14:dd:25:54:14:0d:d8:cf:c5:24:44:d4:7b:c2 | debug1: restore_uid: 0/0 | debug1: ssh_rsa_verify: signature correct | debug1: do_pam_account: called | Accepted publickey for root from 192.168.2.101 port 55650 ssh2 | debug1: monitor_child_preauth: root has been authenticated by privileged process | debug1: PAM: establishing credentials | debug1: Entering interactive session for SSH2. | debug1: server_init_dispatch_20 | debug1
Re: Why does my ssh session terminate immediately?
Hi Vincent, thanks for staying on this! Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-24 05:03:53 +0200, Andreas Leha wrote: Vincent Lefevre vinc...@vinc17.net writes: BTW, does ssh -t localhost work on both machines? I am not sure. On the 'client' it does. On the 'server' I get this: , | ssh root@192.168.2.109 bash | ssh -t localhost | Pseudo-terminal will not be allocated because stdin is not a terminal. | Host key verification failed. ` That's normal if you don't have a tty in the first place. Don't you have some kind of console? I am not sure I understand that question. BTW, what does the following say? $ ssh -t root@192.168.2.109 ls -l /dev/tty\* I get a long list: , | crw-rw-rw- 1 root root5, 0 Jan 1 1970 /dev/tty | crw--- 1 root root4, 0 Jan 1 1970 /dev/tty0 | crw--- 1 root root4, 1 Jan 1 1970 /dev/tty1 | crw--- 1 root root4, 10 Jan 1 1970 /dev/tty10 | crw--- 1 root root4, 11 Jan 1 1970 /dev/tty11 | crw--- 1 root root4, 12 Jan 1 1970 /dev/tty12 | crw--- 1 root root4, 13 Jan 1 1970 /dev/tty13 | crw--- 1 root root4, 14 Jan 1 1970 /dev/tty14 | crw--- 1 root root4, 15 Jan 1 1970 /dev/tty15 | crw--- 1 root root4, 16 Jan 1 1970 /dev/tty16 | crw--- 1 root root4, 17 Jan 1 1970 /dev/tty17 | crw--- 1 root root4, 18 Jan 1 1970 /dev/tty18 | crw--- 1 root root4, 19 Jan 1 1970 /dev/tty19 | crw--- 1 root root4, 2 Jan 1 1970 /dev/tty2 | crw--- 1 root root4, 20 Jan 1 1970 /dev/tty20 | crw--- 1 root root4, 21 Jan 1 1970 /dev/tty21 | crw--- 1 root root4, 22 Jan 1 1970 /dev/tty22 | crw--- 1 root root4, 23 Jan 1 1970 /dev/tty23 | crw--- 1 root root4, 24 Jan 1 1970 /dev/tty24 | crw--- 1 root root4, 25 Jan 1 1970 /dev/tty25 | crw--- 1 root root4, 26 Jan 1 1970 /dev/tty26 | crw--- 1 root root4, 27 Jan 1 1970 /dev/tty27 | crw--- 1 root root4, 28 Jan 1 1970 /dev/tty28 | crw--- 1 root root4, 29 Jan 1 1970 /dev/tty29 | crw--- 1 root root4, 3 Jan 1 1970 /dev/tty3 | crw--- 1 root root4, 30 Jan 1 1970 /dev/tty30 | crw--- 1 root root4, 31 Jan 1 1970 /dev/tty31 | crw--- 1 root root4, 32 Jan 1 1970 /dev/tty32 | crw--- 1 root root4, 33 Jan 1 1970 /dev/tty33 | crw--- 1 root root4, 34 Jan 1 1970 /dev/tty34 | crw--- 1 root root4, 35 Jan 1 1970 /dev/tty35 | crw--- 1 root root4, 36 Jan 1 1970 /dev/tty36 | crw--- 1 root root4, 37 Jan 1 1970 /dev/tty37 | crw--- 1 root root4, 38 Jan 1 1970 /dev/tty38 | crw--- 1 root root4, 39 Jan 1 1970 /dev/tty39 | crw--- 1 root root4, 4 Jan 1 1970 /dev/tty4 | crw--- 1 root root4, 40 Jan 1 1970 /dev/tty40 | crw--- 1 root root4, 41 Jan 1 1970 /dev/tty41 | crw--- 1 root root4, 42 Jan 1 1970 /dev/tty42 | crw--- 1 root root4, 43 Jan 1 1970 /dev/tty43 | crw--- 1 root root4, 44 Jan 1 1970 /dev/tty44 | crw--- 1 root root4, 45 Jan 1 1970 /dev/tty45 | crw--- 1 root root4, 46 Jan 1 1970 /dev/tty46 | crw--- 1 root root4, 47 Jan 1 1970 /dev/tty47 | crw--- 1 root root4, 48 Jan 1 1970 /dev/tty48 | crw--- 1 root root4, 49 Jan 1 1970 /dev/tty49 | crw--- 1 root root4, 5 Jan 1 1970 /dev/tty5 | crw--- 1 root root4, 50 Jan 1 1970 /dev/tty50 | crw--- 1 root root4, 51 Jan 1 1970 /dev/tty51 | crw--- 1 root root4, 52 Jan 1 1970 /dev/tty52 | crw--- 1 root root4, 53 Jan 1 1970 /dev/tty53 | crw--- 1 root root4, 54 Jan 1 1970 /dev/tty54 | crw--- 1 root root4, 55 Jan 1 1970 /dev/tty55 | crw--- 1 root root4, 56 Jan 1 1970 /dev/tty56 | crw--- 1 root root4, 57 Jan 1 1970 /dev/tty57 | crw--- 1 root root4, 58 Jan 1 1970 /dev/tty58 | crw--- 1 root root4, 59 Jan 1 1970 /dev/tty59 | crw--- 1 root root4, 6 Jan 1 1970 /dev/tty6 | crw--- 1 root root4, 60 Jan 1 1970 /dev/tty60 | crw--- 1 root root4, 61 Jan 1 1970 /dev/tty61 | crw--- 1 root root4, 62 Jan 1 1970 /dev/tty62 | crw--- 1 root root4, 63 Jan 1 1970 /dev/tty63 | crw--- 1 root root4, 7 Jan 1 1970 /dev/tty7 | crw--- 1 root root4, 8 Jan 1 1970 /dev/tty8 | crw--- 1 root root4, 9 Jan 1 1970 /dev/tty9 | crw--- 1 root root4, 64 Jan 1 1970 /dev/ttyS0 | crw-rw 1 root dialout 4, 65 Jan 1 1970 /dev/ttyS1 | Connection to 192.168.2.109 closed. ` $ ssh -t root@192.168.2.109 ls -l /dev/pts Here, I get , | total 0 | crw--w 1 root tty 136, 0 Apr 24 21:19 0 | c- 1 root root 5, 2 Jan 1 1970 ptmx | Connection to 192.168.2.109 closed. ` You can also try whether telnet over SSH works... Or just simple telnet if the local network is secure. If this works, you can
Re: Why does my ssh session terminate immediately?
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi Jean-Marc, thanks for your suggestions. See the results inline. Jean-Marc jean-m...@6jf.be writes: On Wed, 24 Apr 2013 05:03:53 +0200, Andreas Leha andreas.l...@med.uni-goettingen.de wrote: Hi Andreas, Did you check your sshd config' ? You can do it running: sshd -t I get nothing -- which I think is good in this case. You can also make tests by running you sshd in debug mode. Just start it on another port to not disturb the main one: sshd -de -p 8022 and try a connection on this SSH from your client: ssh -p 8022 yourhost and check what happens on your server. I did that, here is the result: ,[ on the server -- before a connection attempt ] | /usr/sbin/sshd -de -p 8022 | debug1: sshd version OpenSSH_5.5p1 Debian-6+squeeze3 | debug1: read PEM private key done: type RSA | debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 | debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 | debug1: private host key: #0 type 1 RSA | debug1: read PEM private key done: type DSA | debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 | debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 | debug1: private host key: #1 type 2 DSA | debug1: rexec_argv[0]='/usr/sbin/sshd' | debug1: rexec_argv[1]='-de' | debug1: rexec_argv[2]='-p' | debug1: rexec_argv[3]='8022' | Set /proc/self/oom_adj from 0 to -17 | debug1: Bind to port 8022 on 0.0.0.0. | Server listening on 0.0.0.0 port 8022. | debug1: Bind to port 8022 on ::. | Server listening on :: port 8022. ` ,[ on the server -- during a connection attempt ] | debug1: Server will not fork when running in debugging mode. | debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 | debug1: sshd version OpenSSH_5.5p1 Debian-6+squeeze3 | debug1: read PEM private key done: type RSA | debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 | debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 | debug1: private host key: #0 type 1 RSA | debug1: read PEM private key done: type DSA | debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 | debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 | debug1: private host key: #1 type 2 DSA | debug1: inetd sockets after dupping: 3, 3 | Connection from 192.168.2.101 port 55650 | debug1: Client protocol version 2.0; client software version OpenSSH_6.0p1 Debian-4 | debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH* | debug1: Enabling compatibility mode for protocol 2.0 | debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze3 | debug1: permanently_set_uid: 101/65534 | debug1: list_hostkey_types: ssh-rsa,ssh-dss | debug1: SSH2_MSG_KEXINIT sent | debug1: SSH2_MSG_KEXINIT received | debug1: kex: client-server aes128-ctr hmac-md5 none | debug1: kex: server-client aes128-ctr hmac-md5 none | debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received | debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent | debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT | debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent | debug1: SSH2_MSG_NEWKEYS sent | debug1: expecting SSH2_MSG_NEWKEYS | debug1: SSH2_MSG_NEWKEYS received | debug1: KEX done | debug1: userauth-request for user root service ssh-connection method none | debug1: attempt 0 failures 0 | debug1: PAM: initializing for root | debug1: PAM: setting PAM_RHOST to 192.168.2.101 | debug1: PAM: setting PAM_TTY to ssh | Failed none for root from 192.168.2.101 port 55650 ssh2 | debug1: userauth-request for user root service ssh-connection method publickey | debug1: attempt 1 failures 0 | debug1: test whether pkalg/pkblob are acceptable | debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 | debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 | debug1: temporarily_use_uid: 0/0 (e=0/0) | debug1: trying public key file /root/.ssh/authorized_keys | debug1: fd 4 clearing O_NONBLOCK | debug1: matching key found: file /root/.ssh/authorized_keys, line 1 | Found matching RSA key: 47:7c:14:dd:25:54:14:0d:d8:cf:c5:24:44:d4:7b:c2 | debug1: restore_uid: 0/0 | Postponed publickey for root from 192.168.2.101 port 55650 ssh2 | debug1: userauth-request for user root service ssh-connection method publickey | debug1: attempt 2 failures 0 | debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 | debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 | debug1: temporarily_use_uid: 0/0 (e=0/0) | debug1: trying public key file /root/.ssh/authorized_keys | debug1: fd 4 clearing O_NONBLOCK | debug1: matching key found: file /root/.ssh/authorized_keys, line 1 | Found matching RSA key: 47:7c:14:dd:25:54:14:0d:d8:cf:c5:24:44:d4:7b:c2 | debug1: restore_uid: 0/0 | debug1: ssh_rsa_verify: signature correct | debug1: do_pam_account: called | Accepted publickey for root from 192.168.2.101 port 55650 ssh2 | debug1: monitor_child_preauth: root has been authenticated by privileged process
Re: Why does my ssh session terminate immediately?
Hi Bob, Guido, and Vincent Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-22 22:49:23 +0200, Andreas Leha wrote: thanks for that. Here is what I get: , | + '[' -z '' ']' | + return | Connection to 192.168.2.109 closed. ` You said earlier: (I can, for instance, run a crippled bash with 'ssh root@192.168.2.109 bash') So, perhaps that's the -t which is a problem. What if you run 'ssh -t root@192.168.2.109 bash'? Thanks for all the follow-ups on this matter. I will try all your suggestions and report back. Unfortunately, this will happen in about 12 hours only, since I have no access to that network right now. I can access the files, but thanks for the suggestion of sftp, which did not occur to me. I think I have tried the 'ssh -t' but I don't recall the effect I saw. More on that when I tried it. Regards, Andreas -- 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/87ehe17caj@med.uni-goettingen.de
Re: Why does my ssh session terminate immediately?
Guido Martínez mtzgu...@gmail.com writes: Hi, On Mon, Apr 22, 2013 at 5:49 PM, Andreas Leha andreas.l...@med.uni-goettingen.de wrote: thanks for that. Here is what I get: , | + '[' -z '' ']' | + return | Connection to 192.168.2.109 closed. ` I guess that means, that PS1 is unset in this case? Looks like it, but I think that it shouldn't terminate bash anyway. The 'return' you see is local to .bashrc or whatever file was being loaded. Try running 'ssh root@192.168.2.109 bash --norc --noprofile -i' and see if you get a shell. If you do, it would suggest some misconfiguration of bash but from what I can see your configs are OK.. Here is what I get: , | ssh root@192.168.2.109 bash --norc --noprofile -i | bash: cannot set terminal process group (-1): Invalid argument | bash: no job control in this shell ` or: , | ssh -t root@192.168.2.109 bash --norc --noprofile -i | Connection to 192.168.2.109 closed. ` Regards, Andreas -- 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/87txmxx8mj@med.uni-goettingen.de
Re: Why does my ssh session terminate immediately?
Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-22 22:49:23 +0200, Andreas Leha wrote: thanks for that. Here is what I get: , | + '[' -z '' ']' | + return | Connection to 192.168.2.109 closed. ` You said earlier: (I can, for instance, run a crippled bash with 'ssh root@192.168.2.109 bash') So, perhaps that's the -t which is a problem. What if you run 'ssh -t root@192.168.2.109 bash'? Here is what I get: , | ssh -t root@192.168.2.109 bash | Connection to 192.168.2.109 closed. ` Regards, Andreas -- 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/87ppxlx8iw@med.uni-goettingen.de
Re: Why does my ssh session terminate immediately?
Hi Vincent, Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-24 00:24:16 +0200, Vincent Lefevre wrote: On 2013-04-23 23:05:27 +0200, Andreas Leha wrote: Here is what I get: , | ssh -t root@192.168.2.109 bash | Connection to 192.168.2.109 closed. ` So, it seems that the problem comes from the -t. Perhaps it can't allocate a pseudo-tty? Looks like, I agree. How can I tackle this? BTW, does ssh -t localhost work on both machines? I am not sure. On the 'client' it does. On the 'server' I get this: , | ssh root@192.168.2.109 bash | ssh -t localhost | Pseudo-terminal will not be allocated because stdin is not a terminal. | Host key verification failed. ` Things you can also try: ssh -t root@192.168.2.109 echo 'TERM: $TERM' and try from another terminal. Depending on the terminal I get: , | ssh -t root@192.168.2.109 echo 'TERM: $TERM' | TERM: screen | Connection to 192.168.2.109 closed. ` , | ssh -t root@192.168.2.109 echo 'TERM: $TERM' | TERM: rxvt-unicode | Connection to 192.168.2.109 closed. ` , | ssh -t root@192.168.2.109 echo 'TERM: $TERM' | TERM: linux | Connection to 192.168.2.109 closed. ` Do you have anything special in your .ssh/config? I do have many entries for different machines in my .ssh/config. The one for this is: , | Host pogo | HostName 192.168.2.109 | User root | IdentityFile /home/andreas/.ssh/id_rsa ` The other entries look similar, thus, should not interfere, I think. Thanks for all your effort! Regards, Andreas -- 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/87ip3cy6hy@med.uni-goettingen.de
Why does my ssh session terminate immediately?
Hi all, Short Version: I have the problem that my ssh session terminates immediately after logging in. Longer Version: I am running debian squeeze on a client and on a 'server'. The server is actually a pogoplug on which I installed debian squeeze following http://projects.doozan.com/debian/. I can not get an interactive shell when logging in to the server via ssh. This happens on the root account as well as a normal user account and regardless whether I authenticate via password or via keys. This is what I see: , | ssh root@192.168.2.109 | Linux debian 2.6.32-5-kirkwood #1 Sun May 6 16:57:51 UTC 2012 armv5tel | | The programs included with the Debian GNU/Linux system are free software; | the exact distribution terms for each program are described in the | individual files in /usr/share/doc/*/copyright. | | Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent | permitted by applicable law. | Last login: Wed Apr 17 21:54:34 2013 from 192.168.2.101 | Connection to 192.168.2.109 closed. ` I can run commands via ssh, though. (I can, for instance, run a crippled bash with 'ssh root@192.168.2.109 bash') I do not see any reason for this problem. Below you find the contents of some relevant files as well as the output of 'ssh -vvv'. Any pointers to what could be the problem here are much appreciated! Please let me know if I should provide more information. Thanks in advance, Andreas Attachments: - output of 'ssh -vvv' - root's ~/.bashrc - root's ~/.profile - /etc/profile - /etc/bash.bashrc - *no* logfile, is I only have these files in /var/log: - alternatives.log - apt - boot - bootstrap.log - btmp - dmesg - dmesg.0 - dmesg.1.gz - dmesg.2.gz - dmesg.3.gz - dmesg.4.gz - dpkg.log - faillog - fsck - lastlog - wtmp ,[ ssh -vvv root@192.168.2.109 ] | OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013 | debug1: Reading configuration data /home/andreas/.ssh/config | debug1: Reading configuration data /etc/ssh/ssh_config | debug1: /etc/ssh/ssh_config line 19: Applying options for * | debug2: ssh_connect: needpriv 0 | debug1: Connecting to 192.168.2.109 [192.168.2.109] port 22. | debug1: Connection established. | debug3: Incorrect RSA1 identifier | debug3: Could not load /home/andreas/.ssh/id_rsa as a RSA1 public key | debug1: identity file /home/andreas/.ssh/id_rsa type 1 | debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 | debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 | debug1: identity file /home/andreas/.ssh/id_rsa-cert type -1 | debug1: identity file /home/andreas/.ssh/id_dsa type -1 | debug1: identity file /home/andreas/.ssh/id_dsa-cert type -1 | debug1: identity file /home/andreas/.ssh/id_ecdsa type -1 | debug1: identity file /home/andreas/.ssh/id_ecdsa-cert type -1 | debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze3 | debug1: match: OpenSSH_5.5p1 Debian-6+squeeze3 pat OpenSSH_5* | debug1: Enabling compatibility mode for protocol 2.0 | debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4 | debug2: fd 3 setting O_NONBLOCK | debug3: load_hostkeys: loading entries for host 192.168.2.109 from file /home/andreas/.ssh/known_hosts | debug3: load_hostkeys: found key type RSA in file /home/andreas/.ssh/known_hosts:26 | debug3: load_hostkeys: loaded 1 keys | debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa | debug1: SSH2_MSG_KEXINIT sent | debug1: SSH2_MSG_KEXINIT received | debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 | debug2: kex_parse_kexinit: ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss | debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se | debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se | debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 | debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 | debug2: kex_parse_kexinit: none,z...@openssh.com,zlib | debug2: kex_parse_kexinit: none,z...@openssh.com,zlib | debug2:
Re: Why does my ssh session terminate immediately?
Hi Jochen, thanks for taking this up. Jochen Spieker m...@well-adjusted.de writes: Andreas Leha: Short Version: I have the problem that my ssh session terminates immediately after logging in. What's the users' shell on the server? It is the last column in /etc/passwd. Yes, sorry. I forgot to include that information. Both (root's and the normal user's) shell are set to bash. ,[ /etc/passwd ] | root:x:0:0:root:/root:/bin/bash | [...] | andreas:x:1000:1000:,,,:/home/andreas:/bin/bash ` I do not see any reason for this problem. Below you find the contents of some relevant files as well as the output of 'ssh -vvv'. Impressive! But I don't see a problem with these either. I do not like problems in general, but in this case that is a shame... All the Best, Andreas -- 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/87ppxm75xb@med.uni-goettingen.de
Re: Why does my ssh session terminate immediately?
Hi Bob, Bob Proulx b...@proulx.com writes: Andreas Leha wrote: I have the problem that my ssh session terminates immediately after logging in. I don't see a problem with the files you included. But I would still suspect a problem in there. To debug this I would try this: ssh -t root@192.168.2.109 bash -ix That should run bash similarly to your login but will trace the shell statements as they run. Hopefully at the very end you will see a clue as to why it is logging out. You can save this to a file like this: ssh -t root@192.168.2.109 bash -ix 21 | tee login.trace.out thanks for that. Here is what I get: , | + '[' -z '' ']' | + return | Connection to 192.168.2.109 closed. ` I guess that means, that PS1 is unset in this case? Regards, Andreas -- 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/87ip3e70ks@med.uni-goettingen.de
Re: start-stop-daemon on an inotify script
Hi Bob,
thanks a lot for stepping in and all your comments on the script and its
usage.
I did not want to have too much attention on my inotify script, so I
stripped it down to something simpler, that still is doing something
useful. It seems I failed in the simplification...
Bob Proulx b...@proulx.com writes:
Andreas Leha wrote:
No one?
Is there anything, I should add to the question?
Since no one else is jumping in...
Consider this stripped down script (placed at
/usr/local/bin/testinotify) around inotifywait:
#+begin_src sh
#!/bin/bash
You haven't used any bash specific features. I would use #!/bin/sh
and stay generic.
True. Will do.
WATCHDIR=/tmp/testinotify
inotifywait -mr --timefmt '%d/%m/%y %H:%M' --format '%T %w %f' \
-e modify -e create -e close_write \
Why both (modify|create) and close_write? You will get two lines for
every change that way. Why not just close_write?
Yes, you are right. I did not notice, as I do not actually run that
exact script.
$WATCHDIR | while read date time dir file; do
Note that by using a pipeline the while loop will occur within a
subshell. That is perfectly okay. But just remember that no
environment variables can be returned from it.
I do not see any alternative to that pipe. Setting up the recursive
watches takes some time, and I think the piping is the intended use of
inotifywait if put into monitoring mode.
Your comment, however, prompted me to play more with my script and this
subshell is indeed responsible for the tho 'instances' I am seeing.
FILECHANGE=${dir}${file}
Why split dir and file into two variables with the --format only to
immediately join them together again here?
True again. This also stems from my 'simplification'. In the longer
script, that I run, I need both.
chgrp users $FILECHANGE
chmod g+rw $FILECHANGE
if [ -d $FILECHANGE ]; then
chmod g+x $FILECHANGE
fi
See the 'X' (capital X) mode. Instead of the above to this:
chgrp users $FILECHANGE
chmod g+rwX $FILECHANGE
The documentation says:
$ info -f coreutils --index-search 'Conditional Executability'
27.2.4 Conditional Executability
There is one more special type of symbolic permission: if you use `X'
instead of `x', execute/search permission is affected only if the file
is a directory or already had execute permission.
For example, this mode:
a+X
gives all users permission to search directories, or to execute files if
anyone could execute them before.
That I did not know, indeed. Thanks for that.
echo At ${time} on ${date}, file $FILECHANGE was chmodded $1
done
#+end_src
If I run this by hand via
testinotify /var/log/testinotify.log
everything works as expected.
Here is my question: If I run this via start-stop-daemon as in
PIDFILE=/var/run/testinotify.pid DAEMON=/usr/local/bin/testinotify
LOGFILE=/var/log/testinotify.log start-stop-daemon --start --quiet
--oknodo --pidfile $PIDFILE --make-pidfile --startas $DAEMON -- $LOGFILE
Please, my eyes, my eyes! Think of the kittens. :-)
Why are you chaining those together into a long compound command? Why
Of course I do not intend to use it that way. I want to use
start-stop-daemon in an init script.
I just made it a one-liner to make it more copy-paste-able for the
readers of this list.
I could have sent my init script. But then the attention would have
been on my poor init-script-writing instead of the question on the
behaviour of start-stop-daemon.
are you putting it in the background? What will your script do with
the $LOGFILE argument? It looks like it will do nothing with it to
me. Yes, yes, I know. If you knew those answers you wouldn't have
written it that way. :-)
Here again, the LOGFILE was used in my original script and while stripping
the script I did not revise that command line.
Try this instead. Because if a variable assignment fails then you
don't have an effective way of dealing with it. so might as well make
it more readable instead. Plus a completely new set of options to
start-stop-daemon. Plus there won't be collisions with other
variables if you use lower case names.
pidfile=/var/run/testinotify.pid
daemon=/usr/local/bin/testinotify
logfile=/var/log/testinotify.log
start-stop-daemon --start --quiet --background \
--pidfile $pidfile --make-pidfile \
--exec $daemon -- $logfile
And then modify your script to take a logfile argument. The part
after the -- part above is passed to your script. Your script isn't
currently doing anything with it. I lack the time to write something
up about it right now.
Hint: I would test for the presence and then just redirect everything
off to it. All output after this statement will be redirected to the
specified file.
exec $logfile 21 /dev/null
Thanks. Very handy. I do
Re: start-stop-daemon on an inotify script
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Hi all,
(cross-post from here:
http://superuser.com/questions/571416/start-stop-daemon-on-an-inotify-scripti)
I am on debian squeeze.
Consider this stripped down script (placed at
/usr/local/bin/testinotify) around inotifywait:
#+begin_src sh
#!/bin/bash
WATCHDIR=/tmp/testinotify
inotifywait -mr --timefmt '%d/%m/%y %H:%M' --format '%T %w %f' \
-e modify -e create -e close_write \
$WATCHDIR | while read date time dir file; do
FILECHANGE=${dir}${file}
chgrp users $FILECHANGE
chmod g+rw $FILECHANGE
if [ -d $FILECHANGE ]; then
chmod g+x $FILECHANGE
fi
echo At ${time} on ${date}, file $FILECHANGE was chmodded $1
done
#+end_src
If I run this by hand via
testinotify /var/log/testinotify.log
everything works as expected.
Here is my question: If I run this via start-stop-daemon as in
PIDFILE=/var/run/testinotify.pid
DAEMON=/usr/local/bin/testinotify LOGFILE=/var/log/testinotify.log
start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE
--make-pidfile --startas $DAEMON -- $LOGFILE
I get two instances of my script running.
Why is that and how can I avoid that?
The bad effect is, that killing the process with pid recorded by
start-stop-script is not even stopping the inotifywait.
Regards,
Andreas
No one?
Is there anything, I should add to the question?
- Andreas
--
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/878v4tkwux@med.uni-goettingen.de
start-stop-daemon on an inotify script
Hi all,
(cross-post from here:
http://superuser.com/questions/571416/start-stop-daemon-on-an-inotify-scripti)
I am on debian squeeze.
Consider this stripped down script (placed at
/usr/local/bin/testinotify) around inotifywait:
#+begin_src sh
#!/bin/bash
WATCHDIR=/tmp/testinotify
inotifywait -mr --timefmt '%d/%m/%y %H:%M' --format '%T %w %f' \
-e modify -e create -e close_write \
$WATCHDIR | while read date time dir file; do
FILECHANGE=${dir}${file}
chgrp users $FILECHANGE
chmod g+rw $FILECHANGE
if [ -d $FILECHANGE ]; then
chmod g+x $FILECHANGE
fi
echo At ${time} on ${date}, file $FILECHANGE was chmodded $1
done
#+end_src
If I run this by hand via
testinotify /var/log/testinotify.log
everything works as expected.
Here is my question: If I run this via start-stop-daemon as in
PIDFILE=/var/run/testinotify.pid DAEMON=/usr/local/bin/testinotify
LOGFILE=/var/log/testinotify.log start-stop-daemon --start --quiet --oknodo
--pidfile $PIDFILE --make-pidfile --startas $DAEMON -- $LOGFILE
I get two instances of my script running.
Why is that and how can I avoid that?
The bad effect is, that killing the process with pid recorded by
start-stop-script is not even stopping the inotifywait.
Regards,
Andreas
--
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/87mwtqzgw4@med.uni-goettingen.de
