Re: Native upstart scripts – implemented

2010-05-10 Thread Jacek Konieczny 
On Sun, May 09, 2010 at 02:52:57AM +0300, Elan Ruusamäe wrote:
 also, configtest before reload/restart action would be really important to 
 have in upstart as well, considering that we restart services on rpm 
 upgrades.

Done. Not for 'initctl reload' (which is only 'kill -HUP'), but for
'service $name {restart|reload|try-restart|force-reload}'. Works when
the init script has 'configtest' action and 'upstart_controlled --except
configtest'

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts – implemented

2010-05-09 Thread Jacek Konieczny 
On Sun, May 09, 2010 at 02:52:57AM +0300, Elan Ruusamäe wrote:
 i'd rather avoid completely the new subpackage here, if needed move 
 the /etc/init dir to filesystem package to avoid dirdeps pulling upstart, and 
 use conflicts tag for the current requires tag.

Patrys asked for subpackages and it makes sense - the easiest to choose 
between upstart-way and the-old-way per package.
 
 syslog-ng/syslog-ng.init:
 ...
 upstart_controlled --except configtest
 
 i don't really understand how flush-logs is handled,

It is not. 'service syslog-ng flush-logs' will tell you that. On the
other hand - with upstart 'reload' does the same.
Of course, flush-logs can be implemented in the init script. I guess it
should if it is used by anything else (logrotate?)

 also how do you specify multiple excludes remains unclear.

When '--except' is used, then all what follows are the excludes.

 also, configtest before reload/restart action would be really important to 
 have in upstart as well, considering that we restart services on rpm 
 upgrades. does upstart have such concept after all as restart/reload in 
 scripts?

No. 'reload' in upstart is 'kill -HUP', anything else must be
re-implemented in the init script.  Restart is 'stop; start'. Hmmm...
Now I can see 'restart with configtest' may be easily implemented.
Whenever '--except configtest'  is used, 'upstart_controlled' can call
configtest before trying restart.

configtest on start makes little sense with upstart IMHO.

 ps: would be nice to know where's source of documentation, for example i did 
 not find myself description of job file directives.

