[Vserver] Proc Security in V2.0
Hi there, Quote http://linux-vserver.org/Proc-Security: "Default flagging As of now stable defaults to all proc entries visible everywhere, development and experimental versions default to all proc entries only visible in context 0." It seems like this is still valid for vs2.0 stable, although I would expect it to change to all proc entries hidden. At least that would be the logic of having the vprocunhide utility and the default limiting settings in vprocunhide-files (?) At least all proc entries are visible by default on my first vs2.0 Might I be missing something here? This is a Gentoo host and vserver, using the portage ebuilds for sources and the vserver-new command to make the first vserver. Util-vserver is 208. Best regards, Tor Rune Skoglund ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Proc Security in V2.0
On Fri, Sep 09, 2005 at 11:29:32PM +0200, Tor Rune Skoglund wrote: > Hi there, > > Quote http://linux-vserver.org/Proc-Security: > > "Default flagging > As of now stable defaults to all proc entries visible everywhere, > development and experimental versions default to all proc entries only > visible in context 0." thanks, updated that ... > It seems like this is still valid for vs2.0 stable, although I > would expect it to change to all proc entries hidden. (from the 2.0 patches) config VSERVER_PROC_SECURE bool"Enable Proc Security" depends on PROC_FS default y help This configures ProcFS security to initially hide non-process entries for all contexts except the main and spectator context (i.e. for all guests), which is a secure default. so we now default to enable the proc security, hiding most entries by default ... > At least that would be the logic of having the > vprocunhide utility and the default limiting settings in > vprocunhide-files (?) > > At least all proc entries are visible by default on my first > vs2.0 Might I be missing something here? well, what patch/kernel? (testme.sh) and more improtant what kernel config? > This is a Gentoo host and vserver, using the portage > ebuilds for sources and the vserver-new command to > make the first vserver. Util-vserver is 208. maybe the gentoo default is wrong? Hollow? best, Herbert > Best regards, > Tor Rune Skoglund > ___ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Proc Security in V2.0
Lørdag 10 september 2005 19:18, skrev Herbert Poetzl: > On Fri, Sep 09, 2005 at 11:29:32PM +0200, Tor Rune Skoglund wrote: > > "Default flagging > > As of now stable defaults to all proc entries visible everywhere, > > development and experimental versions default to all proc entries only > > visible in context 0." > > config VSERVER_PROC_SECURE > > so we now default to enable the proc security, hiding > most entries by default ... Yes, that might have been it. I emerged the 2.6.13 vs2.0 kernel sources, recompiled the kernel, and now it works as expected. Silly me, I didn't save the old .config and cannot tell whether PROC_SECURE was the missing link or not. It's a bit strange though - I _thing_ did check that before the kernel compile, but we'll never know for sure... Other pecularities are: - I always get "A timeout occured while waiting for the vserver to finish and it was killed by sending a SIGKILL signal. Please investigate the reasons and/or increase the timeout in apps/vshelper/sync-timeout." on vserver xxx stop. I'm not sure how to debug this. Increasing the timeout didn't help, and I didn't expect it to either - There seems to be problem with the gentoo init.d and/or util-vserver's start-vservers script: (I have edited the init script to see what actually was executed) linuxserver ~ # /etc/init.d/vservers start * Starting vservers of type 'default' ... /usr/lib/util-vserver/start-vservers -m default -j 1 --all --start [ ok ] linuxserver ~ # vserver-stat CTX PROCVSZRSS userTIME sysTIMEUPTIME NAME 0 100 1.9G 0.9G 17m11s21 4m12s17 3h24m27 root server 100 3 6.9M 2.7M 0m01s46 0m01s56 0m50s72 templategentoo linuxserver ~ # /etc/init.d/vservers stop * Stopping all vservers ... /usr/lib/util-vserver/start-vservers -j 1 --all --stop [ ok ] linuxserver ~ # vserver-stat CTX PROCVSZRSS userTIME sysTIMEUPTIME NAME 0 100 1.9G 0.9G 17m11s49 4m12s37 3h24m48 root server 100 3 6.9M 2.7M 0m01s46 0m01s56 1m11s72 templategentoo linuxserver ~ # Vserver still running after start-vserver --all --stop. Removing STOP_ALL in /etc/conf.d/vservers so that it just stops all vserver with mark 'default' did help, but anyway I think --all --stop should work on "marked" vservers also. Anyway, thanks for the help. Best regards, Tor Rune Skoglund ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Proc Security in V2.0
On Sat, Sep 10, 2005 at 08:06:48PM +0200, Tor Rune Skoglund wrote: > Lørdag 10 september 2005 19:18, skrev Herbert Poetzl: > > On Fri, Sep 09, 2005 at 11:29:32PM +0200, Tor Rune Skoglund wrote: > > > "Default flagging > > > As of now stable defaults to all proc entries visible everywhere, > > > development and experimental versions default to all proc entries only > > > visible in context 0." > > > > config VSERVER_PROC_SECURE > > > > so we now default to enable the proc security, hiding > > most entries by default ... > > Yes, that might have been it. I emerged the 2.6.13 > vs2.0 kernel sources, recompiled the kernel, and > now it works as expected. > > Silly me, I didn't save the old .config and cannot tell > whether PROC_SECURE was the missing link or not. > It's a bit strange though - I _thing_ did check that before > the kernel compile, but we'll never know for sure... > > Other pecularities are: > > - I always get > > "A timeout occured while waiting for the vserver to finish and it was > killed by sending a SIGKILL signal. Please investigate the reasons > and/or increase the timeout in apps/vshelper/sync-timeout." > > on vserver xxx stop. I'm not sure how to debug this. > Increasing the timeout didn't help, and I didn't expect it to either well, for some reason the guest has still programs running after a shutdown, best check with 'vps auxwww' and look for processes inside your guest (while waiting for the timeout to occur) > - There seems to be problem with the gentoo init.d and/or > util-vserver's start-vservers script: (I have edited the init script > to see what actually was executed) > > linuxserver ~ # /etc/init.d/vservers start > * Starting vservers of type 'default' ... > /usr/lib/util-vserver/start-vservers -m default -j 1 --all --start > > [ ok ] > linuxserver ~ # vserver-stat > CTX PROCVSZRSS userTIME sysTIMEUPTIME NAME > 0 100 1.9G 0.9G 17m11s21 4m12s17 3h24m27 root server > 100 3 6.9M 2.7M 0m01s46 0m01s56 0m50s72 templategentoo > linuxserver ~ # /etc/init.d/vservers stop > * Stopping all vservers ... > /usr/lib/util-vserver/start-vservers -j 1 --all --stop > > [ ok ] > linuxserver ~ # vserver-stat > CTX PROCVSZRSS userTIME sysTIMEUPTIME NAME > 0 100 1.9G 0.9G 17m11s49 4m12s37 3h24m48 root server > 100 3 6.9M 2.7M 0m01s46 0m01s56 1m11s72 templategentoo > linuxserver ~ # > > Vserver still running after start-vserver --all --stop. > > Removing STOP_ALL in /etc/conf.d/vservers so that > it just stops all vserver with mark 'default' did help, but anyway > I think --all --stop should work on "marked" vservers also. did you already file a bugreport on savannah? best, Herbert > Anyway, thanks for the help. > > Best regards, > Tor Rune Skoglund > ___ > Vserver mailing list > Vserver@list.linux-vserver.org > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Proc Security in V2.0
Søndag 11 september 2005 04:08, skrev Herbert Poetzl: > > "A timeout occured while waiting for the vserver to finish and it was > > killed by sending a SIGKILL signal. Please investigate the reasons > > and/or increase the timeout in apps/vshelper/sync-timeout." > > > > on vserver xxx stop. I'm not sure how to debug this. > > well, for some reason the guest has still programs > running after a shutdown, best check with 'vps auxwww' > and look for processes inside your guest (while waiting > for the timeout to occur) OK, you experts have a look at this: First, minimizing the processes in the vserver to: templategentoo / # ps ax PID TTY STAT TIME COMMAND 1 ?S 0:00 init [3] 17335 pts/1S 0:00 /bin/bash -login 17429 pts/1R+ 0:00 ps ax templategentoo / # Then checking vps on the host: linuxserver ~ # vps auxwww | grep 100 root 1008 0 MAIN 0.0 0.0 1444 468 ?S > /usr/lib/util-vserver/start-vservers -j 1 --all --stop > > [ ok ] > > linuxserver ~ # vserver-stat > > CTX PROCVSZRSS userTIME sysTIMEUPTIME NAME > > 0 100 1.9G 0.9G 17m11s49 4m12s37 3h24m48 root server > > 100 3 6.9M 2.7M 0m01s46 0m01s56 1m11s72 templategentoo > > > > Vserver still running after start-vserver --all --stop. > > did you already file a bugreport on savannah? Yes, now. Best regards, Tor Rune Skoglund ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] Proc Security in V2.0
On Tue, Sep 13, 2005 at 11:39:10PM +0200, Tor Rune Skoglund wrote: > Søndag 11 september 2005 04:08, skrev Herbert Poetzl: > > > "A timeout occured while waiting for the vserver to finish and it was > > > killed by sending a SIGKILL signal. Please investigate the reasons > > > and/or increase the timeout in apps/vshelper/sync-timeout." > > > > > > on vserver xxx stop. I'm not sure how to debug this. > > > > well, for some reason the guest has still programs > > running after a shutdown, best check with 'vps auxwww' > > and look for processes inside your guest (while waiting > > for the timeout to occur) > > OK, you experts have a look at this: > > First, minimizing the processes in the vserver to: > > templategentoo / # ps ax > PID TTY STAT TIME COMMAND > 1 ?S 0:00 init [3] > 17335 pts/1S 0:00 /bin/bash -login > 17429 pts/1R+ 0:00 ps ax > templategentoo / # > > Then checking vps on the host: > > linuxserver ~ # vps auxwww | grep 100 > root 1008 0 MAIN 0.0 0.0 1444 468 ?S 0:00 udevd > root 16616 100 templategentoo 0.0 0.0 1464 496 ?Ss > 23:17 > 0:00 init [3] > root 17335 100 templategentoo 0.0 0.1 2328 1368 pts/1S+ > 23:17 > 0:00 /bin/bash -login > root 17460 0 MAIN 0.0 0.0 1484 452 pts/8S+ 23:20 > 0:00 grep 100 > > Stopping the vserver from the host: > > linuxserver ~ # vserver templategentoo stop > A timeout occured while waiting for the vserver to finish and it was > killed by sending a SIGKILL signal. Please investigate the reasons > and/or increase the timeout in apps/vshelper/sync-timeout. > > Before that timeout arrives, checking vps repeatedly from the host: > > linuxserver ~ # vps auxwww | grep 100 > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > 0:00 udevd > root 16616 100 templategentoo 0.0 0.0 1464 496 ?Ss > 23:17 > 0:00 init [3] > root 17335 100 templategentoo 0.0 0.1 2328 1368 pts/1S+ > 23:17 > 0:00 /bin/bash -login > root 17556 0 MAIN 0.0 0.010828 pts/6S+ 23:20 > > 0:00 /usr/sbin/vwait --timeout 20 --terminate --status-fd 3 100 > root 17612 0 MAIN 0.0 0.0 1484 448 pts/8S+ 23:20 > > 0:00 grep 100 > > vwait just waits 20 seconds, and then the vserver is killed. > > So I checked to see if it stops the services gracefully first: It doesn't. It > just > goes into that timeout directly without the stopping the init.d scripts: > > linuxserver ~ # vps auxwww | grep 100 > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > 0:00 udevd > root 17832 100 templategentoo 0.0 0.0 1468 500 ?Ss > 23:29 > 0:00 init [3] > root 18403 100 templategentoo 0.0 0.0 1712 664 ?Ss > 23:29 > 0:00 /usr/sbin/syslog-ng > root 18499 100 templategentoo 0.0 0.1 3944 1644 ?Ss > 23:29 > 0:00 /usr/sbin/sshd > root 18522 100 templategentoo 0.0 0.3 7652 3296 ?Ss > 23:29 > 0:00 /usr/sbin/apache2 -k start > apache 18558 100 templategentoo 0.0 0.3 7596 3252 ?S > 23:29 > 0:00 /usr/sbin/apache2 -k start > apache 18559 100 templategentoo 0.0 0.3 7788 3336 ?S > 23:29 > 0:00 /usr/sbin/apache2 -k start > apache 18560 100 templategentoo 0.0 0.3 7788 3336 ?S > 23:29 > 0:00 /usr/sbin/apache2 -k start > apache 18561 100 templategentoo 0.0 0.3 7788 3336 ?S > 23:29 > 0:00 /usr/sbin/apache2 -k start > apache 18562 100 templategentoo 0.0 0.3 7788 3336 ?S > 23:29 > 0:00 /usr/sbin/apache2 -k start > apache 18563 100 templategentoo 0.0 0.3 7788 3336 ?S > 23:29 > 0:00 /usr/sbin/apache2 -k start > root 18608 0 MAIN 0.0 0.010424 pts/6S+ 23:29 > > 0:00 /usr/sbin/vwait --timeout 20 --terminate --status-fd 3 100 > root 18706 0 MAIN 0.0 0.0 1488 452 pts/8S+ 23:29 > > 0:00 grep 100 > > Sorry, I have no clue here... This might be a gentoo problem or something > with the init-style (which is 'plain') --- I don't know. could you also add the output of testme.sh (http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh) to this information? TIA, Herbert > More info: > linuxserver ~ # uname -a > Linux linuxserver 2.6.13-vs2.1.0-pre5-gentoo #1 Sat Sep 10 16:25:41 CEST 2005 > i686 AMD Duron(tm) processor AuthenticAMD GNU/Linux > linuxserver ~ # vserver-info > Versions: >Kernel: 2.6.13-vs2.1.0-pre5-gentoo >VS-API: 0x00020001 > util-vserver: 0.30.208; Aug 31 2005, 22:13:08 > > Features: >CC: i386-pc-linux-gnu-gcc, i386-pc-linux-gnu-gcc (GCC) > 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1) > CXX: i386-pc-lin
Re: [Vserver] Proc Security in V2.0
linuxserver ~ # ./vserver-oppsett/testme.sh Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl chcontext is working. chbind is working. Linux 2.6.13-vs2.1.0-pre5-gentoo i686/0.30.208/0.30.208 [Ea] (0) VCI: 0002:0001 273 03110036 --- [000]# succeeded. [001]# succeeded. [011]# succeeded. [031]# succeeded. [101]# succeeded. [102]# succeeded. [201]# succeeded. [202]# succeeded. Onsdag 14 september 2005 00:56, skrev Herbert Poetzl: > On Tue, Sep 13, 2005 at 11:39:10PM +0200, Tor Rune Skoglund wrote: > > Søndag 11 september 2005 04:08, skrev Herbert Poetzl: > > > > "A timeout occured while waiting for the vserver to finish and it was > > > > killed by sending a SIGKILL signal. Please investigate the reasons > > > > and/or increase the timeout in apps/vshelper/sync-timeout." > > > > > > > > on vserver xxx stop. I'm not sure how to debug this. > > > > > > well, for some reason the guest has still programs > > > running after a shutdown, best check with 'vps auxwww' > > > and look for processes inside your guest (while waiting > > > for the timeout to occur) > > > > OK, you experts have a look at this: > > > > First, minimizing the processes in the vserver to: > > > > templategentoo / # ps ax > > PID TTY STAT TIME COMMAND > > 1 ?S 0:00 init [3] > > 17335 pts/1S 0:00 /bin/bash -login > > 17429 pts/1R+ 0:00 ps ax > > templategentoo / # > > > > Then checking vps on the host: > > > > linuxserver ~ # vps auxwww | grep 100 > > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > Sep11 > > 0:00 udevd > > root 16616 100 templategentoo 0.0 0.0 1464 496 ?Ss > > 23:17 > > 0:00 init [3] > > root 17335 100 templategentoo 0.0 0.1 2328 1368 pts/1S+ > > 23:17 > > 0:00 /bin/bash -login > > root 17460 0 MAIN 0.0 0.0 1484 452 pts/8S+ > > 23:20 > > 0:00 grep 100 > > > > Stopping the vserver from the host: > > > > linuxserver ~ # vserver templategentoo stop > > A timeout occured while waiting for the vserver to finish and it was > > killed by sending a SIGKILL signal. Please investigate the reasons > > and/or increase the timeout in apps/vshelper/sync-timeout. > > > > Before that timeout arrives, checking vps repeatedly from the host: > > > > linuxserver ~ # vps auxwww | grep 100 > > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > Sep11 > > 0:00 udevd > > root 16616 100 templategentoo 0.0 0.0 1464 496 ?Ss > > 23:17 > > 0:00 init [3] > > root 17335 100 templategentoo 0.0 0.1 2328 1368 pts/1S+ > > 23:17 > > 0:00 /bin/bash -login > > root 17556 0 MAIN 0.0 0.010828 pts/6S+ > > 23:20 > > 0:00 /usr/sbin/vwait --timeout 20 --terminate --status-fd 3 100 > > root 17612 0 MAIN 0.0 0.0 1484 448 pts/8S+ > > 23:20 > > 0:00 grep 100 > > > > vwait just waits 20 seconds, and then the vserver is killed. > > > > So I checked to see if it stops the services gracefully first: It doesn't. > > It > > just > > goes into that timeout directly without the stopping the init.d scripts: > > > > linuxserver ~ # vps auxwww | grep 100 > > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > Sep11 > > 0:00 udevd > > root 17832 100 templategentoo 0.0 0.0 1468 500 ?Ss > > 23:29 > > 0:00 init [3] > > root 18403 100 templategentoo 0.0 0.0 1712 664 ?Ss > > 23:29 > > 0:00 /usr/sbin/syslog-ng > > root 18499 100 templategentoo 0.0 0.1 3944 1644 ?Ss > > 23:29 > > 0:00 /usr/sbin/sshd > > root 18522 100 templategentoo 0.0 0.3 7652 3296 ?Ss > > 23:29 > > 0:00 /usr/sbin/apache2 -k start > > apache 18558 100 templategentoo 0.0 0.3 7596 3252 ?S > > 23:29 > > 0:00 /usr/sbin/apache2 -k start > > apache 18559 100 templategentoo 0.0 0.3 7788 3336 ?S > > 23:29 > > 0:00 /usr/sbin/apache2 -k start > > apache 18560 100 templategentoo 0.0 0.3 7788 3336 ?S > > 23:29 > > 0:00 /usr/sbin/apache2 -k start > > apache 18561 100 templategentoo 0.0 0.3 7788 3336 ?S > > 23:29 > > 0:00 /usr/sbin/apache2 -k start > > apache 18562 100 templategentoo 0.0 0.3 7788 3336 ?S > > 23:29 > > 0:00 /usr/sbin/apache2 -k start > > apache 18563 100 templategentoo 0.0 0.3 7788 3336 ?S > > 23:29 > > 0:00 /usr/sbin/apache2 -k start > > root 18608 0 MAIN 0.0 0.010424 pts/6S+ > > 23:29 > > 0:00 /usr/sbin/vwait --timeout 20 --terminate --status-fd 3 100 > > root 18706 0 MAIN 0.0 0.0 1488 452 pts/8S+ > > 23:29 > > 0:00 grep 100 > > > > Sorry, I have no clue here... This might be a gentoo problem or something > > with the init-style (which is 'plain') --- I don't know. > > could you also ad
Re: [Vserver] Proc Security in V2.0
On Wed, Sep 14, 2005 at 09:52:58AM +0200, Tor Rune Skoglund wrote: > linuxserver ~ # ./vserver-oppsett/testme.sh > Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl > chcontext is working. > chbind is working. > Linux 2.6.13-vs2.1.0-pre5-gentoo i686/0.30.208/0.30.208 [Ea] (0) > VCI: 0002:0001 273 03110036 > --- > [000]# succeeded. > [001]# succeeded. > [011]# succeeded. > [031]# succeeded. > [101]# succeeded. > [102]# succeeded. > [201]# succeeded. > [202]# succeeded. hmm ... not conclusive yet, if you are interested in tracking down this issue, you might pay a visit to the irc channel #vserver @ irc.oftc.net best, Herbert > Onsdag 14 september 2005 00:56, skrev Herbert Poetzl: > > On Tue, Sep 13, 2005 at 11:39:10PM +0200, Tor Rune Skoglund wrote: > > > Søndag 11 september 2005 04:08, skrev Herbert Poetzl: > > > > > "A timeout occured while waiting for the vserver to finish and it was > > > > > killed by sending a SIGKILL signal. Please investigate the reasons > > > > > and/or increase the timeout in apps/vshelper/sync-timeout." > > > > > > > > > > on vserver xxx stop. I'm not sure how to debug this. > > > > > > > > well, for some reason the guest has still programs > > > > running after a shutdown, best check with 'vps auxwww' > > > > and look for processes inside your guest (while waiting > > > > for the timeout to occur) > > > > > > OK, you experts have a look at this: > > > > > > First, minimizing the processes in the vserver to: > > > > > > templategentoo / # ps ax > > > PID TTY STAT TIME COMMAND > > > 1 ?S 0:00 init [3] > > > 17335 pts/1S 0:00 /bin/bash -login > > > 17429 pts/1R+ 0:00 ps ax > > > templategentoo / # > > > > > > Then checking vps on the host: > > > > > > linuxserver ~ # vps auxwww | grep 100 > > > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > > Sep11 > > > 0:00 udevd > > > root 16616 100 templategentoo 0.0 0.0 1464 496 ?Ss > > > 23:17 > > > 0:00 init [3] > > > root 17335 100 templategentoo 0.0 0.1 2328 1368 pts/1S+ > > > 23:17 > > > 0:00 /bin/bash -login > > > root 17460 0 MAIN 0.0 0.0 1484 452 pts/8S+ > > > 23:20 > > > 0:00 grep 100 > > > > > > Stopping the vserver from the host: > > > > > > linuxserver ~ # vserver templategentoo stop > > > A timeout occured while waiting for the vserver to finish and it was > > > killed by sending a SIGKILL signal. Please investigate the reasons > > > and/or increase the timeout in apps/vshelper/sync-timeout. > > > > > > Before that timeout arrives, checking vps repeatedly from the host: > > > > > > linuxserver ~ # vps auxwww | grep 100 > > > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > > Sep11 > > > 0:00 udevd > > > root 16616 100 templategentoo 0.0 0.0 1464 496 ?Ss > > > 23:17 > > > 0:00 init [3] > > > root 17335 100 templategentoo 0.0 0.1 2328 1368 pts/1S+ > > > 23:17 > > > 0:00 /bin/bash -login > > > root 17556 0 MAIN 0.0 0.010828 pts/6S+ > > > 23:20 > > > 0:00 /usr/sbin/vwait --timeout 20 --terminate --status-fd 3 100 > > > root 17612 0 MAIN 0.0 0.0 1484 448 pts/8S+ > > > 23:20 > > > 0:00 grep 100 > > > > > > vwait just waits 20 seconds, and then the vserver is killed. > > > > > > So I checked to see if it stops the services gracefully first: It > > > doesn't. It > > > just > > > goes into that timeout directly without the stopping the init.d scripts: > > > > > > linuxserver ~ # vps auxwww | grep 100 > > > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > > Sep11 > > > 0:00 udevd > > > root 17832 100 templategentoo 0.0 0.0 1468 500 ?Ss > > > 23:29 > > > 0:00 init [3] > > > root 18403 100 templategentoo 0.0 0.0 1712 664 ?Ss > > > 23:29 > > > 0:00 /usr/sbin/syslog-ng > > > root 18499 100 templategentoo 0.0 0.1 3944 1644 ?Ss > > > 23:29 > > > 0:00 /usr/sbin/sshd > > > root 18522 100 templategentoo 0.0 0.3 7652 3296 ?Ss > > > 23:29 > > > 0:00 /usr/sbin/apache2 -k start > > > apache 18558 100 templategentoo 0.0 0.3 7596 3252 ?S > > > 23:29 > > > 0:00 /usr/sbin/apache2 -k start > > > apache 18559 100 templategentoo 0.0 0.3 7788 3336 ?S > > > 23:29 > > > 0:00 /usr/sbin/apache2 -k start > > > apache 18560 100 templategentoo 0.0 0.3 7788 3336 ?S > > > 23:29 > > > 0:00 /usr/sbin/apache2 -k start > > > apache 18561 100 templategentoo 0.0 0.3 7788 3336 ?S > > > 23:29 > > > 0:00 /usr/sbin/apache2 -k start > > > apache 18562 100 templategentoo 0.0 0.3 7788 3336 ?S > > > 23:29 > > > 0:00 /usr/sbin/apache2 -k start > > > apache 18563 100 templategentoo 0.0 0.3 7788 3336 ?S > > > 23:29
Re: [Vserver] Proc Security in V2.0
Onsdag 14 september 2005 16:22, skrev Herbert Poetzl: > On Wed, Sep 14, 2005 at 09:52:58AM +0200, Tor Rune Skoglund wrote: > > linuxserver ~ # ./vserver-oppsett/testme.sh > > Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl > > chcontext is working. > > chbind is working. > > Linux 2.6.13-vs2.1.0-pre5-gentoo i686/0.30.208/0.30.208 [Ea] (0) > > VCI: 0002:0001 273 03110036 > > --- > > [000]# succeeded. > > [001]# succeeded. > > [011]# succeeded. > > [031]# succeeded. > > [101]# succeeded. > > [102]# succeeded. > > [201]# succeeded. > > [202]# succeeded. > > hmm ... not conclusive yet, if you are interested in tracking > down this issue, you might pay a visit to the irc channel > #vserver @ irc.oftc.net Hello Herbert, OK, I can confirm that the problem is still there on a pre8 kernel. (uname btw says pre7...) No change, it might be some Gentoo specially somewhere, but finding this is beyond my capabilities... If you like, Herbert, I can give you ssh access to a server with a testinstalled server with the problem. Let me know by mail if you like to check it out. Best regards Tor Rune > > Onsdag 14 september 2005 00:56, skrev Herbert Poetzl: > > > On Tue, Sep 13, 2005 at 11:39:10PM +0200, Tor Rune Skoglund wrote: > > > > Søndag 11 september 2005 04:08, skrev Herbert Poetzl: > > > > > > "A timeout occured while waiting for the vserver to finish and it > > > > > > was > > > > > > killed by sending a SIGKILL signal. Please investigate the reasons > > > > > > and/or increase the timeout in apps/vshelper/sync-timeout." > > > > > > > > > > > > on vserver xxx stop. I'm not sure how to debug this. > > > > > > > > > > well, for some reason the guest has still programs > > > > > running after a shutdown, best check with 'vps auxwww' > > > > > and look for processes inside your guest (while waiting > > > > > for the timeout to occur) > > > > > > > > OK, you experts have a look at this: > > > > > > > > First, minimizing the processes in the vserver to: > > > > > > > > templategentoo / # ps ax > > > > PID TTY STAT TIME COMMAND > > > > 1 ?S 0:00 init [3] > > > > 17335 pts/1S 0:00 /bin/bash -login > > > > 17429 pts/1R+ 0:00 ps ax > > > > templategentoo / # > > > > > > > > Then checking vps on the host: > > > > > > > > linuxserver ~ # vps auxwww | grep 100 > > > > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > > > Sep11 > > > > 0:00 udevd > > > > root 16616 100 templategentoo 0.0 0.0 1464 496 ?Ss > > > > 23:17 > > > > 0:00 init [3] > > > > root 17335 100 templategentoo 0.0 0.1 2328 1368 pts/1S+ > > > > 23:17 > > > > 0:00 /bin/bash -login > > > > root 17460 0 MAIN 0.0 0.0 1484 452 pts/8S+ > > > > 23:20 > > > > 0:00 grep 100 > > > > > > > > Stopping the vserver from the host: > > > > > > > > linuxserver ~ # vserver templategentoo stop > > > > A timeout occured while waiting for the vserver to finish and it was > > > > killed by sending a SIGKILL signal. Please investigate the reasons > > > > and/or increase the timeout in apps/vshelper/sync-timeout. > > > > > > > > Before that timeout arrives, checking vps repeatedly from the host: > > > > > > > > linuxserver ~ # vps auxwww | grep 100 > > > > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > > > Sep11 > > > > 0:00 udevd > > > > root 16616 100 templategentoo 0.0 0.0 1464 496 ?Ss > > > > 23:17 > > > > 0:00 init [3] > > > > root 17335 100 templategentoo 0.0 0.1 2328 1368 pts/1S+ > > > > 23:17 > > > > 0:00 /bin/bash -login > > > > root 17556 0 MAIN 0.0 0.010828 pts/6S+ > > > > 23:20 > > > > 0:00 /usr/sbin/vwait --timeout 20 --terminate --status-fd 3 100 > > > > root 17612 0 MAIN 0.0 0.0 1484 448 pts/8S+ > > > > 23:20 > > > > 0:00 grep 100 > > > > > > > > vwait just waits 20 seconds, and then the vserver is killed. > > > > > > > > So I checked to see if it stops the services gracefully first: It > > > > doesn't. It > > > > just > > > > goes into that timeout directly without the stopping the init.d scripts: > > > > > > > > linuxserver ~ # vps auxwww | grep 100 > > > > root 1008 0 MAIN 0.0 0.0 1444 468 ?S > > > Sep11 > > > > 0:00 udevd > > > > root 17832 100 templategentoo 0.0 0.0 1468 500 ?Ss > > > > 23:29 > > > > 0:00 init [3] > > > > root 18403 100 templategentoo 0.0 0.0 1712 664 ?Ss > > > > 23:29 > > > > 0:00 /usr/sbin/syslog-ng > > > > root 18499 100 templategentoo 0.0 0.1 3944 1644 ?Ss > > > > 23:29 > > > > 0:00 /usr/sbin/sshd > > > > root 18522 100 templategentoo 0.0 0.3 7652 3296 ?Ss > > > > 23:29 > > > > 0:00 /usr/sbin/apache2 -k start > > > > apache 18558 100 templategentoo 0.0 0.3 7596 3252 ?S > > > > 23
