Re: Re: about upstart
hi, Am Montag, den 11.01.2016, 16:06 +0800 schrieb yan...@iscas.ac.cn: > Can you tell me where did ubuntu15.04 define the environment > variables "UPSTART_SESSION" ? upstart generates it when it starts the upstart user session. ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
Just to check, have you performed a web search for this information? While I don't know exactly what you're looking for, the very first result I get for "UPSTART_SESSION" is https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions . A little down the page is the following: "D-Bus Each Session Init daemon will register a D-Bus address of: "unix:abstract=/com/ubuntu/upstart-session/$USER/$PID" Where "$USER" corresponds to the username and "$PID" corresponds to the PID of the Session Init. The path will be exported as UPSTART_SESSION in the environment of all child processes of the users Session Init and initctl will use that variable when the Session Init can't be found on the session bus. All child processes will also contain a variable specifying the PID of the Session Init they are being managed by: $UPSTART_SESSION_PID. The Session Init will store the address of the session in $HOME/.cache/upstart/sessions/$PID.log using familiar shell syntax: UPSTART_SESSION=$UPSTART_SESSION The $PID.log file will be removed on successful Session shutdown." As Dimitri suggested, if instead of asking a series of single questions you gave some idea about what you are trying to do the advice could be rather more helpful. It's also not a wonderful idea to ask the same question twice and suggests you're not really reading the responses you're getting. Best, Jonathon On 11 January 2016 at 08:06, yan...@iscas.ac.cn wrote: > Can you tell me where did ubuntu15.04 define the environment variables > "UPSTART_SESSION" ? > > -- > yan...@iscas.ac.cn > > > *From:* Dimitri John Ledkov > *Date:* 2016-01-08 20:52 > *To:* yan...@iscas.ac.cn > *CC:* ubuntu-devel-discuss > *Subject:* Re: Re: about upstart > Hi, > > You have asked a lot of questions already. Could you maybe elaborate > what are you investigating overall? Or what are you trying to achieve? > Answering questions one by one is not very productive. > > UPSTART_SESSION variable points at private unix socket that one can > use to communicate with a user session upstart. When present in the > environment, initctl and other tools use that socket to talk to the > user upstart session. > > Regards, > > Dimitri. > > On 8 January 2016 at 01:55, yan...@iscas.ac.cn wrote: > > > > > > Where is the definition of environment variable "UPSTART_SESSION" > > > > > > From: Martin Pitt > > Date: 2016-01-07 17:54 > > To: yan...@iscas.ac.cn > > CC: ubuntu-devel-discuss > > Subject: Re: Re: about upstart > > yan...@iscas.ac.cn [2016-01-07 15:20 +0800]: > >> How does ubuntu solve the the problem “initctl can not use when > >> /sbin/upstart and systemd in ubuntu14.10”.And how is the reasion? > > > > Sorry, I cannot parse this. > > > > You use "initctl" as user for the user upstart, and you don't use it > > as root for system services when the system is running systemd. > > > > Martin > > > > -- > > Martin Pitt| http://www.piware.de > > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > > > > > -- > > Ubuntu-devel-discuss mailing list > > Ubuntu-devel-discuss@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > > > -- > Regards, > > Dimitri. > > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
Can you tell me where did ubuntu15.04 define the environment variables "UPSTART_SESSION" ? yan...@iscas.ac.cn From: Dimitri John Ledkov Date: 2016-01-08 20:52 To: yan...@iscas.ac.cn CC: ubuntu-devel-discuss Subject: Re: Re: about upstart Hi, You have asked a lot of questions already. Could you maybe elaborate what are you investigating overall? Or what are you trying to achieve? Answering questions one by one is not very productive. UPSTART_SESSION variable points at private unix socket that one can use to communicate with a user session upstart. When present in the environment, initctl and other tools use that socket to talk to the user upstart session. Regards, Dimitri. On 8 January 2016 at 01:55, yan...@iscas.ac.cn wrote: > > > Where is the definition of environment variable "UPSTART_SESSION" > > > From: Martin Pitt > Date: 2016-01-07 17:54 > To: yan...@iscas.ac.cn > CC: ubuntu-devel-discuss > Subject: Re: Re: about upstart > yan...@iscas.ac.cn [2016-01-07 15:20 +0800]: >> How does ubuntu solve the the problem “initctl can not use when >> /sbin/upstart and systemd in ubuntu14.10”.And how is the reasion? > > Sorry, I cannot parse this. > > You use "initctl" as user for the user upstart, and you don't use it > as root for system services when the system is running systemd. > > Martin > > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Regards, Dimitri. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
Hi, You have asked a lot of questions already. Could you maybe elaborate what are you investigating overall? Or what are you trying to achieve? Answering questions one by one is not very productive. UPSTART_SESSION variable points at private unix socket that one can use to communicate with a user session upstart. When present in the environment, initctl and other tools use that socket to talk to the user upstart session. Regards, Dimitri. On 8 January 2016 at 01:55, yan...@iscas.ac.cn wrote: > > > Where is the definition of environment variable "UPSTART_SESSION" > > > From: Martin Pitt > Date: 2016-01-07 17:54 > To: yan...@iscas.ac.cn > CC: ubuntu-devel-discuss > Subject: Re: Re: about upstart > yan...@iscas.ac.cn [2016-01-07 15:20 +0800]: >> How does ubuntu solve the the problem “initctl can not use when >> /sbin/upstart and systemd in ubuntu14.10”.And how is the reasion? > > Sorry, I cannot parse this. > > You use "initctl" as user for the user upstart, and you don't use it > as root for system services when the system is running systemd. > > Martin > > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Regards, Dimitri. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
Where is the definition of environment variable "UPSTART_SESSION" From: Martin Pitt Date: 2016-01-07 17:54 To: yan...@iscas.ac.cn CC: ubuntu-devel-discuss Subject: Re: Re: about upstart yan...@iscas.ac.cn [2016-01-07 15:20 +0800]: > How does ubuntu solve the the problem “initctl can not use when > /sbin/upstart and systemd in ubuntu14.10”.And how is the reasion? Sorry, I cannot parse this. You use "initctl" as user for the user upstart, and you don't use it as root for system services when the system is running systemd. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
yan...@iscas.ac.cn [2016-01-07 15:20 +0800]: > How does ubuntu solve the the problem “initctl can not use when > /sbin/upstart and systemd in ubuntu14.10”.And how is the reasion? Sorry, I cannot parse this. You use "initctl" as user for the user upstart, and you don't use it as root for system services when the system is running systemd. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
How does ubuntu solve the the problem “initctl can not use when /sbin/upstart
and systemd in ubuntu14.10”.And how is the reasion?
yan...@iscas.ac.cn
From: Martin Pitt
Date: 2016-01-07 15:15
To: yan...@iscas.ac.cn
CC: ubuntu-devel-discuss
Subject: Re: Re: about upstart
Hello yankun,
yan...@iscas.ac.cn [2016-01-07 9:04 +0800]:
> Thank you Martin.There is also a doubt: how the lightdm starts
> upstart? I can not find anything useful in unit files ?
lightdm does not do that by itself, it's done by
/etc/X11/Xsession.d/{00,99}upstart .
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
On Thu, Jan 07, 2016 at 09:04:59AM +0800, yan...@iscas.ac.cn wrote: > Thank you Martin.There is also a doubt: how the lightdm starts > upstart? I can not find anything useful in unit files ? It's hooked up via Xsession configuration, in /etc/X11/Xsession.d/00upstart and /etc/X11/Xsession.d/99upstart. -- Colin Watson [cjwat...@ubuntu.com] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
Thank you Martin.There is also a doubt: how the lightdm starts upstart? I can not find anything useful in unit files ? yan...@iscas.ac.cn From: Martin Pitt Date: 2016-01-06 17:41 To: yan...@iscas.ac.cn CC: ubuntu-devel-discuss Subject: Re: Re: about upstart yan...@iscas.ac.cn [2016-01-06 17:16 +0800]: > Thanks for your reply.Is there any other reasion.By "pstree",the pulseaudio > is started by upstart.I mean,even when I choose systemd as the init daemon.I > can not remove upstart in Ubuntu15.04 ? Yes, pulseaudio is a session process and started by the session upstart. You can't entirely remove upstart in Ubuntu yet, just upstart-sysv for the system services. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
yan...@iscas.ac.cn [2016-01-06 17:16 +0800]: > Thanks for your reply.Is there any other reasion.By "pstree",the pulseaudio > is started by upstart.I mean,even when I choose systemd as the init daemon.I > can not remove upstart in Ubuntu15.04 ? Yes, pulseaudio is a session process and started by the session upstart. You can't entirely remove upstart in Ubuntu yet, just upstart-sysv for the system services. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Re: about upstart
Thanks for your reply.Is there any other reasion.By "pstree",the pulseaudio is started by upstart.I mean,even when I choose systemd as the init daemon.I can not remove upstart in Ubuntu15.04 ? yan...@iscas.ac.cn From: Martin Pitt Date: 2016-01-06 16:59 To: yan...@iscas.ac.cn CC: ubuntu-devel-discuss Subject: Re: about upstart Hello yankun, yan...@iscas.ac.cn [2016-01-06 13:47 +0800]: > In ubuntu15.04,there is also upstart running when systemd is the init.So why > to do this ? You are most probably seeing the session upstart process. User sessions haven't been converted away from upstart (to systemd or dbus activation) yet. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: about upstart
Hello yankun, yan...@iscas.ac.cn [2016-01-06 13:47 +0800]: > In ubuntu15.04,there is also upstart running when systemd is the init.So why > to do this ? You are most probably seeing the session upstart process. User sessions haven't been converted away from upstart (to systemd or dbus activation) yet. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
about upstart
Hi,all In ubuntu15.04,there is also upstart running when systemd is the init.So why to do this ? yan...@iscas.ac.cn -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
about upstart
Hi,all In ubuntu15.04,there is also upstart running when systemd is the init.So why to do this ? yan...@iscas.ac.cn -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: about break upstart
hi, Am Donnerstag, den 31.12.2015, 14:39 +0800 schrieb yan...@iscas.ac.cn: > breaks upstart(<<1.12.1-0ubuntu8) this looks like you are doing a release to release upgrade without using update-manager/do-release-upgrade (who would both take care for handling replacing upstart with systemd proper) but by directly via hacking sources.list and using apt ... ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: about break upstart
On Thu, 31 Dec 2015 14:39:05 +0800, yan...@iscas.ac.cn wrote: >when I install lsb-base,but it tell me it will break >upstart(<<1.12.1-0ubuntu8)) What does it mean? Need I update the >upstart? What exactly does it tell you? Copy and paste the output you get. Which Ubuntu release do you use? Are you using a third party repository? FWIW https://lists.ubuntu.com/mailman/listinfo/ubuntu-users -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
about break upstart
Hi: when I install lsb-base,but it tell me it will break upstart(<<1.12.1-0ubuntu8)) What does it mean? Need I update the upstart? yan...@iscas.ac.cn -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Display backlight level save and restore as a init-script / upstart job for laptops
Dear all! As you can read from bug 1270579 description <https://bugs.launchpad.net/bugs/1270579>, I created Ubuntu package for saving and restoring backlight (brightness) level on laptops. This package installs one file - "/etc/init.d/sysvinit-backlight" (sysvinit script <https://bazaar.launchpad.net/~nrbrtx/+junk/sysvinit-backlight/files> ). You can install my package from PPA <https://launchpad.net/~nrbrtx/+archive/ubuntu/sysvinit-backlight> with the commands below: sudo add-apt-repository ppa:nrbrtx/sysvinit-backlight sudo apt-get update sudo apt-get install sysvinit-backlight You can remove it by sudo apt-get purge sysvinit-backlight Please note: if you have installed the previous version of my script, please remove it by sudo rm /etc/rc?.d/?25backlight /etc/init.d/brightness /etc/rc?.d/?25brightness The script functionality is: * save backlight (brightness) levels of all video adapters on reboot and shutdown (runlevel 0 and 6) * load backlight (brightness) levels for all video adapters on boot (runlevel S and 2) * this version supports hybrid graphics The script options are: * sudo service sysvinit-backlight status (show current brightness levels and saved in files values) * sudo service sysvinit-backlight start (set saved level from files) * sudo service sysvinit-backlight stop (save current level to files) Known problems: * brightness resets to maximum on login to MATE session (may be related to https://github.com/mate-desktop/mate-power-manager/issues/76) Changes: I removed all bashisms and made code more clear - thanks to Andreas Mohr (andi). I tested my package on Ubuntu 12.04.5 LTS, 14.04.2 LTS and Ubuntu 14.10. With best regards, Ubuntu user, Norbert. On Sat, Jan 10, 2015 at 9:24 PM, Nrbrtx wrote: > Dear Ubuntu and Debian developers! > > I understand that you are very busy, but laptop users have problems > with saving and restoring display backlight level in Debian and Ubuntu. > > Systemd-based distros (Fedora, OpenSuSe, Arch, Sabayon, Mageia) have this > functionality out the box (they have systemd-backlight@.service > <https://github.com/systemd/systemd/commits/56f64d95763a799ba4475daf44d8e9f72a1bd474/src/backlight/backlight.c>), > but sysvinit and upstart not. > > Here is a list: > >- in Arch backlight brightness load and save are provided by systemd >(see Arch wiki > > <https://wiki.archlinux.org/index.php/backlight#systemd-backlight_service>), >it is in systemd ><https://www.archlinux.org/packages/core/x86_64/systemd/> package. >- in OpenSUSE 13.1, OpenSUSE 13.2, CentOS 7, Fedora 20, Fedora 21, >Mageia 4 - systemd package ><http://pkgs.org/search//usr/lib/systemd/systemd-backlight?type=files> >- Sabayon has /usr/lib/systemd/systemd-backlight service >- ALT Linux p7 has systemd, but does not have /usr/lib/systemd/systemd- >backlight service >- in Debian Jessie > > <https://packages.debian.org/search?suite=jessie&arch=any&mode=path&searchon=contents&keywords=systemd-backlight> >and Debian sid > > <https://packages.debian.org/search?suite=sid&arch=any&mode=path&searchon=contents&keywords=systemd-backlight> >there is /usr/lib/systemd/systemd-backlight service >- in Ubuntu Utopic > > <http://packages.ubuntu.com/search?searchon=contents&keywords=systemd-backlight&mode=filename&suite=utopic&arch=any> >and Ubuntu Vivid > > <http://packages.ubuntu.com/search?searchon=contents&keywords=systemd-backlight&mode=filename&suite=vivid&arch=any> >there is /usr/lib/systemd/systemd-backlight service > > There is no backlight load/save functionality in (neither upstart nor > systemd): > >- Ubuntu Lucid >- Ubuntu Precise >- Ubuntu Trusty >- Debian Wheezy >- Debian Squeeze > > So it seems that modern distros have backlight load/save functionality > via systemd-backlight service > <http://www.freedesktop.org/software/systemd/man/systemd-backli...@.service.html>, > but older systems does not have this functionality at all. > > > This problem is well-described on launchpad (see bug 1270579 > <http://bugs.launchpad.net/bugs/1270579> ) and on > AskUbuntu (see my comment > <http://askubuntu.com/questions/151651/brightness-is-reset-to-maximum-on-every-restart/227553#227553> > on it). Around 160 users are affected. > > Steps to reproduce: > 1. User boots laptop (cold boot, not wake from suspend) > 2. User sets comfortable backlight level > 3. User ends his/her work by shutting down the laptop (not suspend, so > backlight level is not saved) > 4. Go to 1 (another cold boot with resetted backlight level). >
Display backlight level save and restore as a init-script / upstart job for laptops
Dear Ubuntu and Debian developers! I understand that you are very busy, but laptop users have problems with saving and restoring display backlight level in Debian and Ubuntu. Systemd-based distros (Fedora, OpenSuSe, Arch, Sabayon, Mageia) have this functionality out the box (they have systemd-backlight@.service <https://github.com/systemd/systemd/commits/56f64d95763a799ba4475daf44d8e9f72a1bd474/src/backlight/backlight.c>), but sysvinit and upstart not. Here is a list: - in Arch backlight brightness load and save are provided by systemd (see Arch wiki <https://wiki.archlinux.org/index.php/backlight#systemd-backlight_service>), it is in systemd <https://www.archlinux.org/packages/core/x86_64/systemd/> package. - in OpenSUSE 13.1, OpenSUSE 13.2, CentOS 7, Fedora 20, Fedora 21, Mageia 4 - systemd package <http://pkgs.org/search//usr/lib/systemd/systemd-backlight?type=files> - Sabayon has /usr/lib/systemd/systemd-backlight service - ALT Linux p7 has systemd, but does not have /usr/lib/systemd/systemd- backlight service - in Debian Jessie <https://packages.debian.org/search?suite=jessie&arch=any&mode=path&searchon=contents&keywords=systemd-backlight> and Debian sid <https://packages.debian.org/search?suite=sid&arch=any&mode=path&searchon=contents&keywords=systemd-backlight> there is /usr/lib/systemd/systemd-backlight service - in Ubuntu Utopic <http://packages.ubuntu.com/search?searchon=contents&keywords=systemd-backlight&mode=filename&suite=utopic&arch=any> and Ubuntu Vivid <http://packages.ubuntu.com/search?searchon=contents&keywords=systemd-backlight&mode=filename&suite=vivid&arch=any> there is /usr/lib/systemd/systemd-backlight service There is no backlight load/save functionality in (neither upstart nor systemd): - Ubuntu Lucid - Ubuntu Precise - Ubuntu Trusty - Debian Wheezy - Debian Squeeze So it seems that modern distros have backlight load/save functionality via systemd-backlight service <http://www.freedesktop.org/software/systemd/man/systemd-backli...@.service.html>, but older systems does not have this functionality at all. This problem is well-described on launchpad (see bug 1270579 <http://bugs.launchpad.net/bugs/1270579> ) and on AskUbuntu (see my comment <http://askubuntu.com/questions/151651/brightness-is-reset-to-maximum-on-every-restart/227553#227553> on it). Around 160 users are affected. Steps to reproduce: 1. User boots laptop (cold boot, not wake from suspend) 2. User sets comfortable backlight level 3. User ends his/her work by shutting down the laptop (not suspend, so backlight level is not saved) 4. Go to 1 (another cold boot with resetted backlight level). I prepared draft version for saving and restoring display backlight level on laptops - it is saved on launchpad (upstart_brightness.tar.gz archive <https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1270579/+attachment/4288756/+files/upstart_brightness.tar.gz> , see comment #18 on launchpad <https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1270579/comments/18>) and may be installed to the system manually with sudo tar -zxvf upstart_brightness.tar.gz -C / My script was tested on Ubuntu 12.04 and Ubuntu 14.04 - see reports on AskUbuntu <http://askubuntu.com/questions/151651/brightness-is-reset-to-maximum-on-every-restart/227553#227553>, Launchpad <https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1270579/comments/22> and forum.ubuntu.ru <http://forum.ubuntu.ru/index.php?topic=255145.0;all> on laptops with discrete, integrated and hybrid graphics card. Please reply to this message if you are interested in such init-script. Thank you! With best regards, Debian and Ubuntu user, Norbert. P.S. I found interesting projects for the same purpose - first is named Light and hosted on GitHub <https://github.com/haikarainen/light> (previously known as LightScript <http://haikarainen.dotgeek.org/lightscript/>), second is named Relight <http://xyne.archlinux.ca/projects/relight/>. But I think that init-script approach is better. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Backlight level save and restore as a init-script / upstart job for laptops
Dear Petter! Thank you for reply. Here is a list: - in Arch backlight brightness load and save are provided by systemd (see Arch wiki <https://wiki.archlinux.org/index.php/backlight#systemd-backlight_service>), it is in systemd <https://www.archlinux.org/packages/core/x86_64/systemd/> package. - in OpenSUSE 13.1, OpenSUSE 13.2, CentOS 7, Fedora 20, Fedora 21, Mageia 4 - systemd package <http://pkgs.org/search//usr/lib/systemd/systemd-backlight?type=files> - Sabayon has /usr/lib/systemd/systemd-backlight service - ALT Linux p7 has systemd, but does not have /usr/lib/systemd/systemd-backlight service - in Debian Jessie <https://packages.debian.org/search?suite=jessie&arch=any&mode=path&searchon=contents&keywords=systemd-backlight> and Debian sid <https://packages.debian.org/search?suite=sid&arch=any&mode=path&searchon=contents&keywords=systemd-backlight> there is /usr/lib/systemd/systemd-backlight service - in Ubuntu Utopic <http://packages.ubuntu.com/search?searchon=contents&keywords=systemd-backlight&mode=filename&suite=utopic&arch=any> and Ubuntu Vivid <http://packages.ubuntu.com/search?searchon=contents&keywords=systemd-backlight&mode=filename&suite=vivid&arch=any> there is /usr/lib/systemd/systemd-backlight service There is no backlight load/save functionality in (neither upstart nor systemd): - Ubuntu Lucid - Ubuntu Precise - Ubuntu Trusty - Debian Wheezy - Debian Squeeze So it seems that modern distros have backlight load/save functionality via systemd-backlight service <http://www.freedesktop.org/software/systemd/man/systemd-backli...@.service.html>, but older systems does not have this functionality at all. For older (but supported) systems one can use my script with symlinks (may be with some files in /etc/pm/). I mean Debian 6, 7 and Ubuntu 12.04, 14.04. If you have any suggestions and recommendations - I'm ready to hear. What you and other developers think? With best regards, Norbert. P.S. I found interesting projects for the same purpose - first is named Light and hosted on GitHub <https://github.com/haikarainen/light> (previously known as LightScript <http://haikarainen.dotgeek.org/lightscript/>), second is named Relight <http://xyne.archlinux.ca/projects/relight/>. But I think that init-script approach is better. On Tue, Dec 23, 2014 at 12:44 PM, Petter Reinholdtsen wrote: > [Nrbrtx] > > I have tested many distros - Arch, OpenSuSe 13.1, Fedora 20, ALT Linux > p7, > > Sabayon, Mageia 4. > > Many of them are based on systemd. > > It does not matter what init system they use, but all of them have very > > useful script (or binary program, I don't know) for saving and restoring > > backlight level on laptop. > > > > In these distros there is a script for save and restore backlight levels > > for two video-cards (acpi_video0 and acpi_video1). During system boot it > is > > indicated as follows: > > While this seem like a useful feature, it can only be implemented once > it is decided which package should take resposibility for it. In which > package is this handled byArch, OpenSuSe 13.1, Fedora 20, ALT Linux p7, > Sabayon and Mageia 4? Can you check, as you haveaccess to these > already? I do not. Knowing this might give an idea where to fix it in > Debian and Ubuntu. :) > > I do not expect to have time to work on this myself any time soon, but > hope someone will. :) > > -- > Happy hacking > Petter Reinholdtsen > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Backlight level save and restore as a init-script / upstart job for laptops
[Nrbrtx] > I have tested many distros - Arch, OpenSuSe 13.1, Fedora 20, ALT Linux p7, > Sabayon, Mageia 4. > Many of them are based on systemd. > It does not matter what init system they use, but all of them have very > useful script (or binary program, I don't know) for saving and restoring > backlight level on laptop. > > In these distros there is a script for save and restore backlight levels > for two video-cards (acpi_video0 and acpi_video1). During system boot it is > indicated as follows: While this seem like a useful feature, it can only be implemented once it is decided which package should take resposibility for it. In which package is this handled byArch, OpenSuSe 13.1, Fedora 20, ALT Linux p7, Sabayon and Mageia 4? Can you check, as you haveaccess to these already? I do not. Knowing this might give an idea where to fix it in Debian and Ubuntu. :) I do not expect to have time to work on this myself any time soon, but hope someone will. :) -- Happy hacking Petter Reinholdtsen -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Backlight level save and restore as a init-script / upstart job for laptops
Dear Debian and Ubuntu developers! Let me inform you about the problem. The problem is well described on LaunchPad - see http://bugs.launchpad.net/bugs/1270579 (21 users affected). Here I can repeat myself. I have tested many distros - Arch, OpenSuSe 13.1, Fedora 20, ALT Linux p7, Sabayon, Mageia 4. Many of them are based on systemd. It does not matter what init system they use, but all of them have very useful script (or binary program, I don't know) for saving and restoring backlight level on laptop. In these distros there is a script for save and restore backlight levels for two video-cards (acpi_video0 and acpi_video1). During system boot it is indicated as follows: [ OK ] Started Load/Save Screen Backlight Brightness of acpi_video1. [ OK ] Started Load/Save Screen Backlight Brightness of acpi_video0. I have a draft version, which works normally on my VAIO F13Z1R laptop with Ubuntu 12.04.4. It is in attachment. You can use it unmodified or modify it for compatibility or something. I made symlinks for it: ln -s /etc/init.d/brightness /etc/rc0.d/S25backlight ln -s /etc/init.d/brightness /etc/rcS.d/S25backlight ln -s /etc/init.d/brightness /etc/rc6.d/S25backlight For details you can read my comment on askubuntu ( http://askubuntu.com/a/227553/66509). I think that having a script for saving and restoring backlight level is very useful for laptop Ubuntu users. So, please, add such init script to default Debian and Ubuntu installation. Thank you! With best regards, Debian and Ubuntu user, Norbert. upstart_backlight.tar.gz Description: GNU Zip compressed data -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On Fri, 05 Dec 2014 12:00:28 + ubuntu-devel-discuss-requ...@lists.ubuntu.com wrote: > Well, you're welcomed to join me :) > > I'll yet have to sort out certain conceptional issues regarding > authentication. > > For now, I'm pretty clear that it will be something 9P and factotum > based and shall be compatible with the usual Plan9 ways (so it's > also suited for distributed systems). I don't know the details of those but wonder if you have considered making it user centric with sudo or giving users options such as spacefm does with udevil or sudo etc.. sudo and polkit are widely misunderstood! -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On 03.12.2014 23:32, Vittorio wrote: > If really you could succeed in getting rid of polkit and dbus, that > would be a very good work. > I completely agree with you. Polkit has given me a lot of headaches. Well, you're welcomed to join me :) I'll yet have to sort out certain conceptional issues regarding authentication. For now, I'm pretty clear that it will be something 9P and factotum based and shall be compatible with the usual Plan9 ways (so it's also suited for distributed systems). But I haven't sorted out, who exactly will maintain the sessions (and session keys), and how to do service startup and mounting, especially regarding the differences between Linux and Plan9. My current thoughts go like this: * user services visible to some user can be expected to be posted within some directory in his home directory. perhaps this will directory will be configurable via env (to support multiple sessions w/o separate namespaces) * system services are posted in some global (world readable dir) * maybe: those which are accessible to some user are also symlinked to his home / session dir * traditional group-based access controls can be used here * for finer access control, services can be authenticated via factotum (user and host factotum) * an separate control agent (maybe acting on user login, eg. via pam, etc) generates keys for system services and adds them to host factotum, so system services can be accessed by them * users that should be allowed to access them also get the corresponding keys into their user / session factotum, so it can authenticate * in case we really need a hard separation between sessions (so session privileges cannot be stole by the same user, into other sessions), we can run the session factotums under a different uid and configure it to never tell secrets uhm, I might expect too much Plan9 knowledge here ... sorry for that ;-o maybe we should get into deeper discussion on the 9fans list. cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On 29.11.2014 22:31, I.E.G. wrote: Hi, > I was a "little" surprised to see the "...has been converted to an > upstart job" message some time ago in response to a ~$ /etc/init.d/ > stop/start/restart/foo . > I tried the ~$ service stop/start/restart/foo and it either didn't work > or produced the same "...has been converted to an upstart job". Yeah, had the same problems... > I'll just offer one example of what I don't want to see . A deployment > or migration such as the the protracted abortion that was PulseAudio . I > still have several hardware instances that never did (and I suspect > never will) tolerate PulseAudio. For me, it at least works w/ my hardware, but far from rock-stable. I regularily have to kill and restart it. In fact, I never really understood why it's necessary at all. Okay, moving more stuff into userland has some benefits (eg. adding virtual devices running as separate servers, etc) - but then it should be done more consequently, like Plan9 does. Maybe, if i've someday got enough spare time, I'll fork it and rebuild it to an plan9'ish system-wide service. Then it would make sense to move all audio applications to that service only (dropping all native alsa support). But for now, I'm still too occupied with other things. For now I'm more concerned with getting rid of dbus/polkit. > I even had PA/Devl tell me to upgrade my > month old hardware in order to make it work (a long and only slightly > humorous story I'll spare you ) . Well, the usual Lennartists behaviour ... cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On 29.11.2014 00:39, Dimitri John Ledkov wrote: Hi, > Similarly, 16.04 LTS is not yet planned, thus i'm not sure whether it > will or won't ship upstart. If it does, it will be another 5 years > from then, or 2021. I really hope, it will continue to ship upstart and doesn't push towards systemd than it already does (eg. could anybody perhaps explain, what I really need that logind for ?). Otherwise people will move away (and never come back). cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On 28.11.2014 13:41, Ben Tinner wrote: Hi, > Recently, the developers of Ubuntu have decided to migrate the init > system from upstart to systemd. > > So, I would like to find out what will happen to upstart after Ubuntu > complete its transition to systemd. That might also depend on which init systems the debianfork project is going to support upstart (besides openrc and sysv init), and how many Ubuntu folks move over to debianfork. I, personally, *will* move over, as soon as systemd becomes mandatory (if there wasn't debianfork, it would be Gentoo). The already mandatory Lennartware already caused more than enough pain. Actually, I'm preparing a fork of NetworkManager, getting rid of all the dbus and polkit crap, which causes more problems than it solves. Haven't decided yet, whether the interface will be fuse or 9P (both have their pros and cons), but definitively will be a data driven filesystem-based approach. In the next round, I'll heavily trim down network-manager-gnome to get rid of all the unnecessary stuff (eg. I dont use BT, and i dont want it. period.) cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The fate of Upstart
On 28 November 2014 at 12:41, Ben Tinner wrote: > Hello > > > Recently, the developers of Ubuntu have decided to migrate the init system > from upstart to systemd. > > So, I would like to find out what will happen to upstart after Ubuntu > complete its transition to systemd. > > Will development of upstart be abandoned after the transition is completed? At the moment Ubuntu Phone, Ubuntu (and derivatives) and ChromeOS are the largest users of Upstart. Ubuntu 14.04 LTS is a long-term supported release, 5 years, until 2019. Similarly, 16.04 LTS is not yet planned, thus i'm not sure whether it will or won't ship upstart. If it does, it will be another 5 years from then, or 2021. I do not know the support time-frames of the phone product, it's a question for Canonical and their partners, rather than the Ubuntu project. But at the moment it is based on Upstart as well. 2019-2021 is far enough into the future that all predictions are moot. Upstart is very large and stable piece of software and it is not under active (rewrite) / feature work. Thus latest work is mostly focused on extending and creating optional features or fixing corner case bugs in the core. One of the largest portions of work that is not merged is incomplete support for FreeBSD kernel (and GNU user-space) as shipped by the Debian kFreeBSD port. That has stalled a bit, since my interests have shifted and Debian kFreeBSD port is no longer planned for "official-official" release. -- Regards, Dimitri. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
The fate of Upstart
Hello Recently, the developers of Ubuntu have decided to migrate the init system from upstart to systemd. So, I would like to find out what will happen to upstart after Ubuntu complete its transition to systemd. Will development of upstart be abandoned after the transition is completed?-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Where can I find more docs/help on upstart?
On Tue, Sep 7, 2010 at 9:46 AM, Paul Smith wrote: > On Tue, 2010-09-07 at 11:28 +0100, Matthew Paul Thomas wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Paul Smith wrote on 04/09/10 20:46: >> > >> > Esp. how it interacts with Ubuntu/Debian packaging. >> >... >> > So far my Google/etc. searching for admin-level details of upstart >> > hasn't netted me very much. >> >... >> >> Have you found <http://upstart.ubuntu.com/wiki/>? > > Yes, thanks for that. Most pages there are specifications for future > improvements. > > The documentation about today's implementation doesn't give any hints > about how a service can be disabled, a la update-rc.d disable. > > All I can find is the description of the init file. I don't know if there is an 'official' way to disable a job, but the two ways I have used in the past are: 1) Rename it so that it doesn't end with .conf. Upstart only watches .conf files, so renaming it to .conf.disabled will kill it. 2) Add an unused event (like 'never') to the 'start on' field. As long as nothing emits the 'never' event, then the job will never start. 1 seems more robust in that 2 can still be started by upstart accidentally if something emits an event that it shouldn't. However, I believe 2 plays more nicely with dpkg and how it manages configuration files (upstart files are listed as debian conf files). If you're still looking for a better answer, try asking on https://lists.ubuntu.com/mailman/listinfo/upstart-devel Evan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Where can I find more docs/help on upstart?
On Tue, 2010-09-07 at 11:28 +0100, Matthew Paul Thomas wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Paul Smith wrote on 04/09/10 20:46: > > > > Esp. how it interacts with Ubuntu/Debian packaging. > >... > > So far my Google/etc. searching for admin-level details of upstart > > hasn't netted me very much. > >... > > Have you found <http://upstart.ubuntu.com/wiki/>? Yes, thanks for that. Most pages there are specifications for future improvements. The documentation about today's implementation doesn't give any hints about how a service can be disabled, a la update-rc.d disable. All I can find is the description of the init file. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Where can I find more docs/help on upstart?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Smith wrote on 04/09/10 20:46: > > Esp. how it interacts with Ubuntu/Debian packaging. >... > So far my Google/etc. searching for admin-level details of upstart > hasn't netted me very much. >... Have you found <http://upstart.ubuntu.com/wiki/>? Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyGE+EACgkQ6PUxNfU6ecqEpACcCZw7Y9Z0RDgiziKy+ZbAytNj zeAAn17LNLPA2SppxyBOPDq/d736OhOZ =nvFb -END PGP SIGNATURE- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Where can I find more docs/help on upstart?
Esp. how it interacts with Ubuntu/Debian packaging. For example on my Ubuntu 10.04 system I installed tftpd-hpa and find that it's been converted to upstart. No problem, except that I don't want it to start when my system boots, I want it to be started via xinetd (I need it to work this way in order to test compatibility with other software; please don't suggest "just don't do that"... I have to do it). What's the proper/recommended way to change the configuration of this package so that (a) it doesn't conflict with new packages installed, and (b) upstart does not try to start tftpd when my system boots. In the "old" SysV way there were fancy tools that managed the SysV symlinks and a method for modifying them that was, be consensus, preserved across upgrades/etc. How do I do the equivalent thing with upstart? I (finally) found the init.5 man page so I see the format of the config file, but is there some way to customize the startup of these packages other than hand-editing conf files? So far my Google/etc. searching for admin-level details of upstart hasn't netted me very much. Thanks! -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
>> 1. Why does /lib/init/upstart-job direct us to use service rather than >> initctl? > Because /usr/sbin/service can handle the start/stop/restart/status > actions of both traditional System V init scripts in /etc/init.d as > well as Upstart scripts in /etc/init. > It's intended to be one-stop-shopping for managing services in either > /etc/init.d or /etc/init. Many thanks for the explanation. >> 999. Could initctl be made to recognize, for example, both >> avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare >> but it happens - and type "stop av//tab//", I end up with "stop >> avahi-daemon.conf" which, after pressing //enter// results in an >> "unknown job" message.) > As answered above, that's service(8)'s job ;-) Perhaps that it is service's job, but it is also initctl's; and without, bash_completion, neither can distinguish between avahi-daemon and avahi-daemon.conf. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
>>> 999. Could initctl be made to recognize, for example, both
>>> avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare
>>> but it happens - and type "stop av//tab//", I end up with "stop
>>> avahi-daemon.conf" which, after pressing //enter// results in an
>>> "unknown job" message.)
>> That sounds like the lack of a specialised bash-completion function?
> This seems to do the job (except for completions of arguments for --dest):
> --8<---cut here---start->8---
> _stop()
> {
> local cur
>
> COMPREPLY=()
> cur=${COMP_WORDS[COMP_CWORD]}
>
> case "$cur" in
> -*)
> COMPREPLY=( $( compgen -W '-n --no-wait --system --dest -q
> --quiet -v --verbose --help --version' -- $cur ) )
> ;;
> *)
> COMPREPLY=( $(initctl list| awk "/^$cur/ {print \$1}" ) )
> ;;
> esac
>
> return 0
>
> }
> complete -F _stop stop
> --8<---cut here---end--->8---
It works perfectly, thanks. I have never used bash_completion before;
it completes "avahi-daemon" no matter which dir I am in.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
On Sun, Mar 7, 2010 at 2:21 PM, Tom H wrote: > Patrick's two Upstart posts reminded me of 2.5 queries of my own. > > 1. Why does /lib/init/upstart-job direct us to use service rather than > initctl? Because /usr/sbin/service can handle the start/stop/restart/status actions of both traditional System V init scripts in /etc/init.d as well as Upstart scripts in /etc/init. It's intended to be one-stop-shopping for managing services in either /etc/init.d or /etc/init. > 999. Could initctl be made to recognize, for example, both > avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare > but it happens - and type "stop av//tab//", I end up with "stop > avahi-daemon.conf" which, after pressing //enter// results in an > "unknown job" message.) As answered above, that's service(8)'s job ;-) :-Dustin -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
Jan Claeys writes:
> Op zondag 07-03-2010 om 15:21 uur [tijdzone -0500], schreef Tom H:
>> 999. Could initctl be made to recognize, for example, both
>> avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare
>> but it happens - and type "stop av//tab//", I end up with "stop
>> avahi-daemon.conf" which, after pressing //enter// results in an
>> "unknown job" message.)
>
> That sounds like the lack of a specialised bash-completion function?
This seems to do the job (except for completions of arguments for --dest):
--8<---cut here---start->8---
_stop()
{
local cur
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
case "$cur" in
-*)
COMPREPLY=( $( compgen -W '-n --no-wait --system --dest -q
--quiet -v --verbose --help --version' -- $cur ) )
;;
*)
COMPREPLY=( $(initctl list| awk "/^$cur/ {print \$1}" ) )
;;
esac
return 0
}
complete -F _stop stop
--8<---cut here---end--->8---
Florian
--
GUIs programmieren mit Python und Glade:
Re: Upstart
Op zondag 07-03-2010 om 15:21 uur [tijdzone -0500], schreef Tom H: > 999. Could initctl be made to recognize, for example, both > avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare > but it happens - and type "stop av//tab//", I end up with "stop > avahi-daemon.conf" which, after pressing //enter// results in an > "unknown job" message.) That sounds like the lack of a specialised bash-completion function? -- Jan Claeys -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Upstart
Patrick's two Upstart posts reminded me of 2.5 queries of my own. 1. Why does /lib/init/upstart-job direct us to use service rather than initctl? 2. With initctl, upstart has the equivalent of invoke-rc.d/service. Is there or will there be the equivalent of update-rc.d/chkconfig? 999. Could initctl be made to recognize, for example, both avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare but it happens - and type "stop av//tab//", I end up with "stop avahi-daemon.conf" which, after pressing //enter// results in an "unknown job" message.) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart (now, a very modest suggestion)
> So, I'm testing samba on a Lucid alpha 3, and I decide to restart the > smbd daemon: > sudo /etc/init.d/samba restart > sudo: /etc/init.d/samba: command not found > Oops, I guess it's a service now? > sudo service samba restart > samba: unrecognized service > So of course it only took a little digging to discover that smbd and > nmbd are now services started separately, and that (bizarrely) there is > now a winbind daemon which is still started from /etc/init.d, but > nevertheless a bit unnerving. (And why and since when has winbind been a > separate daemon, anyway?! But I digress.) I assume that the samba job has been split into two because there was a problem with nmbd not starting when smbd and nmbd were launched through samba. If you look at the respective conf files, you will see that nmbd requires a nic other than lo to be up before starting. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
On Fri, 2010-03-05 at 14:50 -0600, Patrick Goetz wrote: > > D-Bus is used to communicate with the init daemon, and one of the method > > calls you may make is to emit an event. The event name is simply a > > string, and the arguments an array of strings. There's no need to > > configure Upstart to accept certain events, you just make them up as you > > go along. > > > > Thanks for the detailed response, this is all starting to make sense. > So if service Z can't start until services A,B, and C have already > started the /etc/init/Z.conf file would contain the line: > >start on (A started and B started and C started) > ? > We don't tend to describe it that way. We say that "service Z should be started as a result of services A, B and C having been started". (Because a sysadmin can always come along and run "start Z" by themselves) > And if D alternatively replaces A and C, then this becomes > >start on ((A started and B started and C started) or > (B started and D started)) > ? > Yes. > One last question. I'm curious about the technical details of how this > is implemented; i.e. what blocks Z until A,B, and C have started? Does > upstart or some process simply make a list of /\/etc\/init\/(.+)\.conf/ > and then poll through the list in a loop looking to see if the 'start > on' conditions have already been met => send a startup $1 signal to > init, remove $1 from the list whenever it does? > No, this describes a fairly poorly implemented dependency based init system. Upstart is event based, and is thus the exact opposite. Upstart parses all *.conf files under /etc/init and creates in-memory objects for each of them, which have event matches. Each time an event occurs, Upstart marks any event matches as TRUE for them. If a job's event tree is TRUE, then it gets started. A good way of describing the difference is: a dependency based system (such as you described) thinks "can I start foo yet? no, it needs bah" an event based system (like Upstart) thinks "bah just started, what else can I start now?" Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
Scott James Remnant wrote: > You might have forgotten to plug your USB > mouse in this boot; or maybe your cat has chewed the ethernet cable > overnight and it won't come up, etc. > Actually, it was my gerbil that frequently chewed through the ethernet cable, but then the cat ate the gerbil, so that bug has been resolved, so to speak. > D-Bus is used to communicate with the init daemon, and one of the method > calls you may make is to emit an event. The event name is simply a > string, and the arguments an array of strings. There's no need to > configure Upstart to accept certain events, you just make them up as you > go along. > Thanks for the detailed response, this is all starting to make sense. So if service Z can't start until services A,B, and C have already started the /etc/init/Z.conf file would contain the line: start on (A started and B started and C started) ? And if D alternatively replaces A and C, then this becomes start on ((A started and B started and C started) or (B started and D started)) ? One last question. I'm curious about the technical details of how this is implemented; i.e. what blocks Z until A,B, and C have started? Does upstart or some process simply make a list of /\/etc\/init\/(.+)\.conf/ and then poll through the list in a loop looking to see if the 'start on' conditions have already been met => send a startup $1 signal to init, remove $1 from the list whenever it does? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart (now, a very modest suggestion)
On Fri, 2010-03-05 at 12:27 -0600, Patrick Goetz wrote: > So of course it only took a little digging to discover that smbd and > nmbd are now services started separately, and that (bizarrely) there is > now a winbind daemon which is still started from /etc/init.d, but > nevertheless a bit unnerving. (And why and since when has winbind been a > separate daemon, anyway?! But I digress.) > > During the transition from Debianized Sys V Init to Upstart, how > difficult would it be to keep the comfortable old /etc/init.d scripts in > place, but so that these scripts simply tell command line users > something like: > > pgo...@data:~$ sudo /etc/init.d/samba restart > > The samba daemons are now started individually as services: try > service smbd restart > and/or > service nmbd restart > Oh, and note that winbindd is now a separate process -- happy debugging! > > > Again, some people, possibly myself, are old, feeble-minded, and > distracted with lots of problems that go beyond the function of basic > linux server services, hence discomfited when start/stop/restart > commands that have worked for 10 years are suddenly missing with no > explanation of how to proceed in the new world order. > That's exactly what we've done for the most part: quest scott# /etc/init.d/cron restart Rather than invoking init scripts through /etc/init.d, use the service(8) utility, e.g. service cron restart Since the script you are attempting to invoke has been converted to an Upstart job, you may also use the restart(8) utility, e.g. restart cron cron start/running, process 20151 Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
On Fri, 2010-03-05 at 12:09 -0600, Patrick Goetz wrote: > Scott James Remnant wrote: > > Anyone can emit any event. That's probably the bit of Upstart that > > people find the hardest to get to grips with, so there can never be any > > comprehensive list of every event and every argument - because anyone > > can add a new one. > > > From a system administrators' perspective, this sounds like a debugging > nightmare, since anyone not documenting an emitted event as outlined > above leaves you with no idea of what is going on or how things > interact. I think it's extremely important to either have or be able to > produce a text file which definitely indicates the sequence(s) of > [particular] event dependencies. (I.e., I don't want to rely on > someone's remembering to put a comment in a text file, I want to know > what's actually going on for sure.) > An event is simply an abstraction of some kind of change to your computer's state; it might be new hardware being detected, it might be a particular filesystem (or group of filesystems) being mounted. It might even be the user pressing a key combination on the keyboard, or shutting the lid. They don't have "dependencies", nor do they have ordering or sequences. Upstart was designed from the principle that since we can no longer control the order that things happen in, or even whether certain things happen, we should instead design a system that lets you define what a service needs. You can't know what's going on for sure without letting the computer boot and see what happens. You might have forgotten to plug your USB mouse in this boot; or maybe your cat has chewed the ethernet cable overnight and it won't come up, etc. > The events are emitted over D-bus? Unfortunately I don't know much > about d-bus, so pardon my ignorance if this is a dumb question, but is > there some kind of Upstart d-bus configuration file which documents all > the events the upstart daemon is configured to handle? How does Upstart > decide how to sequence services based on the events they emit? > D-Bus is used to communicate with the init daemon, and one of the method calls you may make is to emit an event. The event name is simply a string, and the arguments an array of strings. There's no need to configure Upstart to accept certain events, you just make them up as you go along. Upstart doesn't "sequence services". > Perhaps a specific example would help: > > Let's say, for the sake of argument, that autofs is failing to start > because of some daemon initialization timing problem (I use this example > because this is a problem we've actually had with Ubuntu desktop clients). > > 1. > How would I go about figuring out what the *linear* sequence of events > is related to the autofs service? I.e. I understand that lots of stuff > is going to be started in parallel, but I want to know the startup > dependencies for that particular service. This was very easy to figure > out with System V init on Debian: >ls /etc/rc2.d > followed by a few peeks at files in /etc/init.d. > There is no *linear* sequence of events. Purge that assumption from your mind. In an Upstart system, you look at the "start on" (or "while" in future versions) line in the /etc/init/autofs.conf file. That tells you what condition will cause autofs to be started/running. > 2. > OK, I've rolled out Ubuntu X.Y and discover that a (mission-critical) > service is not starting because of an event sequencing boo-boo, > intermittent timing problem, or what not. In 9.4, for autofs, we solved > this by throwing a few sleep 1's in the /etc/init.d/autofs file > What recourse do I have to fix the problem myself on an Upstart-based > system? Please note that in trenches one encounters fire-breathing > dragon users who aren't satisfied with the response "oh, we logged a bug > on launchpad, so this should be working in a couple of weeks -- we > hope.". System administrators who like to stay employed are most > comfortable with solutions, even if hacks or band-aids, that they can > deploy themselves while waiting for the Olympians to act. <:) > Simple; you'd modify the /etc/init/autofs.conf file and either fix the "start on"/"while" line (which must be wrong if the service is failing to start) - or modify the script/exec lines to correct how autofs is started. > 3. > I have to install a commercially provided service and these bozos > couldn't care less about dpkg, Ubuntu, or anything other than their > lucre (why is lucre always filthy?). The service is probably a license > manager, or something like this. How does thi
Re: Upstart (now, a very modest suggestion)
On Fri, 05 Mar 2010 13:54:48 -0500 Ben Gamari wrote: > Excerpts from Patrick Goetz's message of Fri Mar 05 13:27:52 -0500 > 2010: > > So of course it only took a little digging to discover that smbd > > and nmbd are now services started separately, and that (bizarrely) > > there is now a winbind daemon which is still started > > from /etc/init.d, but nevertheless a bit unnerving. (And why and > > since when has winbind been a separate daemon, anyway?! But I > > digress.) > > With all due respect, you are using alpha software. Documentation is > generally one of the last things to be completed. I would hope these > init changes will be thoroughly documented before release. Moreover, > it sounds like most of what confused you were changes in Samba's > packaging, not upstart itself. At the same time, it never hurts to be reminded, most of all about missing docs. > > > > Again, some people, possibly myself, are old, feeble-minded, and > > distracted with lots of problems that go beyond the function of > > basic linux server services, hence discomfited when > > start/stop/restart commands that have worked for 10 years are > > suddenly missing with no explanation of how to proceed in the new > > world order. > > > Certainly, but if you are having difficulty with this, you probably > ought to stick with releases. I am sorry, but I do not agree. The difficulty one (be it Patrick, or whoever) is having on a development release will probably be even greater after a release. Even more, we *need* testers, and we *need* to have feedback. Feedback after the release of a version will probably only be acted on for the next release, while feedback during development allows for (possible) action in time for the release. I would rather have a lot of (even misguided) feedback than none at all (and, by the way, I think Patrick is raising some good points). Cheers, ..C.. signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart (now, a very modest suggestion)
Excerpts from Patrick Goetz's message of Fri Mar 05 13:27:52 -0500 2010: > So of course it only took a little digging to discover that smbd and > nmbd are now services started separately, and that (bizarrely) there is > now a winbind daemon which is still started from /etc/init.d, but > nevertheless a bit unnerving. (And why and since when has winbind been a > separate daemon, anyway?! But I digress.) With all due respect, you are using alpha software. Documentation is generally one of the last things to be completed. I would hope these init changes will be thoroughly documented before release. Moreover, it sounds like most of what confused you were changes in Samba's packaging, not upstart itself. > > During the transition from Debianized Sys V Init to Upstart, how > difficult would it be to keep the comfortable old /etc/init.d scripts in > place, but so that these scripts simply tell command line users > something like: > Just use the service command. It's the way things are going to work moving forward. It wouldn't be difficult to write wrapper scripts, but we really do need to move beyond SysV. > > Again, some people, possibly myself, are old, feeble-minded, and > distracted with lots of problems that go beyond the function of basic > linux server services, hence discomfited when start/stop/restart > commands that have worked for 10 years are suddenly missing with no > explanation of how to proceed in the new world order. > Certainly, but if you are having difficulty with this, you probably ought to stick with releases. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart (now, a very modest suggestion)
So, I'm testing samba on a Lucid alpha 3, and I decide to restart the smbd daemon: sudo /etc/init.d/samba restart sudo: /etc/init.d/samba: command not found Oops, I guess it's a service now? sudo service samba restart samba: unrecognized service So of course it only took a little digging to discover that smbd and nmbd are now services started separately, and that (bizarrely) there is now a winbind daemon which is still started from /etc/init.d, but nevertheless a bit unnerving. (And why and since when has winbind been a separate daemon, anyway?! But I digress.) During the transition from Debianized Sys V Init to Upstart, how difficult would it be to keep the comfortable old /etc/init.d scripts in place, but so that these scripts simply tell command line users something like: pgo...@data:~$ sudo /etc/init.d/samba restart The samba daemons are now started individually as services: try service smbd restart and/or service nmbd restart Oh, and note that winbindd is now a separate process -- happy debugging! Again, some people, possibly myself, are old, feeble-minded, and distracted with lots of problems that go beyond the function of basic linux server services, hence discomfited when start/stop/restart commands that have worked for 10 years are suddenly missing with no explanation of how to proceed in the new world order. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart
Scott James Remnant wrote: > Anyone can emit any event. That's probably the bit of Upstart that > people find the hardest to get to grips with, so there can never be any > comprehensive list of every event and every argument - because anyone > can add a new one. > > However there are "recommendations". > > > First is that if the service a job represents emits an event, it uses > the (purely documentation) "emits" stanza in its job file. That way you > can get a rough idea by parsing /etc/init/*.conf > > $ grep "emits local-filesystems" /etc/init/*.conf > /etc/init/mountall.conf:emits local-filesystems > > So local-filesystems comes from the mountall service. > From a system administrators' perspective, this sounds like a debugging nightmare, since anyone not documenting an emitted event as outlined above leaves you with no idea of what is going on or how things interact. I think it's extremely important to either have or be able to produce a text file which definitely indicates the sequence(s) of [particular] event dependencies. (I.e., I don't want to rely on someone's remembering to put a comment in a text file, I want to know what's actually going on for sure.) The events are emitted over D-bus? Unfortunately I don't know much about d-bus, so pardon my ignorance if this is a dumb question, but is there some kind of Upstart d-bus configuration file which documents all the events the upstart daemon is configured to handle? How does Upstart decide how to sequence services based on the events they emit? Perhaps a specific example would help: Let's say, for the sake of argument, that autofs is failing to start because of some daemon initialization timing problem (I use this example because this is a problem we've actually had with Ubuntu desktop clients). 1. How would I go about figuring out what the *linear* sequence of events is related to the autofs service? I.e. I understand that lots of stuff is going to be started in parallel, but I want to know the startup dependencies for that particular service. This was very easy to figure out with System V init on Debian: ls /etc/rc2.d followed by a few peeks at files in /etc/init.d. 2. OK, I've rolled out Ubuntu X.Y and discover that a (mission-critical) service is not starting because of an event sequencing boo-boo, intermittent timing problem, or what not. In 9.4, for autofs, we solved this by throwing a few sleep 1's in the /etc/init.d/autofs file What recourse do I have to fix the problem myself on an Upstart-based system? Please note that in trenches one encounters fire-breathing dragon users who aren't satisfied with the response "oh, we logged a bug on launchpad, so this should be working in a couple of weeks -- we hope.". System administrators who like to stay employed are most comfortable with solutions, even if hacks or band-aids, that they can deploy themselves while waiting for the Olympians to act. <:) 3. I have to install a commercially provided service and these bozos couldn't care less about dpkg, Ubuntu, or anything other than their lucre (why is lucre always filthy?). The service is probably a license manager, or something like this. How does this interface with the Upstart Init system? Just stuff everything into /etc/rc.local and hope for the best? 4. Presumably there must be developers' documentation for Upstart so that services can be coded to emit d-bus events? Where might one find this documentation? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart? Plymouth?
On Wed, 2010-02-24 at 11:50 -0600, Patrick Goetz wrote: > And probably way to busy to work on documentation. At some point it > would be nice to have a better understanding of how upstart works. The > concept of an event driven init replacement isn't completely jelling in > my little peanut brain; even more so as a replacement for cron/anacron. > > For example, in /etc/init/networking.conf one finds > > start on (local-filesystems >and stopped udevtrigger) > > Hookay, but what/where is "local-filesystems"? I can't find a conf file > for this in /etc/init, although there is one for udevtrigger. > Anyone can emit any event. That's probably the bit of Upstart that people find the hardest to get to grips with, so there can never be any comprehensive list of every event and every argument - because anyone can add a new one. However there are "recommendations". First is that if the service a job represents emits an event, it uses the (purely documentation) "emits" stanza in its job file. That way you can get a rough idea by parsing /etc/init/*.conf $ grep "emits local-filesystems" /etc/init/*.conf /etc/init/mountall.conf:emits local-filesystems So local-filesystems comes from the mountall service. Second is that the service actually documents the event in the form of a manpage (this was missing in karmic, but added in lucid). So $ man 7 local-filesystems DESCRIPTION The local-filesystems event is generated by the moun‐ tall(8) daemon after it has mounted all local filesystems listed in fstab(5). mountall(8) emits this event as an informational signal, services and tasks started or stopped by this event will do so in parallel with other activity. This event is typically used by services that must be started in order for remote filesystems, if any, to be activated. Remember that some users may not consider it wrong to place /usr on a remote filesystem. For most normal services the filesystem(7) event is sufficient. This event will never occur before the virtual-filesys‐ tems(7) event. EXAMPLE A service that wishes to be running once local filesys‐ tems are mounted might use: start on local-filesystems > Right now in Lucid things are a bit of a mess, with a bunch of stuff in > /etc/init and a bunch of other very similar stuff in /etc/init.d. Not a > problem of course if everything just works flawlessly right out of the > box so that I don't even have to think about it, but. <:) > That's because all this is still in development. I've asked nicely to spend the next cycle "finishing" Upstart :-) Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart? Plymouth?
Scott James Remnant wrote: > This is a bug that I'm working on. > > The problem is there's no code in Plymouth to put the VT back ;-) > And probably way to busy to work on documentation. At some point it would be nice to have a better understanding of how upstart works. The concept of an event driven init replacement isn't completely jelling in my little peanut brain; even more so as a replacement for cron/anacron. For example, in /etc/init/networking.conf one finds start on (local-filesystems and stopped udevtrigger) Hookay, but what/where is "local-filesystems"? I can't find a conf file for this in /etc/init, although there is one for udevtrigger. Right now in Lucid things are a bit of a mess, with a bunch of stuff in /etc/init and a bunch of other very similar stuff in /etc/init.d. Not a problem of course if everything just works flawlessly right out of the box so that I don't even have to think about it, but. <:) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upstart? Plymouth?
On Mon, 2010-02-22 at 17:17 -0600, Patrick Goetz wrote: > I'm trying to track down a Lucid AMD64 Server bug to either Upstart or > plymouth, and realized I have no idea how the system decides what vt > console gets focus after boot when no xserver is installed. Can anyone > direct me to some relevant Upstart documentation? > This is a bug that I'm working on. The problem is there's no code in Plymouth to put the VT back ;-) Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Upstart? Plymouth?
I'm trying to track down a Lucid AMD64 Server bug to either Upstart or plymouth, and realized I have no idea how the system decides what vt console gets focus after boot when no xserver is installed. Can anyone direct me to some relevant Upstart documentation? Someone has already (incorrectly, I believe) posted this as a bug in gdm: bug #517842 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: That upstart Upstart
On Tue, 2009-06-30 at 02:56 +0100, Colin Watson wrote: > On Mon, Jun 29, 2009 at 04:11:53PM -0500, Patrick Goetz wrote: > > Doesn't this mean that rcS is stopped before /etc/init.d/rcS is ever > > exec'd, since the runlevel is set before the script is run? In > > particular, when exactly does the runlevel event stop the script? > > I think the 'stop on runlevel' is actually just there to make sure rcS > doesn't keep on trying to start, but Scott could clarify that. > The rcS script might run a root shell (sulogin, usually) in cases of error - the filesystem check failing is a good example here. The user might type "shutdown" at this shell. Or the user might simply press Ctrl-Alt-Delete while rcS is running. The "stop on" therefore makes sure it's all killed so the system can run the shutdown scripts. > (For the avoidance of doubt, this isn't me arguing that the job format > shouldn't be better documented, but rather that if you're searching for > documentation because you want to write Upstart jobs and use them in > production rather than because you want to help with development, you > may be on the wrong track just now.) > Indeed, the lack of detailed documentation is /slightly/ deliberate ;-) Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: That upstart Upstart
On Mon, 2009-06-29 at 16:11 -0500, Patrick Goetz wrote: > Everyone knows the canonical (no pun intended) unix interview question, > namely > > Q: how many processes does the kernel start on boot? > A: Only one -- init > > Apparently this isn't necessarily true any more, or soon won't be? > In the literal sense, it's still true. Once the kernel initialisation has completed, it runs the /sbin/init executable on the root filesystem. It's up to this executable to run all of the other processes on the system. When using System V init, this /sbin/init binary is provided by the sysvinit package. When using Upstart, this binary is provided by the upstart package. While they have different configuration and operation, they are still fundamentally a single binary from which all other processes are spawned. Now, I said literal sense, because on a modern system that's not entirely true. This has nothing to do with Upstart, but simply the way that Linux has evolved. Firstly the root filesystem's /sbin/init is rarely the first process started these days. Instead the /init executable inside a boot-loaded supplied "initial ram filesystem" (initramfs) is actually run; this is then responsible for mounting to the root filesystem, and the final thing it does is exec /sbin/init itself. Thus the new /sbin/init on the root filesystem still has pid #1. Secondly, the kernel isn't just a monolithic processes these days but has many threads of operation. These threads are effectively processes being run inside kernel space, some are even userspace from all effective points of view other than the fact they were spawned by the kernel. Many of these are spawned before init is actually started, but the kernel takes care to assign them pids beginning 2. Thirdly the kernel itself will spawn userspace processes directly itself; the original example of this is that the kernel will execute /sbin/modprobe itself if you open a device node that has no attached driver (passing a magic alias along the lines of char-major-123-4). Other examples are the defunct /sbin/hotplug tool, and apport which is run when a process core dumps. Since these are executed out the kernel, they fall outside of the "everything is run by init" model. > So, this brings us to upstart, the init replacement. After a couple of > days of looking through both the on-line documentation I could find > (http://upstart.ubuntu.com/getting-started.html) and the actual > installed files I find that I still have more than a number of > questions about how this is supposed to work currently and in the > future, as alluded to in this snippet from something posted to one of > the ubuntu devel lists: > > > > Date: Fri, 26 Jun 2009 14:55:16 -0500 > > From: Robbie Williamson > > Subject: Debian/Ubuntu Boot Performance Sprint Summary > > Scott James Remnant stated that he expects to have the > entire Ubuntu boot sequence transitioned over to upstart > by 10.04, with some work already planned for the 9.10 cycle. > - > Great! Always happy to answer any questions about it! :-) > Questions: > 1. the previously referenced site says that jobs files are placed in > /etc/init/jobs.d; actually, they seem to be in /etc/event.d -- what's up > with that? > Upstart is in heavy development, and things are subject to change until 1.0 is out. Once that happens, it'll all be stable and compatible, but up to that point I would rather get things right than be bound to not change things. The document you're reading is from the upstream site, and thus actually documents a later version of Upstart (0.5) than is currently in Ubuntu (0.3) I should probably point out that the next version (0.6) uses a different location again. These location changes generally come with a job format change, so it does actually make migration easier. Why the change at all? /etc/event.d was causing a lot of confusion, people started to think that jobs were events - when the two are quite different. The original reason for using /etc/event.d was that it fitted the /etc/dbus-1/event.d naming for "things run on events". Future versions will just use /etc/init > 2. > lizard:~~$ which init > /sbin/init > lizard:~~$ dpkg -S /sbin/init > upstart: /sbin/init > > So, I'm confused: is init still being used, or what? > Yes. Upstart is an implementation of /sbin/init, thus the binary it installs is still called /sbin/init (since that's what the kernel runs). --version reveals all here: 8<8<8<8<8<8<8< littlebigplanet scott% /sbin/init --version init (upstart 0.6.0) Copyright (C) 2009 Canonical Ltd. This is free software; see the source fo
Re: That upstart Upstart
On Mon, Jun 29, 2009 at 04:11:53PM -0500, Patrick Goetz wrote: > Everyone knows the canonical (no pun intended) unix interview question, > namely > > Q: how many processes does the kernel start on boot? > A: Only one -- init > > Apparently this isn't necessarily true any more, or soon won't be? It's still true to a decent engineering approximation, assuming that you don't count the pile of kernel threads that show up in the process table, things like the kernel calling modprobe on demand sometimes, and the initramfs probably muddies the waters a bit too. For the purposes of a block-diagram-type view of the system this is as sensible an assumption as it ever was, though, and Upstart certainly doesn't change it. > So, this brings us to upstart, the init replacement. After a couple of > days of looking through both the on-line documentation I could find > (http://upstart.ubuntu.com/getting-started.html) and the actual > installed files I find that I still have more than a number of > questions about how this is supposed to work currently and in the > future, as alluded to in this snippet from something posted to one of > the ubuntu devel lists: > > > > Date: Fri, 26 Jun 2009 14:55:16 -0500 > > From: Robbie Williamson > > Subject: Debian/Ubuntu Boot Performance Sprint Summary > > Scott James Remnant stated that he expects to have the > entire Ubuntu boot sequence transitioned over to upstart > by 10.04, with some work already planned for the 9.10 cycle. > - > > Questions: > 1. the previously referenced site says that jobs files are placed in > /etc/init/jobs.d; actually, they seem to be in /etc/event.d -- what's up > with that? Upstart 0.10, which is the series we plan to move to at least for 10.04 (though it's not clear whether that will happen for 9.10) will use /etc/init/jobs.d/; the current version of Upstart in Ubuntu uses /etc/event.d/. This went in tandem with a job file format change so it isn't as gratuitous as it seems - the simultaneous move means that, this time, we don't have to worry about mismatches between old/new Upstart and new/old job files. (I think Scott mostly just preferred the new location though.) > 2. > lizard:~~$ which init > /sbin/init > lizard:~~$ dpkg -S /sbin/init > upstart: /sbin/init > > So, I'm confused: is init still being used, or what? Upstart is an implementation of init. The kernel calls /sbin/init, so that has to exist. It is not sysvinit, the older implementation of the init daemon. > /etc/inittab no longer exists in 9.04/9.10, This goes back as far as 6.10. > Is this init an upstarted init? Yes. > 3. There's much discussion about improving the startup system by moving > to an event driven model. The current implementation in 9.04/9.10alpha > simply mimics System-V init. OK, this is transitional, but how are we > going to get from A to B? Package implementers are not getting > initialization scripts right now (e.g. autofs), what's the plan for > rolling out a new event-driven system and how is it going to work? Roughly, and note that I'm not responsible for implementing most of this so errors and omissions excepted: * Move to a newer upstream version of Upstart to support new facilities, such as better daemon supervision and parsing LSB headers in init scripts * Move Upstart configuration to /etc/init/ * Write debhelper command to install Upstart jobs and add a transitional upstart-job command to allow those jobs to be handled (at least to some extent) by the old sysv-rc system where that's necessary * Start moving core scripts over to Upstart jobs, and ensure that all remaining init scripts we ship include LSB headers * Once a reasonable number of core scripts have been moved over, switch Upstart over to dealing with the rc mechanism itself rather than via /etc/init.d/rc * Existing init scripts will still work; those that declare dependency information via LSB headers will be run once those dependencies are satisfied, while those that don't will be run at the end The devil is in the detail, but this seems viable as a general plan. We clearly can't do a flag day transition where everything moves over at once, for all kinds of reasons. > 4. Related: The concept of run levels is fairly useful, and the core > concept in System-V init. Are run levels going to go way under full > upstart implementation? Not to my knowledge. They remain useful, although since Upstart is more general they don't need to be as deeply embedded into the implementation there. > And if run levels are not going away, how is process of startinɡ > system daemons going to be event driven in any meaningful way? Even in a f
That upstart Upstart
(Apologies in advance for the length of this message -- if you don't care about order and manner in which system daemons are launched, please invoke the Delete key operator immediately.) Everyone knows the canonical (no pun intended) unix interview question, namely Q: how many processes does the kernel start on boot? A: Only one -- init Apparently this isn't necessarily true any more, or soon won't be? I usually don't dig into random subsystems until something fails. In this case, I recently found out that my coworker had "fixed" an autofs startup timing problem in our 8.04 rollout by simply inserting a few sleep loops into the autofs init script. This hack was no longer working in 9.04, which we're testing now (not to mention dramatically increased boot times). Since autofs is a core system service, I suggested that he contact Canonical support and let them know that there is a problem; i.e. as installed by default, autofs fails to start. The support technician who got back to us made a number of comments about how processes are launched which were simply wrong. At this point, Houston: we have a problem. The Ubuntu tech staff isn't even clear on how daemons are launched at startup. So, this brings us to upstart, the init replacement. After a couple of days of looking through both the on-line documentation I could find (http://upstart.ubuntu.com/getting-started.html) and the actual installed files I find that I still have more than a number of questions about how this is supposed to work currently and in the future, as alluded to in this snippet from something posted to one of the ubuntu devel lists: > Date: Fri, 26 Jun 2009 14:55:16 -0500 > From: Robbie Williamson > Subject: Debian/Ubuntu Boot Performance Sprint Summary Scott James Remnant stated that he expects to have the entire Ubuntu boot sequence transitioned over to upstart by 10.04, with some work already planned for the 9.10 cycle. - Questions: 1. the previously referenced site says that jobs files are placed in /etc/init/jobs.d; actually, they seem to be in /etc/event.d -- what's up with that? 2. lizard:~~$ which init /sbin/init lizard:~~$ dpkg -S /sbin/init upstart: /sbin/init So, I'm confused: is init still being used, or what? /etc/inittab no longer exists in 9.04/9.10, and the jobs in /etc/event.d follow the event driven model outlined in the documentation, however there is still an init executable. Is this init an upstarted init? There don't appear to be any other candidate executables in the upstart package. 3. There's much discussion about improving the startup system by moving to an event driven model. The current implementation in 9.04/9.10alpha simply mimics System-V init. OK, this is transitional, but how are we going to get from A to B? Package implementers are not getting initialization scripts right now (e.g. autofs), what's the plan for rolling out a new event-driven system and how is it going to work? 4. Related: The concept of run levels is fairly useful, and the core concept in System-V init. Are run levels going to go way under full upstart implementation? If so, how will the system distinguish between, say, a maintenance single-user boot and what is currently rc2? And if run levels are not going away, how is process of startinɡ system daemons going to be event driven in any meaningful way? 5. Even after reading through the "Getting Started" page twice, the implementation under 9.04 is still confusing. For example, to quote Getting Started: "You list the events you want to start your job with start on, and the events that stop your job with stop on." OK, fair enough. However, here is /etc/event.d/rcS: start on startup stop on runlevel console output script runlevel --set S >/dev/null || true PREVLEVEL=N RUNLEVEL=S export PREVLEVEL RUNLEVEL exec /etc/init.d/rcS end script Doesn't this mean that rcS is stopped before /etc/init.d/rcS is ever exec'd, since the runlevel is set before the script is run? In particular, when exactly does the runlevel event stop the script? Clearly after the rcS script is exec'd (otherwise none of the goodies in /etc/rc2.d would ever get started), but this needs to be documented much more carefully, since not every case will be this clear cut. Again, package implementors can't get the timing down right now under System-V init. This is going to turn into complete pandemonium if the termination of events is ill-defined. 6. "If you're using the example jobs, you will also have runlevel X events, where X is one of 0–6 or S. Jobs will be run alongside the init scripts for that runlevel." Presumably this means in an event dr