From the rc-scripts init.txt:

 The syntax of the ``/etc/init/*.conf`` files is described in the
 init(5) man page.


And yes, looking for a current Upstart documentation in the web gives
no good results.

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts – implemented

2010-05-09 Thread Elan Ruusamäe 
On Sunday 09 May 2010 09:57:57 Jacek Konieczny wrote:
 On Sun, May 09, 2010 at 02:52:57AM +0300, Elan Ruusamäe wrote:
  i'd rather avoid completely the new subpackage here, if needed move
  the /etc/init dir to filesystem package to avoid dirdeps pulling upstart,
  and use conflicts tag for the current requires tag.

 Patrys asked for subpackages and it makes sense - the easiest to choose
 between upstart-way and the-old-way per package.

that maybe useful for developer, but not for end user who wants to boot 
fastest way using upstart, as he does not know which upstart packages he must 
install, i.e must inspect every package one by one, seeing if he has the same 
base package installed on system or not.


-- 
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts – implemented

2010-05-09 Thread Elan Ruusamäe 
On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
 Hello,

 Your volunteer has done his job :)

seems there's some deadlock with initctl emiting

also seems the nice service name is lost there (see sshd part).

also seems there's no our typical restart service after package upgrade,
if you've upgrading upstart-enabled service.
%define upstart_post() \
if [ -f /var/lock/subsys/%1 ] ; then \
/sbin/service --no-upstart %1 stop \
/sbin/service %1 start \
fi

anyway, ps of stall:
root 25974  0.4  0.5  15596  6064 pts/3S+   11:23   0:00  \_ 
poldek -u upstart --up --sn carme openssh-server-upstart syslog-ng-upstart
root 27078  0.4  0.5  12516  5804 pts/3S+   11:24   0:00  
\_ 
rpm --upgrade -vh --root / 
/var/cache/poldek/http_carme.pld-linux.org..glen.th.i686/syslog-ng-3.0.5-2.1.i
root 27181  0.0  0.0   1872   584 pts/3S+   11:24   0:00
  \_ /bin/sh /home/users/glen/tmp/rpm-tmp.59975 2
root 27184  0.0  0.0   1872   604 pts/3S+   11:24   0:00
  \_ /bin/sh /sbin/service syslog-ng restart
root 27187  0.0  0.0   2000   808 pts/3S+   11:24   0:00
  \_ /bin/sh /etc/rc.d/init.d/syslog-ng restart
root 27321  0.0  0.0   5716   972 pts/3S+   11:24   0:00
  \_ /sbin/initctl emit started JOB=syslog-ng SERVICE=syslog

and terminal output:

11:23:03 root[load: 5.81; cpu: 6...@ravenous ~# poldek -u upstart --up --sn 
carme openssh-server-upstart syslog-ng-upstart
...
Preparing...### [100%]
   1:rc-scripts ### [ 25%]
   2:openssh### [ 50%]
   3:openssh-server ### [ 75%]
 * Reloading OpenSSH service...[ DONE ]
   4:openssh-server-upstart ### [100%]
 * Stopping OpenSSH service[ DONE ]
 * Starting sshd service...[ DONE ]

Installing set #2
Processing dependencies...
syslog-ng-upstart-3.0.5-2.1.i686 marks syslog-ng-3.0.5-2.1.i686 (cap syslog-ng 
= 3.0.5-2.1)
 syslog-ng-3.0.5-1.i686 obsoleted by syslog-ng-3.0.5-2.1.i686
There are 2 packages to install (1 marked by dependencies), 1 to remove:
I syslog-ng-upstart-3.0.5-2.1.i686
D syslog-ng-3.0.5-2.1.i686
R syslog-ng-3.0.5-1.i686
This operation will use 423.0B of disk space.
Need to get 2.7MB of archives (2.7MB to download).

Retrieving carme::syslog-ng-3.0.5-2.1.i686.rpm...
.. 100.0% [2.7M (450.6K/s)]  
Retrieving carme::syslog-ng-upstart-3.0.5-2.1.i686.rpm...
.. 100.0% [4.2K (4.2K/s)]   
Executing rpm --upgrade -vh --root /...
error: failed to stat /mnt/docs: Host is down
Preparing...### [100%]
   1:syslog-ng  ### [ 50%]
 * Stopping syslog-ng service..[ DONE ]
 * Starting syslog-ng service..[ DONE ]

# strace -p 27321  
Process 27321 attached - interrupt to quit
restart_syscall(... resuming interrupted call ...

# lsof -p 27321  
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system 
/home/users/glen/.gvfs
  Output information may be incomplete.
lsof: WARNING: can't stat() cifs file system /mnt/docs
  Output information may be incomplete.
COMMAND   PID USER   FD   TYPE DEVICE  SIZE/OFF NODE NAME
initctl 27321 root  cwdDIR  254,0  4096  128 /
initctl 27321 root  rtdDIR  254,0  4096  128 /
initctl 27321 root  txtREG  254,0121084 50978235 /sbin/initctl
initctl 27321 root  memREG  254,0 109740720   142782 
/usr/lib/locale/locale-archive
initctl 27321 root  memREG  254,0117047 34830808 
/lib/libpthread-2.11.1.so
initctl 27321 root  memREG  254,0 26512 35528163 
/lib/librt-2.11.1.so
initctl 27321 root  memREG  254,0   1339736 33654733 /lib/libc-2.11.1.so
initctl 27321 root  memREG  254,0214980 34344577 
/lib/libdbus-1.so.3.4.0
initctl 27321 root  memREG  254,0 33996 33600976 
/lib/libnih-dbus.so.1.0.0
initctl 27321 root  memREG  254,0 83156 33632425 
/lib/libnih.so.1.0.0
initctl 27321 root  memREG  254,0132403 33596389 /lib/ld-2.11.1.so
initctl 27321 root0r  FIFO0,8   0t0  1228197 pipe
initctl 27321 root1u   CHR  136,7   0t0   10 /dev/pts/7
initctl 27321 root2u   CHR  136,7   0t0   10 /dev/pts/7
initctl 27321 root3u  unix 0xdb670a00   0t0  1228587 socket

-- 
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org

Re: Native upstart scripts – implemented

2010-05-09 Thread Jacek Konieczny 
On Sun, May 09, 2010 at 11:39:14AM +0300, Elan Ruusamäe wrote:
 On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
  Hello,
 
  Your volunteer has done his job :)
 
 seems there's some deadlock with initctl emiting

Isn't that another result of https://bugs.launchpad.net/upstart/+bug/406397

 also seems the nice service name is lost there (see sshd part).

How is that supposed to work and where is that 'sshd part'?

 also seems there's no our typical restart service after package upgrade,
 if you've upgrading upstart-enabled service.
 %define upstart_post() \
 if [ -f /var/lock/subsys/%1 ] ; then \
 /sbin/service --no-upstart %1 stop \
 /sbin/service %1 start \
 fi

The service will be restarted after main package upgrade. Though we have
the real problem of -upstart subpackage here: the restart should
probably be done when both main and -upstart packages are upgraded.

 anyway, ps of stall:
 root 25974  0.4  0.5  15596  6064 pts/3S+   11:23   0:00  \_ 
 poldek -u upstart --up --sn carme openssh-server-upstart syslog-ng-upstart
 root 27078  0.4  0.5  12516  5804 pts/3S+   11:24   0:00  
 \_ 
 rpm --upgrade -vh --root / 
 /var/cache/poldek/http_carme.pld-linux.org..glen.th.i686/syslog-ng-3.0.5-2.1.i
 root 27181  0.0  0.0   1872   584 pts/3S+   11:24   0:00  
 \_ /bin/sh /home/users/glen/tmp/rpm-tmp.59975 2
 root 27184  0.0  0.0   1872   604 pts/3S+   11:24   0:00  
 \_ /bin/sh /sbin/service syslog-ng restart
 root 27187  0.0  0.0   2000   808 pts/3S+   11:24   0:00  
 \_ /bin/sh /etc/rc.d/init.d/syslog-ng restart
 root 27321  0.0  0.0   5716   972 pts/3S+   11:24   0:00  
 \_ /sbin/initctl emit started JOB=syslog-ng SERVICE=syslog

I guess  --no-wait for emit should be used here. Though there is
something blocking – emit waits for some action on the 'started' event
to finish and some service starting on this even has probably locked up
(most probably due to https://bugs.launchpad.net/upstart/+bug/406397 and
broken /etc/init/*.conf file (I have recently fixed those for openssh
and syslog-ng)).

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts – implemented

2010-05-09 Thread Elan Ruusamäe 
On Sunday 09 May 2010 12:00:57 Jacek Konieczny wrote:
  also seems the nice service name is lost there (see sshd part).

 How is that supposed to work and where is that 'sshd part'?

line 1 and 3 - the nice name, line 4 plain service name

1: * Reloading OpenSSH service...[ DONE ]
2:   4:openssh-server-upstart ### 
[100%]
3: * Stopping OpenSSH service[ DONE ]
4: * Starting sshd service...[ DONE ]

the nice names are embedded in initscript as msg_* and in .spec file as extra 
arg for %service restart

-- 
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts – implemented

2010-05-09 Thread Elan Ruusamäe 
On Sunday 09 May 2010 12:00:57 Jacek Konieczny wrote:
 I guess  --no-wait for emit should be used here. Though there is
 something blocking – emit waits for some action on the 'started' event
 to finish and some service starting on this even has probably locked up
 (most probably due to https://bugs.launchpad.net/upstart/+bug/406397 and
 broken /etc/init/*.conf file (I have recently fixed those for openssh
 and syslog-ng)).

if thats any useful info, then initctl list:

# initctl list
mountall-net stop/waiting
rc stop/waiting
ureadahead-other stop/waiting
sshd start/running, process 26834
tty (/dev/tty3) start/running, process 4362
tty (/dev/tty2) start/running, process 27957
tty (/dev/tty1) start/running, process 4358
tty (/dev/tty4) start/running, process 4364
control-alt-delete stop/waiting
mountall stop/waiting
rcS stop/waiting
mountall-reboot stop/waiting
mountall-shell stop/waiting
start-ttys stop/waiting
rcS-sulogin stop/waiting
ureadahead stop/waiting

i've built packages today, sshd is irrelevant here even if it has recent -D 
fix, and syslog-ng is not yet known as upstart service, package install is 
not yet finished.

# pkgbytime | grep upstart
Tue Apr 20 20:42:46 2010 vim-syntax-upstart-0.1-1.noarch
Sun May  2 21:26:26 2010 upstart-SysVinit-2.86-24.i686
Sun May  9 11:22:01 2010 upstart-0.6.5-2.2.i686
Sun May  9 11:24:18 2010 openssh-server-upstart-5.5p1-2.1.i686

# initctl status syslog
initctl: Unknown job: syslog
# initctl status syslog-ng
initctl: Unknown job: syslog-ng

-- 
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts – implemented

2010-05-09 Thread Jacek Konieczny 
On Sun, May 09, 2010 at 12:26:56PM +0300, Elan Ruusamäe wrote:
 On Sunday 09 May 2010 12:00:57 Jacek Konieczny wrote:
   also seems the nice service name is lost there (see sshd part).
 
  How is that supposed to work and where is that 'sshd part'?
 
 line 1 and 3 - the nice name, line 4 plain service name

 3: * Stopping OpenSSH service[ DONE ]
 4: * Starting sshd service...[ DONE ]

Oh, you mean that. Do you have an idea how to solve this, keeping things
simple? 

I don't won't anything overly complicated for such a trivial cosmetic
problem. Especially that these messages will not be displayed on boot,
only during manual start/stop with 'service' or during package install
or upgrades, when user knows what is happening.

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts – implemented

2010-05-08 Thread Elan Ruusamäe 
On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
 Some documentation for the rc-scripts+upstart usage is here:

  
 http://svn.pld-linux.org/cgi-bin/viewsvn/rc-scripts/branches/upstart_native
/doc/upstart.txt?rev=11395view=markup

does $JOB=_ has special meaning?

...
emit starting JOB=_ SERVICE=syslog


-- 
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts – implemented

2010-05-08 Thread Jacek Konieczny 
On Sat, May 08, 2010 at 05:07:35PM +0300, Elan Ruusamäe wrote:
 On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
  Some documentation for the rc-scripts+upstart usage is here:
 
   
  http://svn.pld-linux.org/cgi-bin/viewsvn/rc-scripts/branches/upstart_native
 /doc/upstart.txt?rev=11395view=markup
 
 does $JOB=_ has special meaning?

No, as far as I know.
 
 ...
 emit starting JOB=_ SERVICE=syslog

I thought init script should not emit 'started' event exactly as a job
would do, but then I changed my mind. I guess I have not update the doc
after I have changed the script.

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-08 Thread Elan Ruusamäe 
On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
 What do you think? Should I try to prepare a proof-of-concept
 implementation?

any plans of moving rc.sysinit also to upstart?

-- 
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-08 Thread Elan Ruusamäe 
On Saturday 08 May 2010 23:25:27 Jacek Konieczny wrote:
 And no, switching fully to Upstart at this point is not a good idea.
 Have anybody recently upgraded upstart 0.5 to 0.6 on a production
 machine?

i've upgraded once. there was no way to reload init process. the TERM signal 
which was supposed to work did not work, maybe it needed patching in 0.5.x 
times to work.

and even now with 0.6.x the reloading of init process imho did not work.
as a result you can't shutdown your system in normal ways. likely reboot -f 
will help there.

# telinit u
# lsof -p 1 | grep /sbin/init
init  1 root  txtREG  254,0   112932 50978332 /sbin/init (deleted)

-- 
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts – implemented

2010-05-08 Thread Elan Ruusamäe 
On Friday 07 May 2010 16:33:21 Jacek Konieczny wrote:
 Patryk Zawadzki pat...@pld-linux.org wrote:
  I'd opt for having 2 separate -init subpackages, one with the current
  rc.d contents and one with an upstart job description and a simple
  rc.d wrapper that runs start $foo, stop $foo etc.

 -upstart subpackages done. Addin -init makes no sense, as current
 upstart job handling implementaion relies on the init.d scripts for LSB
 compatibility and doing things not doable with bare Upstart
 (non-SIGHUP-reloading, 'checkconfig', advanced status monitoring).

i'd rather avoid completely the new subpackage here, if needed move 
the /etc/init dir to filesystem package to avoid dirdeps pulling upstart, and 
use conflicts tag for the current requires tag.

 Some documentation for the rc-scripts+upstart usage is here:

 http://svn.pld-linux.org/cgi-bin/viewsvn/rc-scripts/branches/upstart_native
/doc/upstart.txt?rev=11395view=markup

syslog-ng/syslog-ng.init:
...
upstart_controlled --except configtest

i don't really understand how flush-logs is handled, or it's just not 
perfectly implemented yet? also how do you specify multiple excludes remains 
unclear.

also, configtest before reload/restart action would be really important to 
have in upstart as well, considering that we restart services on rpm 
upgrades. does upstart have such concept after all as restart/reload in 
scripts?

ps: would be nice to know where's source of documentation, for example i did 
not find myself description of job file directives.

-- 
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-05 Thread Patryk Zawadzki 
On Tue, May 4, 2010 at 11:17 AM, Jacek Konieczny jaj...@jajcus.net wrote:
 Hello,

 In PLD Th, we have upstart as the /sbin/init daemon for some time, but
 it is only used to start the old 'SysVinit' scripts from
 /etc/rc.d/init.d. To make full use of Upstart features, like process
 supervising, parallel start, etc. we should find a way to include
 Upstart support in our packages. Though, we should not replace the
 current, working solution.

BTW: http://0pointer.de/blog/projects/systemd.html

-- 
Patryk Zawadzki
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-05 Thread Jacek Konieczny 
On Wed, May 05, 2010 at 11:20:30AM +0200, Patryk Zawadzki wrote:
 On Tue, May 4, 2010 at 11:17 AM, Jacek Konieczny jaj...@jajcus.net wrote:
  In PLD Th, we have upstart as the /sbin/init daemon for some time, but
  it is only used to start the old 'SysVinit' scripts from
  /etc/rc.d/init.d. To make full use of Upstart features, like process
  supervising, parallel start, etc. we should find a way to include
  Upstart support in our packages. Though, we should not replace the
  current, working solution.
 
 BTW: http://0pointer.de/blog/projects/systemd.html

Great. This fixes some problems of Upstart… but…

This would look great to me if I haven't seen several other „great
SysVinit replacements”. All of them were much better than SysVinit and
even had some „working implementations”. Often long before the Upstart
came up. And everybody have been still using SysVinit.

Upstart is the only one which caught on. It is terrible, with its
big incompatibilities between each version… poor documentation (at least
on the web), impractical event system. Nevertheless it is still much
better than SysVinit with the pile of shell scripts starting daemons
doing anything not to be managed (double-forking, etc.).

Unfortunately /sbin/init is so critical, that we cannot even experiment
much, especially with something no one else uses. And it is hard to have
multiple /sbin/init implementation side by side in one distribution.
They all differ too much not only in the configuration file formats but
in the whole philosophy of the configuration (not only „how to describe
a service configuration” but even „what is a service configuration”). 

One could think of making some kind of an abstraction layer, like our
rc-inetd, but that is a very bad idea. We would probably lose most of
the advantages of each init implementation then.

We should rather think how can we provided a few very different
configuration items, each for a different init implementation, with one
package. I am losing my enthusiasm about implementing the „native
upstart support” in PLD when I think systemd may eventually mature
enough and we would need to start from the beginning…

And I need a good init system now. Currently I use SysVinit +
daemontools in my PLD-based project. It generally works, but is not
elegant nor optimal. Even upstart, when properly deployed, would be
better and systemd could be much better, but I guess it is a matter of
future. 

Pozdrowienia,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-05 Thread Jacek Konieczny 
On Tue, May 04, 2010 at 07:40:43PM +0300, Elan Ruusamäe wrote:
 i don't like the idea that the links are managed via some script, i'd like 
 easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or 
 something in /etc/sysconfig/system the both solutions should be available and 
 configured at the same time.

I thought about that and cannot see how it could be implemented. When
there are upstart configs for some services then Upstart will start them
by the dependencies inside and I cannot see a way to stop this from a
kernel command line and still have the flexibility of which services
should be handled by Upstart and which the old way.

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-05 Thread Łukasz Jernaś 
On Wed, May 5, 2010 at 11:20 AM, Patryk Zawadzki pat...@pld-linux.org wrote:
 On Tue, May 4, 2010 at 11:17 AM, Jacek Konieczny jaj...@jajcus.net wrote:
 Hello,

 In PLD Th, we have upstart as the /sbin/init daemon for some time, but
 it is only used to start the old 'SysVinit' scripts from
 /etc/rc.d/init.d. To make full use of Upstart features, like process
 supervising, parallel start, etc. we should find a way to include
 Upstart support in our packages. Though, we should not replace the
 current, working solution.

 BTW: http://0pointer.de/blog/projects/systemd.html

Well, after seeing how many people have weird problems with PulseAudio
I would be cautious about using another thing  thought out by
Lennart...

-- 
Łukasz [DeeJay1] Jernaś
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-05 Thread Patryk Zawadzki 
On Wed, May 5, 2010 at 2:03 PM, Łukasz Jernaś deej...@srem.org wrote:
 Well, after seeing how many people have weird problems with PulseAudio
 I would be cautious about using another thing  thought out by
 Lennart...

To be fair you have to admit that a vast number of the problems
experienced while using pulseaudio are actually bugs in kernel audio
modules and/or alsa API abuse (think opal, ekiga etc.).

-- 
Patryk Zawadzki
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-05 Thread Jacek Konieczny 
On Wed, May 05, 2010 at 02:13:51PM +0200, Patryk Zawadzki wrote:
 On Wed, May 5, 2010 at 2:03 PM, Łukasz Jernaś deej...@srem.org wrote:
  Well, after seeing how many people have weird problems with PulseAudio
  I would be cautious about using another thing  thought out by
  Lennart...
 
 To be fair you have to admit that a vast number of the problems
 experienced while using pulseaudio are actually bugs in kernel audio
 modules and/or alsa API abuse (think opal, ekiga etc.).

I would rather say it is because of putting another audio server where
it is not needed at all. ALSA alone does its job well enough nowadays
(and if it does not, it should be fixed not wrapped with another layer).
Fortunately things have not gone too far yet and a system without
PulseAudio can still be set up (there was no such freedom in the dark
ages of ESD and ARTS).

This /sbin/init things are not that easy. We will always need some init
daemon… though I still won't chose an implementation only basing on the
fact that the idea is great. It must work and be maintained (or at least
stable as SysVinit) too.

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-05 Thread Patryk Zawadzki 
On Wed, May 5, 2010 at 2:32 PM, Jacek Konieczny jaj...@jajcus.net wrote:
 I would rather say it is because of putting another audio server where
 it is not needed at all. ALSA alone does its job well enough nowadays
 (and if it does not, it should be fixed not wrapped with another layer).
 Fortunately things have not gone too far yet and a system without
 PulseAudio can still be set up (there was no such freedom in the dark
 ages of ESD and ARTS).

I'd say alsa has nothing to search in the userspace and should just
expose hardware. It should not try to provide smart mixing, store
per-application volume or decide which channels to mute when a voip
connection is established. That's pulseaudio's work.

 This /sbin/init things are not that easy. We will always need some init
 daemon… though I still won't chose an implementation only basing on the
 fact that the idea is great. It must work and be maintained (or at least
 stable as SysVinit) too.

Notice I only mentioned systemd as by the way. I did not even think
about packaging it at this point in time.

-- 
Patryk Zawadzki
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-05 Thread Jacek Konieczny 
On Wed, May 05, 2010 at 03:48:18PM +0200, Patryk Zawadzki wrote:
  This /sbin/init things are not that easy. We will always need some init
  daemon… though I still won't chose an implementation only basing on the
  fact that the idea is great. It must work and be maintained (or at least
  stable as SysVinit) too.
 
 Notice I only mentioned systemd as by the way. I did not even think
 about packaging it at this point in time.

Yes, but knowing it „by the way” means we can consider it as a future
option when changing rc-scripts for Upstart, so we don't have to revert
some silly changes in the far future.

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-04 Thread Caleb Maclennan 
2010/5/4 Jacek Konieczny jaj...@jajcus.net:
 I think Upstart support should be implemented as an option, coexisting
 with current solution, so the administrator may choose what he prefers
 and even use init.d for some services and upstart for other.

+1

  - chkconfig would link/unlink the files when requested (global
    configuration option and command line option to prefer upstart)

Your implementation sounds reasonable. I have several systems I will
be interested in trying this out on.

 P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;)

Yes. Particularly as a new developer seeing verbose discussion of
various decisions is quite helpful.

Caleb
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-04 Thread Elan Ruusamäe 
On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
 What do you think? Should I try to prepare a proof-of-concept
 implementation?

i describe ubuntu like implementation that i had in first mind to do:

1. some packages have been migrated to upstart, 
having /etc/init/service.conf file
2. those packages initscript is symlinked: 
to /etc/rc.d/init.dservice - /lib/init/upstart-job
3. upstart-job suggests to use 'service service to start if invoked directly 
via /etc/rc.d/init.d
4. /sbin/service, sees if invoked service jas /etc/init/service.conf and 
invokes via upstart, otherwise fallbacks to sysvninit mode

upstart-job is included in upstart package, /sbin/service diff in attachment.

however this assumes you already have upstart in target, i.e you preserve 
invoking old way, but require upstart being present.

and this does not handle chkconfig integration due the symlink, i.e booting 
without upstart sequence is unknown.

i've also packaged two packages from ubuntu to pld: mountall and ureadahead

 P.S. Does anybody read those 'long' posts I send to pld-devel-en? ;)

i would had answered bacula one, if i had chance to test bacula 5.0

-- 
glen
--- service	2010-04-21 23:22:56.221265599 +0300
+++ /sbin/service	2010-04-21 23:24:13.564399085 +0300
@@ -95,6 +95,21 @@
 	esac
 done
 
+if [ -r /etc/init/${SERVICE}.conf ]; then
+	# Upstart configuration exists for this job
+	case ${ACTION} in
+	start|stop|restart|status|reload)
+		 # Action is a valid upstart action
+		exec ${ACTION} ${SERVICE} ${OPTIONS}
+	;;
+	force-reload)
+		# Upstart just uses reload for force-reload
+		exec reload ${SERVICE} ${OPTIONS}
+	;;
+	esac
+fi
+
+# Otherwise, use the traditional sysvinit
 if [ -x ${SERVICEDIR}/${SERVICE} ]; then
 	exec env -i LANG=$LANG PATH=$PATH TERM=$TERM ${SERVICEDIR}/${SERVICE} ${ACTION} ${OPTIONS}
 else
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-04 Thread Jacek Konieczny 
On Tue, May 04, 2010 at 12:04:39PM +0200, Patryk Zawadzki wrote:
  I think Upstart support should be implemented as an option, coexisting
  with current solution, so the administrator may choose what he prefers
  and even use init.d for some services and upstart for other.
 
 I was hoping for eventually dropping rc scripts for some services and
 moving them completely to upstart. I see why that might sound scary
 and am ok with having two solutions.

I think we can drop rc-scripts some day, but first the alternative must
be well-tested. Having the two alternatives co-exist every one may gradually 
migrate to upstart in his own pace.

And dropping /etc/rc.d/init.d/* in Th will make another difference to
Ti… I guess we don't wont PLD split even more.

Another thing to consider is LSB compatibility… some services expect
/etc/init.d scripts doing their stuff. 

Maybe we could make /etc/init.d a directory with symlinks to
/etc/rc.d/init.d or the upstart wrapper, depending on what is used to
handle the service?

 I'd opt for having 2 separate -init subpackages, one with the current
 rc.d contents and one with an upstart job description and a simple
 rc.d wrapper that runs start $foo, stop $foo etc.

Extra two subpackages for every daemon? I would prefer to avoid that.

 As for emitting signals, we should add these as required by
 dependencies. I see no gain from adding them to every rc.d script.

Hmm. That makes sense. Some event will be implemented in rc-scripts
(line 'network started').

On the other hand, if we make rc-scripts function which does 
 touch /var/lock/subsys/$name; initctl emit subsys/$name started
and another to:
 rm -f /var/lock/subsys/$name; initctl emit subsys/$name stopped

Then integrating the signals will be very easy.

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-04 Thread Jacek Konieczny 
On Tue, May 04, 2010 at 12:04:39PM +0200, Patryk Zawadzki wrote:
  - scripts in /etc/rc.d/init.d would emit 'started' and 'stopped'
   events when necessary, so upstart services can rely on that
 
 I'd opt for having 2 separate -init subpackages, one with the current
 rc.d contents and one with an upstart job description and a simple
 rc.d wrapper that runs start $foo, stop $foo etc.

There is one more thing why I would prefer to keep both old-style init.d
script and the new upstart configuration together: we often have
something more than 'start' 'stop' and 'status' implemented in the init
scripts. Some of these actions would have to be copied to upstart
script somehow (initialization before first run), other probably cannot
be handled by upstart means.

sshd init script builds host keys the first time it is started. This
functionality is available also via '/etc/rc.d/init.d/sshd init' and
would have to be copied to the upstart configuration to and maintained
in the two places.

As starting and stopping of services is quite different in LSB init
scripts and upstart and reusing code does not make sens, in other cases,
like 'init' the code may be reused and upstart script could just call
'/etc/rc.d/init.d/sshd init'. 

Also, there are things like '/etc/rc.d/init.d/lighttpd configtest' which
are not part of normal job control and thus not applicable to upstart
config, but still useful.

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-04 Thread Pawel Golaszewski 
On Tue, 4 May 2010, Patryk Zawadzki wrote:
  I think Upstart support should be implemented as an option, coexisting 
  with current solution, so the administrator may choose what he prefers 
  and even use init.d for some services and upstart for other.
 I was hoping for eventually dropping rc scripts for some services and
 moving them completely to upstart. I see why that might sound scary
 and am ok with having two solutions.

-ENOWAY !
Don't remove working sollution.

It can be done for new services, but not for existing-ones.

 I'd opt for having 2 separate -init subpackages, one with the current
 rc.d contents and one with an upstart job description and a simple
 rc.d wrapper that runs start $foo, stop $foo etc.

I wanted to say something like that.

  What do you think? Should I try to prepare a proof-of-concept 
  implementation?
 Ladies and gentlemen, we have a volunteer :)

hip-hip, hura!!! ;)

-- 
pozdr.  Paweł Gołaszewski  jid:bluesatjabberdotgdadotpl
--
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-04 Thread Pawel Golaszewski 
On Tue, 4 May 2010, Jacek Konieczny wrote:
 Maybe we could make /etc/init.d a directory with symlinks to 
 /etc/rc.d/init.d or the upstart wrapper, depending on what is used to 
 handle the service?

see how ubuntu made this.
Every service is in that directory, some are links.
I can see how does it looks like at home, later.

  I'd opt for having 2 separate -init subpackages, one with the current
  rc.d contents and one with an upstart job description and a simple
  rc.d wrapper that runs start $foo, stop $foo etc.
 Extra two subpackages for every daemon? I would prefer to avoid that.

but you can make ignores in poldek with that and make it easy to use.

-- 
pozdr.  Paweł Gołaszewski  jid:bluesatjabberdotgdadotpl
--
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-04 Thread Elan Ruusamäe 
On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
 My proposition:
 - packages will provide upstart configuration files in /etc/rc.d/upstart
 - those could be linked or copied to /etc/init/subsys when needed
   - chkconfig would link/unlink the files when requested (global
     configuration option and command line option to prefer upstart)
   - user could copy them manually and modify them if needed

i don't like the idea that the links are managed via some script, i'd like 
easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or 
something in /etc/sysconfig/system the both solutions should be available and 
configured at the same time.

also i'd not invent new paths, but use /etc/init for upstart scripts.

 - rc-scripts won't start/stop services via /etc/rc.d/init.d scripts when
   /etc/init/subsys/$name exists
 - 'service' script would use 'initctl' instead of /etc/rc.d/init.d
   when /etc/init/subsys/$name exists
 - scripts in /etc/rc.d/init.d would emit 'started' and 'stopped'
   events when necessary, so upstart services can rely on that

otherwise matches quite much with my vision...

-- 
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Native upstart scripts

2010-05-04 Thread Jacek Konieczny 
On Tue, May 04, 2010 at 07:40:43PM +0300, Elan Ruusamäe wrote:
 On Tuesday 04 May 2010 12:17:41 Jacek Konieczny wrote:
  My proposition:
  - packages will provide upstart configuration files in /etc/rc.d/upstart
  - those could be linked or copied to /etc/init/subsys when needed
    - chkconfig would link/unlink the files when requested (global
      configuration option and command line option to prefer upstart)
    - user could copy them manually and modify them if needed
 
 i don't like the idea that the links are managed via some script, i'd like 
 easily to boot to upstart-mode or sysvinit-mode with a kernel commandline, or 
 something in /etc/sysconfig/system the both solutions should be available and 
 configured at the same time.

I'll take this into account. Though keeping both configured could cause
mistakes like starting a service again the different way. I guess this
can be solved somehow anyway
 
 also i'd not invent new paths, but use /etc/init for upstart scripts.

Recent upstart allows hierarchical names. I thought a separate namespace
(subsys/* or rc/*) for the rc-scripts equivalents would be a good idea.
Now I think it will be probably better to use subdirs for local stuff
(/etc/init/local - local/* jobs) and sub-tasks (e.g.
/etc/init/postgresql.conf – 'postgresql' task to start/stop whole
postgresql and /etc/init/postgresql/instance.conf –
'postgresql/instance' describing each instance) instead.

Greets,
Jacek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en