Hello! Sorry for the delay.. .micah hunted me so that I answer, so here i am. :)
On Thu, Jan 18, 2007 at 11:50:41PM +0100, intrigeri wrote:
> The Anarcat wrote (10 Jan 2007 18:38:48 GMT) :
> > I have had recurring problems deploying backupninja in vservers. Not
> > using the vservers = foo approach, mind you, but directly installing
> > backupninja in the vserver and configuring it.
>
> First, thanks for this throughly documented bug report :)
Glad it's useful.
> > An example is the duplicity handler. It calls duplicity using this
> > fragment:
>
> > output=`nice -n $nicelevel \
> > su -c \
> > "duplicity $execstr --exclude '**' /
> > $execstr_serverpart 2>&1"`
>
> > In other words:
>
> > nice su -c "ls"
>
> > This doesn't work on a vserver, even though su works:
>
> > [EMAIL PROTECTED]:~# nice su -c ls
> > su: Permission denied
> > [EMAIL PROTECTED]:~# su -c ls
> > [EMAIL PROTECTED]:~#
>
> > That is because the vserver isn't a "realtime" vserver (it can't raise
> > its processes priorities). An strace shows the problem fairly clearly:
>
> > ...
> > setpriority(PRIO_PROCESS, 0, 0) = -1 EACCES (Permission denied)
> > getpid() = 11777
> > rt_sigaction(SIGPIPE, {0x2aaaf6e824f0, [], 0x4000000}, {SIG_DFL}, 8) = 0
> > sendto(3, "<83>Jan 10 18:14:02 su[11777]: p"..., 67, 0, NULL, 0) = 67
> > rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
> > write(2, "su: Permission denied\n", 22su: Permission denied
> > ...
>
> Please try "nice ls", and the same tests you've already done
> replacing "nice" by "nice -n 10", too.
scanner:/# nice su -c ls
su: Permission denied
scanner:/# nice ls
bin dev home lib lost+found mnt proc root srv tmp var
boot etc initrd lib64 media opt restoresymtable sbin sys usr
scanner:/# \nice -n 10 su -c ls
su: Permission denied
Note that this is a "sarge" vserver, in a "etch" server. This doesn't
happen in a "etch" vserver on another "etch server. Maybe that's
related.
> It's weird, because a default nice invocation *decreases* the process
> priority ('-n 10' is the default if no niceness is explicitely
> provided).
Right.
> I quite understand it's impossible to *raise* a process priority
> inside a VServer :
>
> vserver:/# nice -n -10 ls
> nice: cannot set niceness: Permission denied
>
> Please note, BTW, that the error message I get comes from nice and not
> from su, which seems quite logical to me.
>
> But here I can decrease a process priority without any issue :
>
> vserver:/# nice su -c ls
> bin boot dev etc home initrd lib media mnt opt proc root sbin
> srv sys tmp usr var
> vserver:/# su -c ls
> bin boot dev etc home initrd lib media mnt opt proc root sbin
> srv sys tmp usr var
> vserver:/# nice ls
> bin boot dev etc home initrd lib media mnt opt proc root sbin
> srv sys tmp usr var
>
> Maybe you have an alias for "nice" or somthing like this ?
I don't think so.
I think the issue is that *su* tries to raise the nice level back to 0.
Maybe that behaviour was fixed in etch.
> BTW, how do you configure a VServer not to be a realtime one ?
There not realtime, by default.
> Is there a specific configuration item to do so or is it the default
> behaviour ? Please post your /etc/vservers/VSERVER/flags and misc
> capabilities files.
remus:/etc/vservers/scanner# ls */flags
ls: */flags: No such file or directory
No capabilities.
Here's a vserver that allows playing with nice levels:
romulus:/etc/vservers/voice# cat bcapabilities
CAP_SYS_NICE
voice:/# nice su -c ls
bin boot dev etc home initrd lib lib64 lost+found media mnt
opt proc root sbin srv sys tmp usr var
> > I really wonder why this `su -c' call is there, because it doesn't
> > serve any purpose in my eyes.
>
> To be honnest, I don't remember, but looking to the SVN repo logs
> should help to understand this piece of code. I'd like to try fixing
> your "nice + su" issue without modifying this code, which seems to
> work well everywhere else. He he, I don't like modifying good old
> working code.
I still think the su should go.
> > I would advocate removing all such calls. I had to do it here to make
> > it work. Here's my current patch on dup:
>
> > @@ -119,14 +130,14 @@
> > for i in $exclude; do
> > str="${i//__star__/*}"
> > i=`readlink -f ${i#}`
> > - execstr="${execstr}--exclude '$str' "
> > + execstr="${execstr}--exclude $str "
> > done
>
> Why are you removing the single quotes ? Did you have to do so to get
> the following working ?
I honestly don't remember here...
> IIRC, they are useful in two cases :
> - if $str contains space characters, the final duplicity command
> should really be "duplicity --exclude 'bla bli'"
Right.
> - if $str contains globbing characters (*), the final duplicity
> command should really be "duplicity --exclude 'bla*'", because
> duplicity knows how to expand such characters, and because
> expanding there before has caused issues in the past : such
> expanded command lines could exceed the shell command
> length limit.
Indeed. I guess this chunk could go away. I don't remember why it's
there.
A.
--
Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas
Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas.
- Sébastien Faure
signature.asc
Description: Digital signature
