Re: multiple scandir and rc database

[Eric Vidal]

> > note : I think, you will have this trouble on a lot of
> > distribution. you have importas program which do the same thing as
> > import program, so perhaps you can remove the import program?!?
> 
>   Oh really? How about you write to the ImageMagick maintainers and
> suggest *them* to remove *their* import program? They wouldn't react well,
> would they? What made you think I would react any better?
> 


you have totally right, sorry for this stupid suggestion, it was not my 
intention of offended you

>   The problem is bigger than just "import". The problem is that there's no
> global database of command names, and if you attempt to build a distro,
> that is a problem that *you* need to fix. I suggested you the real, working
> fix: slashpackage. You did not want it; fine, but then I'm not going to
> modify my software to work around your problems.

again you have right, i see the trouble here not only with your software, 
perhaps it's time to me to make a difference between what i share and archlinux.

Thanks and sorry again if i offended you

-- 
Eric Vidal 

Re: multiple scandir and rc database

[Laurent Bercot]

On 13/06/2016 16:50, Eric Vidal wrote:


I totaly agree with you but i do not have the choice, you import
program is in conflict with import from imagemagick. So, under
Archlinux system (i'm based on it) the bin directory is a symlinks to
/usr/bin.


 You totally have the choice. Install it with slashpackage, install it into
/opt, install it anywhere BUT /usr/local. You are the distributor, you choose
the policy; if you're tied to the Arch Linux choices, then you'll run into
way more trouble than this.



note : I think, you will have this trouble on a lot of
distribution. you have importas program which do the same thing as
import program, so perhaps you can remove the import program?!?


 Oh really? How about you write to the ImageMagick maintainers and
suggest *them* to remove *their* import program? They wouldn't react well,
would they? What made you think I would react any better?

 The problem is bigger than just "import". The problem is that there's no
global database of command names, and if you attempt to build a distro,
that is a problem that *you* need to fix. I suggested you the real, working
fix: slashpackage. You did not want it; fine, but then I'm not going to
modify my software to work around your problems.



my fault,it is not a down file but a finish file, type syntax error
here :)


 A finish script won't be of any use either. By the time your finish
script runs, s6-svscan is already dead. What kills it is the SIGTERM
that happens when s6-rc decides to bring down the service.

--
 Laurent

Re: multiple scandir and rc database

[Eric Vidal]

> > > However, i have a another trouble, when i try to launch some classic
> > > service with the second scandir(or the first, it's equal) i have this
> > > error on the log : @4000575cf0bb05fd2e24 s6-supervise
> > > syslogd-linux/log: warning: unable to spawn ./run - waiting 10
> > > seconds @4000575cf0c504c9de44 s6-supervise syslogd-linux:
> > > warning: unable to spawn ./run - waiting 10 seconds
> > > @4000575cf0c504ca5f2c s6-supervise (child): fatal: unable to exec
> > > run: No such file or directory @4000575cf0c50660c63c s6-supervise
> > > (child): fatal: unable to exec run: No such file or directory
> > 
> >   You have an invalid "syslogd-linux" service directory, with no run script.
> > Same thing with syslogd-linux/log. Check what is happening to your run
> > scripts.
> 
> i taken your original service from your s6 package, i do not have changing 
> anything on it appart the s6-setuidgid at the log scripts that i defined with 
> s6log according to my system. However, if i try with your klogd-linux 
> service, the error is equal. So, this is the procedure i use, perhaps i make 
> a mistake :
> 
> i copy the entire directory syslogd-linux to my running scandir 
> /run/boot/service
> then i enter this command on the console:
> s6-svscanctl -an /run/boot/service
 
shame on me :(, i forgot to change the shebang according to my system, all 
works fine here, sorry for that

-- 
Eric Vidal 

Re: multiple scandir and rc database

[Laurent Bercot]

#!/usr/local/bin/execlineb -P


 If you're a distributor: don't do that. Distributions should not install
anything in /usr/local.
 Also, if you're providing s6 as the base init system, you should have the
execline binaries in the root filesystem, which means /bin. Because the user
may choose to have /usr on a different filesystem.



foreground { s6-hiercopy /etc/s6/user-serv /run/user }


 Do you need to perform that step every time your service restarts?
It's idempotent, so you should put that in a separate oneshot, instead of
in a run script.



if { if { s6-mkdir -p -m 0755 /run/user-run/ } forbacktickx -p -0 i {
s6-ls -0 /run/user } import -u i foreground { s6-ln -s --
/run/user/${i} /run/user-run/ } }


 Same thing: that's idempotent, so put that in a separate oneshot.
Besides, all that accomplishes is add another level of indirection.
Why do you need /run/user-run with symlinks when you could just use
/run/user ? /run/user is already a working copy of your user data in
/etc/s6/user-serv, why do you need an additional directory where you're not
adding anything meaningful ?



s6-envdir -I /run/user-run/service/.s6-svscan


 I don't think that does what you think it does. Nothing in .s6-svscan is
meant to be read and put into environment variables.



then i launch a s6-rc-init by a oneshot just after like this :


 Hmmm. This means that your user s6-svscan should notify readiness.
 It's difficult to have a s6-svscan service notify readiness, because how do
you define readiness?
 - If it's just that the s6-svscan process has entered its main loop and can
now receive signals and commands and process the scandir: that's easy to do,
but doesn't mean much.
 - If it's that the whole supervision tree at the time of launch, i.e. all the
early services, are ready: that's a bit harder to implement, it implies
running s6-svwait -a on all early services. Which is doable, but requires
the run script to be a bit more complex than the one you wrote.



#!/usr/local/bin/execlineb -S0
s6-svscanctl -q -- /run/user-run/service


 That's not going to work. Your s6-svscan service is a longrun, so your
supposed "down" file will be ignored; it's not doing anything, you should
delete it.
 What is happening is that your user s6-svscan is sent a SIGTERM when s6-rc
decides it's time to bring it down. Which is the right thing to do.

 Note that you launched s6-svscan with -s, so what SIGTERM does depends on
the contents of /run/user-run/service/.s6-svscan/SIGTERM. That's probably
not a good idea for a s6-svscan instance that is not the main one. My
suggestion would be to just remove the -s option in your run script.



The rc database bring down correctly the service declared on it but
the scandir do not want to stop.


 I suspect you don't have a script for SIGTERM, so s6-svscan is happily
ignoring it. Just remove the -s option to s6-svscan and everything will work
fine.



However, i have a another trouble, when i try to launch some classic
service with the second scandir(or the first, it's equal) i have this
error on the log : @4000575cf0bb05fd2e24 s6-supervise
syslogd-linux/log: warning: unable to spawn ./run - waiting 10
seconds @4000575cf0c504c9de44 s6-supervise syslogd-linux:
warning: unable to spawn ./run - waiting 10 seconds
@4000575cf0c504ca5f2c s6-supervise (child): fatal: unable to exec
run: No such file or directory @4000575cf0c50660c63c s6-supervise
(child): fatal: unable to exec run: No such file or directory


 You have an invalid "syslogd-linux" service directory, with no run script.
Same thing with syslogd-linux/log. Check what is happening to your run
scripts.

--
 Laurent