Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Sat, Jul 26, 2014 at 01:08:57AM +0200, Michael Biebl wrote:
> Am 25.07.2014 19:23, schrieb Steve Langasek:
> > systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> > cgmanager, implementing the new post-v205 interfaces.  libpam-systemd now
> > needs to be updated to depend again on systemd-shim (>= 6-4) | systemd-sysv.

> > Michael Biebl has said on IRC that he will take care of this in the next
> > upload of systemd.

> Just a quick followup: After testing cgmanager a bit I stumbled over
> various issues which should be fixed first before I'm going to re-add
> the alternative dependency. I started filing bugs for them.

Thanks for identifying these bugs.

The only bugs still open on cgmanager are a pair of normal-severity bugs. 
What is blocking libpam-systemd re-adding the systemd-shim alternative
dependency now?  It's not reasonable to withhold this alternative until
cgmanager and/or systemd-shim are entirely bug-free by your reckoning. 
Users should have the option to install systemd-shim+libpam-systemd instead
of systemd-sysv, even if that means there are some non-RC bugs.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: unlocking encfs during boot (Re: systemd now appears to be only possible init system in testing)

[Cameron Norman]

El lun, 28 de jul 2014 a las 8:21 , Michael Biebl  
escribió:

Am 28.07.2014 16:53, schrieb Michael Biebl:

 --8<---
 [Unit]
 Description=Unlock EncFS
 DefaultDependencies=no
 After=local-fs.target
 Before=display-manager.service getty@tty1.service
 
 [Service]

 Type=oneshot
 RemainAfterExit=true
 Environment=RootDir=/home/.encfs/crypt
 Environment=MountPoint=/home/crypt
 ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 
'Unlock

 EncFS' | encfs --stdinpass $RootDir $MountPoint"
 ExecStop=/bin/umount $MountPoint
 
 [Install]

 WantedBy=sysinit.target
 -->8---



To show you some additional cool systemd features, I'm going a step
further and make this unit file a completely generic template unit, so
it can easily be re-used, say if you have multiple encfs file systems 
to

unlock and you don't want to copy that file over and over again.

Only 3 small modifications are necessary:
- Rename the file unlock@.service
- Update Description: Description=Unlock %I EncFS
- Use EnvironmentFile=/etc/encfs/%I

The %I is the instance name specfier and denotes the part between
unlock@.service. See man systemd.unit(5)

The resulting template unit looks like this and is completely generic:

--8<---
[Unit]
Description=Unlock %I EncFS
DefaultDependencies=no
After=local-fs.target
Before=display-manager.service getty@tty1.service

[Service]
Type=oneshot
RemainAfterExit=true
EnvironmentFile=/etc/encfs/%I
ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 
'Unlock

EncFS' | encfs --stdinpass $RootDir $MountPoint"
ExecStop=/bin/umount $MountPoint

[Install]
WantedBy=sysinit.target
-->8---

So how do we create a new encfs unit now?

- mkdir /etc/encfs/
- echo -e "RootDir=/home/.encfs/crypt/\nMountPoint=/home/crypt" >
/etc/encfs/home
- systemctl enable unlock@home.service
Note how the file name and the instance name match.


Maybe you could use BindsTo=/etc/encfs/%I.path (I think that would 
work, right?) so that you do not have to explicitly enable it. Although 
that would cause the MTPT to be unmounted if the file is deleted 
(unless the ExecStop= is removed)... Anyway, pretty cool.


Thanks for sharing,
--
Cameron Norman

Re: unlocking encfs during boot (Re: systemd now appears to be only possible init system in testing)

[Michael Biebl]

Am 28.07.2014 16:53, schrieb Michael Biebl:
> --8<---
> [Unit]
> Description=Unlock EncFS
> DefaultDependencies=no
> After=local-fs.target
> Before=display-manager.service getty@tty1.service
> 
> [Service]
> Type=oneshot
> RemainAfterExit=true
> Environment=RootDir=/home/.encfs/crypt
> Environment=MountPoint=/home/crypt
> ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 'Unlock
> EncFS' | encfs --stdinpass $RootDir $MountPoint"
> ExecStop=/bin/umount $MountPoint
> 
> [Install]
> WantedBy=sysinit.target
> -->8---


To show you some additional cool systemd features, I'm going a step
further and make this unit file a completely generic template unit, so
it can easily be re-used, say if you have multiple encfs file systems to
unlock and you don't want to copy that file over and over again.

Only 3 small modifications are necessary:
- Rename the file unlock@.service
- Update Description: Description=Unlock %I EncFS
- Use EnvironmentFile=/etc/encfs/%I

The %I is the instance name specfier and denotes the part between
unlock@.service. See man systemd.unit(5)

The resulting template unit looks like this and is completely generic:

--8<---
[Unit]
Description=Unlock %I EncFS
DefaultDependencies=no
After=local-fs.target
Before=display-manager.service getty@tty1.service

[Service]
Type=oneshot
RemainAfterExit=true
EnvironmentFile=/etc/encfs/%I
ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 'Unlock
EncFS' | encfs --stdinpass $RootDir $MountPoint"
ExecStop=/bin/umount $MountPoint

[Install]
WantedBy=sysinit.target
-->8---

So how do we create a new encfs unit now?

- mkdir /etc/encfs/
- echo -e "RootDir=/home/.encfs/crypt/\nMountPoint=/home/crypt" >
/etc/encfs/home
- systemctl enable unlock@home.service
Note how the file name and the instance name match.


Hope you enjoy my little explorations in systemd land :-)

Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: unlocking encfs during boot (Re: systemd now appears to be only possible init system in testing)

[Michael Biebl]

Hi,

Am 28.07.2014 01:54, schrieb Christian Hofstaedtler:
> * Michael Biebl  [140727 23:09]:
>> Am 22.07.2014 23:54, schrieb Julian Gilbey:
>>> For me, this is a killer, as I still do not know how to solve the
>>> problem I asked a while back on debian-user
>>> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
>>> summary, I need to unlock an encrypted filesystem during boot time by
>>> asking for a password to feed into encfs.  But I cannot figure out how
>>> to do this under systemd.
>>>
>>> Answers to this question would also be much appreciated!
>>
>> Julian, do you still need help with that?
>> I've just cobbled together a short unlock.service file which seems to
>> work reasonable fine and which I can share with you.
> 
> I'd love to see that file.

Here we go:

--8<---
[Unit]
Description=Unlock EncFS
DefaultDependencies=no
After=local-fs.target
Before=display-manager.service getty@tty1.service

[Service]
Type=oneshot
RemainAfterExit=true
Environment=RootDir=/home/.encfs/crypt
Environment=MountPoint=/home/crypt
ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 'Unlock
EncFS' | encfs --stdinpass $RootDir $MountPoint"
ExecStop=/bin/umount $MountPoint

[Install]
WantedBy=sysinit.target
-->8---

(The ExecStart= needs to be a single line, I hope it's not messed up by
my mailer)

I've installed that as /etc/systemd/system/unlock.service, then ran
"systemctl enable unlock.service"

A few remarks:

- I hook that service up in sysinit.target, which is similar to rcS in
sysvinit since that is what Julian was using in his original SysV init
script
Services which run that early should usually use DefaultDependencies=no
and specificy their requirements explicitly (that's what the
After=local-fs.target is for)

- I used Type=oneshot, as I'm only interested in the unlock process and
not in tracking the encfs process.

- The usage of Environment= is entirely optional, but makes it a bit
more readable

- The ExecStop= is not strictly required, but simply a nice touch.

- Querying input on a non sequential system (like systemd) is not
trivial. I therefore recommend the usage of plymouth. Don't consider it
as only a shiny bootsplash, but rather an I/O multi-plexer [1]. If you
insist on not using plymouth, make at least sure, to booth with "quiet"
enabled, otherwise your unlock prompt will be overwritten by the boot
messages.
Let me repeat: for such case, I really recommend to use plymouth!

- The Before=display-manager.service getty@tty1.service line makes sure,
your plymouth (or console) prompt is not interfered by the getty on tty1
or X/your display manager.
Not all display managers already setup the display-manager.service
symlink properly (gdm3 in unstable and lightdm, do).
So you might need to change that to list the actual service name say you
use xdm:
Before=xdm.service ...


systemd-ask-password is clever enough to automatically use plymouth when
available or falls back to the tty agent otherwise.


If you have further questions, just ask.


Cheers,
Michael

[1] http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/
(currently not reachable, you might use the google cache)

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Charles Plessy]

Le Mon, Jul 28, 2014 at 10:32:00AM +, Thorsten Glaser a écrit :
> 
> There are lots of duckduckgo results for "systemd
> screen session" where people describe systemd killing their
> GNU screen sessions, changing config files to avoid it,
> only for the next systemd upgrade to kill their GNU screen
> sessions again.

Really ?  At least not that much in the top of the list.

curl 'https://duckduckgo.com/html/?q=systemd%20screen%20session' | lynx --stdin 
--dump

[…]

   [6]archlinux wiki systemd/User - ArchWiki
   systemd offers users the ability to run an instance of systemd to
   manage their session and services. This allows users to start, stop,
   enable, and disable units found within certain directories when systemd
   is run by the user.
   wiki.archlinux.org/index.php/Systemd/User

Not a problem

   [7]How To Use Linux Screen - Server Management Services
   Linux Screen allows you to: Use multiple shell windows from a single
   SSH session. Keep a shell active even through network disruptions.
   Disconnect and re-connect to a shell sessions from multiple locations.
   rackaid.com/blog/linux-screen-tutorial-and-how-to/

Nothing to do with systemd

   [8][systemd-devel] [beagleboard] Systemd blowing away screen ...
   Adding the systemd list. I had this working a few systemd releases ago,
   but I now get the same behaviour as you are seeing. Op 22 mrt. 2012, om
   08:32 heeft Ken Restivo het volgende geschreven: > Systemd wipes out
   screen sessions, thus making screen unusable.
   lists.freedesktop.org/archives/systemd-devel/2012-March/004774

Sent in 2012

   [9]GNU Screen - ArchWiki - Arch Linux
   $ screen -x session_name Autostart with systemd. This service
   autostarts screen for the specified user (e.g. systemctl enable
   screen@florian). ... To send a command to the inner screen session, use
   ctrl+a a, followed by your command. For example:
   wiki.archlinux.org/index.php/GNU_Screen

Not a problem

   [10]screen - systemd service that needs .ssh/id_dsa password ...
   I have a systemctl service that starts a process smd-loop in a screen
   session. This process requires acces to remote SSH sources (for syncing
   purposes) and thus needs to be able to access my id_dsa private key.
   unix.stackexchange.com/questions/53044/systemd-service-that-need...

Not related to your problem

   [11][SOLVED] Console font ignored after switching to systemd ...
   Newbie Corner ... "Kebertx Member Registered: 2012-01-02 Posts: 69
   [SOLVED] Console font ignored after ..." · "jasonwryan Administrator
   From: .nz Registered: 2009-05-09 Posts: 11,656 Website Re: [SOLVED]
   Console font ignored after switching to systemd Try it without the
   quotes, as per the man ...
   bbs.archlinux.org/viewtopic.php?id=151233

Not related to your problem

   [12]rTorrent+Screen doesn't start properly from systemd ...
   I think that the user session works just like the system session. So
   when it starts systemd --user, it will just start whatever it deems the
   default.target.
   linuxine.com/story/rtorrentscreen-doesnt-start-properl...

Not related to your problem

   [13]Using screen for remote interaction | Linux.com
   Basically, screen allows you to create virtual terminals which are not
   connected to your actual xterms or console screens. You can then
   disconnect from a screen session and reconnect from somewhere else
   while preserving your shell or other running processes.
   linux.com/learn/tutorials/442418-using-screen-for-r...
 
Nothing to do with systemd

  [14]STOP:c21a(Fatal System Error) The Session Manager ...
   original title: STOP:c21a(Fatal System Error) The Session Manager
   Initialization system process terminated unexpectedly with a status of
   0xc26c (0x 0x) The system has been shut ... the
   first non-bsod start of windows hanged on a please wait screen.
   answers.microsoft.com/en-us/windows/forum/windows_xp-system/sto...

Not likely to use systemd in the near future

   [15]GNU Screen - Wikipedia, the free encyclopedia
   GNU Screen is a software application that can be used to multiplex
   several virtual consoles, allowing a user to access multiple separate
   terminal sessions inside a single terminal window or remote terminal
   session.
   en.wikipedia.org/wiki/GNU_Screen

Not related to your problem

   [16]How to send a command to a screen session? - LinuxQuestions.org
   Thx for the answer. I tried to make a system() call to a screen -x
   sessionname redirecting the output to /dev/null, but it didn't work. I
   found out that I could send the screen -x sessionname command to
   another (temporarily) screen session, but that didn't work neither (see
   below).
   linuxquestions.org/questions/linux-software-2/how-to-send-a-...
   [17]Screen User's Manual - GNU
   1 Overview. Screen is a full-screen window manager that multiplexes a
   physical terminal between several processes, typically interactive
   shells.

Not related to your pr

Re: systemd now appears to be only possible init system in testing

[Ansgar Burchardt]

Hi,

On 07/28/2014 12:32, Thorsten Glaser wrote:
> Vincent Lefevre wrote:
>> Screen sessions, SSH sessions and computation processes running in
>> background are lost after a reboot, not after a relogin.
> 
> AIUI this is not true for systemd: once the "session" is
> terminated, all background processes run in it are killed
> too.

No, systemd doesn't kill any background processes (though one can change
the configuration to do so if desired).

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d62b0b.6020...@debian.org

Re: systemd now appears to be only possible init system in testing

[Thorsten Glaser]

Vincent Lefevre wrote:

>Screen sessions, SSH sessions and computation processes running in
>background are lost after a reboot, not after a relogin.

AIUI this is not true for systemd: once the "session" is
terminated, all background processes run in it are killed
too. There are lots of duckduckgo results for "systemd
screen session" where people describe systemd killing their
GNU screen sessions, changing config files to avoid it,
only for the next systemd upgrade to kill their GNU screen
sessions again.

But if this is fixed/solved in Debian, do tell. (And if it
is not, I consider it a catastrophic failure.)

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lr58r0$67f$2...@ger.gmane.org

Re: unlocking encfs during boot (Re: systemd now appears to be only possible init system in testing)

[Christian Hofstaedtler]

* Michael Biebl  [140727 23:09]:
> Am 22.07.2014 23:54, schrieb Julian Gilbey:
> > For me, this is a killer, as I still do not know how to solve the
> > problem I asked a while back on debian-user
> > (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> > summary, I need to unlock an encrypted filesystem during boot time by
> > asking for a password to feed into encfs.  But I cannot figure out how
> > to do this under systemd.
> > 
> > Answers to this question would also be much appreciated!
> 
> Julian, do you still need help with that?
> I've just cobbled together a short unlock.service file which seems to
> work reasonable fine and which I can share with you.

I'd love to see that file.

  C.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140727235453.ga5...@sx.home.zeha.at

unlocking encfs during boot (Re: systemd now appears to be only possible init system in testing)

[Michael Biebl]

Am 22.07.2014 23:54, schrieb Julian Gilbey:
> For me, this is a killer, as I still do not know how to solve the
> problem I asked a while back on debian-user
> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.
> 
> Answers to this question would also be much appreciated!

Julian, do you still need help with that?
I've just cobbled together a short unlock.service file which seems to
work reasonable fine and which I can share with you.

We can further discuss this on pkg-systemd-maintainers if you want.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Marco d'Itri]

On Jul 26, Russ Allbery  wrote:

> Not mentioned there is another problem, namely that LSB mandates
> particular exit codes for particular conditions in init scripts, and set
> -e will not produce the correct exit codes.
What a great argument in favour of systemd... :-)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Josselin Mouette]

Le mercredi 23 juillet 2014 à 16:12 -0700, Russ Allbery a écrit : 
> Someone with more detailed desktop knowledge should read this over and
> correct it as necessary.  This is just my understanding of what's going
> on, and I don't work with the software in question and could be wrong in
> some details.

This is overall accurate except for:

> However, PolicyKit has basically been orphaned upstream, replaced by the
> rewritten polkit, and I believe polkit depends on logind to provide core
> functionality around knowing what users are on console.  

polkit = PolicyKit
It’s just that PolicyKit used to rely on ConsoleKit to obtain the
information about who is logged on the system. Now that ConsoleKit is
orphaned, the only available information is provided by systemd-logind.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1406388024.2376.4.camel@tomoyo

Re: systemd now appears to be only possible init system in testing

[Vincent Bernat]

 ❦ 25 juillet 2014 16:19 -0700, Russ Allbery  :

>> I thought that start-stop-daemon (and status_of_proc) returned the
>> correct codes, and whatever it returns you can relay / let the shell
>> catch? The script is here
>> (https://github.com/cgmanager/cgmanager/pull/14/files), if you wanted to
>> take a look.
>
> It does not, at least not the way that you're calling it.
>
> If you used --oknodo in a few places, it might be closer, but take a look
> at /etc/init.d/skeleton and look at the exit status remapping that it
> does.

Some time ago, /etc/init.d/skeleton has been modified to make use of
init-d-script.
-- 
printk("Entering UltraSMPenguin Mode...\n");
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c


signature.asc
Description: PGP signature

Re: systemd now appears to be only possible init system in testing

[Serge Hallyn]

Quoting Russ Allbery (r...@debian.org):
> Cameron Norman  writes:
> 
> > Oh this is easy. The init script calls s-s-d and does not check the return
> > code (so always exits 0). I am just going to use set -e in the init
> > script, only a couple tweaks are needed.
> 
> Please don't use set -e in init scripts.  See Policy 9.3.2:
> 
> Be careful of using set -e in init.d scripts.  Writing correct init.d
> scripts requires accepting various error exit statuses when daemons
> are already running or already stopped without aborting the init.d
> script, and common init.d function libraries are not safe to call with
> set -e in effect.  For init.d scripts, it's often easier to not use
> set -e and instead check the result of each command separately.
> 
> Not mentioned there is another problem, namely that LSB mandates
> particular exit codes for particular conditions in init scripts, and set
> -e will not produce the correct exit codes.

No worries, I've gone a different route - borrowing heavily (and
appreciatively) from the libvirt init scripts.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725233710.GS31507@ubuntumail

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-25 23:04:55 +0200, Michael Biebl wrote:
> Am 25.07.2014 22:43, schrieb Vincent Lefevre:
> > On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
> >> And we already concluded that you need to logout anyway, even with
> >> systemd-shim. A reboot and relogin isn't that much different from a
> >> users POV.
> > 
> > Screen sessions, SSH sessions and computation processes running in
> > background are lost after a reboot, not after a relogin.
> 
> You are doing a dist-upgrade while there are running computation
> processes? That sounds like a recipe for disaster.

I have a Debian/unstable desktop machine that permanently runs
computation processes, so yes. However I don't really mind if
they are aborted. I'm more annoyed when losing my screen and SSH
sessions (to the machine). Now, if this happens only once every
few months, that's OK.

What I really meant is that a reboot is quite different from a
relogin: I log out / in again quite often, and if I need a more
permanent session, I use screen.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725232526.ga5...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Cameron Norman  writes:

> I thought that start-stop-daemon (and status_of_proc) returned the
> correct codes, and whatever it returns you can relay / let the shell
> catch? The script is here
> (https://github.com/cgmanager/cgmanager/pull/14/files), if you wanted to
> take a look.

It does not, at least not the way that you're calling it.

If you used --oknodo in a few places, it might be closer, but take a look
at /etc/init.d/skeleton and look at the exit status remapping that it
does.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx65hvrd@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 19:23, schrieb Steve Langasek:
> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> cgmanager, implementing the new post-v205 interfaces.  libpam-systemd now
> needs to be updated to depend again on systemd-shim (>= 6-4) | systemd-sysv.
> 
> Michael Biebl has said on IRC that he will take care of this in the next
> upload of systemd.

Just a quick followup: After testing cgmanager a bit I stumbled over
various issues which should be fixed first before I'm going to re-add
the alternative dependency. I started filing bugs for them.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Fri, 25 de Jul 2014 a las 3:42 PM, Russ Allbery  
escribió:

Cameron Norman  writes:

 Oh this is easy. The init script calls s-s-d and does not check the 
return

 code (so always exits 0). I am just going to use set -e in the init
 script, only a couple tweaks are needed.


Please don't use set -e in init scripts.  See Policy 9.3.2:

Be careful of using set -e in init.d scripts.  Writing correct 
init.d
scripts requires accepting various error exit statuses when 
daemons

are already running or already stopped without aborting the init.d
script, and common init.d function libraries are not safe to call 
with
set -e in effect.  For init.d scripts, it's often easier to not 
use

set -e and instead check the result of each command separately.

Not mentioned there is another problem, namely that LSB mandates
particular exit codes for particular conditions in init scripts, and 
set

-e will not produce the correct exit codes.


I thought that start-stop-daemon (and status_of_proc) returned the 
correct codes, and whatever it returns you can relay / let the shell 
catch? The script is here 
(https://github.com/cgmanager/cgmanager/pull/14/files), if you wanted 
to take a look.


Best,
--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Steve Langasek  writes:
> On Fri, Jul 25, 2014 at 11:44:43PM +0200, Michael Biebl wrote:

>> Ah perfect. Seems this just hasn't hit the archive yet when I installed
>> cgmanager.

>> Steve, could you please bump the depends on cgmanager in systemd-shim
>> accordingly to ensure a working cgmanager is installed?

> No, I'm not going to reupload the package to declare an incompatibility with
> a version of a dependency that was in unstable less than a day before
> getting fixed.

I concur -- not every bug is worth tightening dependencies.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a97xjbz9@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Cameron Norman  writes:

> Oh this is easy. The init script calls s-s-d and does not check the return
> code (so always exits 0). I am just going to use set -e in the init
> script, only a couple tweaks are needed.

Please don't use set -e in init scripts.  See Policy 9.3.2:

Be careful of using set -e in init.d scripts.  Writing correct init.d
scripts requires accepting various error exit statuses when daemons
are already running or already stopped without aborting the init.d
script, and common init.d function libraries are not safe to call with
set -e in effect.  For init.d scripts, it's often easier to not use
set -e and instead check the result of each command separately.

Not mentioned there is another problem, namely that LSB mandates
particular exit codes for particular conditions in init scripts, and set
-e will not produce the correct exit codes.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87egx9jc0h@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 11:44:43PM +0200, Michael Biebl wrote:
> Ah perfect. Seems this just hasn't hit the archive yet when I installed
> cgmanager.

> Steve, could you please bump the depends on cgmanager in systemd-shim
> accordingly to ensure a working cgmanager is installed?

No, I'm not going to reupload the package to declare an incompatibility with
a version of a dependency that was in unstable less than a day before
getting fixed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725221426.gd31...@virgil.dodds.net

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Fri, 25 de Jul 2014 a las 2:50 PM, Steve Langasek 
 escribió:

On Fri, Jul 25, 2014 at 11:10:41PM +0200, Michael Biebl wrote:

 Am 25.07.2014 19:23, schrieb Steve Langasek:
 > systemd-shim 6-4 has now been uploaded to unstable with a 
dependency on
 > cgmanager, implementing the new post-v205 interfaces. 



 I just installed systemd-shim 6-4 and cgmanager 0.28-1.
 Unfortunately the cgmanager package seems to be not quite ready yet.



 The init script fails with



 # service cgmanager start
 [] Starting cgroup management daemon: cgmanagercgmanager: Failed
 mounting memory onto /run/cgmanager/fs/memory: No such file or 
directory

 cgmanager: Failed mounting cgroups
 cgmanager: Failed to set up cgroup mounts
 . ok



 on a default jessie kernel.


I believe this is bug #755990, already fixed by Serge in 0.28-2.


 Interestingly, the return code of the init script was 0.


Hmm, dunno about that.  Serge?


Oh this is easy. The init script calls s-s-d and does not check the 
return code (so always exits 0). I am just going to use set -e in the 
init script, only a couple tweaks are needed. I will get a merge 
request to the github repo in about 15 minutes.


Cheers,
--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Serge Hallyn]

Quoting Michael Biebl (bi...@debian.org):
> Hi Serge!
> 
> Am 25.07.2014 23:35, schrieb Serge Hallyn:
> > Quoting Michael Biebl (bi...@debian.org):
> >> Am 25.07.2014 19:23, schrieb Steve Langasek:
> >>> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> >>> cgmanager, implementing the new post-v205 interfaces. 
> >>
> >> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
> >> Unfortunately the cgmanager package seems to be not quite ready yet.
> >>
> >> The init script fails with
> >>
> >> # service cgmanager start
> >> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> >> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> >> cgmanager: Failed mounting cgroups
> >> cgmanager: Failed to set up cgroup mounts
> >> . ok
> > 
> > That was an upstream bug, should be fixed in 0.28-2.  The default of
> > having memory show up in /proc/cgroups but not be mountable was being
> > mishandled.
> 
> Ah perfect. Seems this just hasn't hit the archive yet when I installed
> cgmanager.
> 
> Steve, could you please bump the depends on cgmanager in systemd-shim
> accordingly to ensure a working cgmanager is installed?
> 
> > There was also mention of having a systemd unit linked to /dev/null to
> > not run cgmanager in systemd.  I assume that's what systemd itself would
> > actually prefer and I'm fine with it, but for the sake of supporting
> > nested containers it would be nicer if we could have it actually run
> > (for now).
> 
> If cgmanager and systemd don't step on each others toes and there is
> value running cgmanager besides systemd, it might make sense to also run
> it under systemd.
> 
> My only concern would be, that most users probably don't need nested
> containers and if cgmanager is pulled in as a depends on systemd-shim,
> they'd have a useless daemon running.
> 
> What about shipping a native .service file for cgmanager, but not enable
> it by default, i.e. the admin would have to run
> systemctl enable cgmanager.service
> if want's to run cgmanager under systemd.
> 
> That means, under sysvinit the service would be running by default and
> under systemd it would have to be enabled explicitly.
> 
> Would that work for you?

Sure - I don't know offhand how this would be done, but I'll look into it.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725221022.GO31507@ubuntumail

Re: systemd now appears to be only possible init system in testing

[Serge Hallyn]

Quoting Michael Biebl (bi...@debian.org):
> 
> Am 25.07.2014 23:35, schrieb Serge Hallyn:
> > Quoting Michael Biebl (bi...@debian.org):
> >>
> >> The init script fails with
> >>
> >> # service cgmanager start
> >> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> >> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> >> cgmanager: Failed mounting cgroups
> >> cgmanager: Failed to set up cgroup mounts
> >> . ok
> > 
> > 
> >> on a default jessie kernel.
> >>
> >> Interestingly, the return code of the init script was 0.
> 
> Could you please also look into this.
> 
> The init script shouldn't have an exit code of 0 if the daemon failed to
> start.
> 
> Thanks!

D'oh, yup, that's a real bug in the (upstream) sysvinit job.  Thanks.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725220636.GN31507@ubuntumail

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 11:10:41PM +0200, Michael Biebl wrote:
> Am 25.07.2014 19:23, schrieb Steve Langasek:
> > systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> > cgmanager, implementing the new post-v205 interfaces. 

> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
> Unfortunately the cgmanager package seems to be not quite ready yet.

> The init script fails with

> # service cgmanager start
> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> cgmanager: Failed mounting cgroups
> cgmanager: Failed to set up cgroup mounts
> . ok

> on a default jessie kernel.

I believe this is bug #755990, already fixed by Serge in 0.28-2.

> Interestingly, the return code of the init script was 0.

Hmm, dunno about that.  Serge?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 23:35, schrieb Serge Hallyn:
> Quoting Michael Biebl (bi...@debian.org):
>>
>> The init script fails with
>>
>> # service cgmanager start
>> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
>> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
>> cgmanager: Failed mounting cgroups
>> cgmanager: Failed to set up cgroup mounts
>> . ok
> 
> 
>> on a default jessie kernel.
>>
>> Interestingly, the return code of the init script was 0.

Could you please also look into this.

The init script shouldn't have an exit code of 0 if the daemon failed to
start.

Thanks!


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Hi Serge!

Am 25.07.2014 23:35, schrieb Serge Hallyn:
> Quoting Michael Biebl (bi...@debian.org):
>> Am 25.07.2014 19:23, schrieb Steve Langasek:
>>> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
>>> cgmanager, implementing the new post-v205 interfaces. 
>>
>> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
>> Unfortunately the cgmanager package seems to be not quite ready yet.
>>
>> The init script fails with
>>
>> # service cgmanager start
>> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
>> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
>> cgmanager: Failed mounting cgroups
>> cgmanager: Failed to set up cgroup mounts
>> . ok
> 
> That was an upstream bug, should be fixed in 0.28-2.  The default of
> having memory show up in /proc/cgroups but not be mountable was being
> mishandled.

Ah perfect. Seems this just hasn't hit the archive yet when I installed
cgmanager.

Steve, could you please bump the depends on cgmanager in systemd-shim
accordingly to ensure a working cgmanager is installed?

> There was also mention of having a systemd unit linked to /dev/null to
> not run cgmanager in systemd.  I assume that's what systemd itself would
> actually prefer and I'm fine with it, but for the sake of supporting
> nested containers it would be nicer if we could have it actually run
> (for now).

If cgmanager and systemd don't step on each others toes and there is
value running cgmanager besides systemd, it might make sense to also run
it under systemd.

My only concern would be, that most users probably don't need nested
containers and if cgmanager is pulled in as a depends on systemd-shim,
they'd have a useless daemon running.

What about shipping a native .service file for cgmanager, but not enable
it by default, i.e. the admin would have to run
systemctl enable cgmanager.service
if want's to run cgmanager under systemd.

That means, under sysvinit the service would be running by default and
under systemd it would have to be enabled explicitly.

Would that work for you?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 10:46:45PM +0200, Michael Biebl wrote:
> Am 25.07.2014 20:44, schrieb Steve Langasek:
> > Correct.  But it's well-established that, when you upgrade your system,
> > things may be broken in a currently logged-in desktop session until you
> > log out and log back in.

> The release notes actually mention that the system should *not* be
> upgraded from within an X session

That is a bug in the release notes, dating back to the days when X itself
was unreliable enough that you couldn't be confident that it wouldn't bomb
out leaving dpkg in an unclean state.

Nowadays it is reliable, and a desktop user should never need to see a Linux
console, including during upgrades.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Serge Hallyn]

Quoting Michael Biebl (bi...@debian.org):
> Am 25.07.2014 19:23, schrieb Steve Langasek:
> > systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> > cgmanager, implementing the new post-v205 interfaces. 
> 
> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
> Unfortunately the cgmanager package seems to be not quite ready yet.
> 
> The init script fails with
> 
> # service cgmanager start
> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> cgmanager: Failed mounting cgroups
> cgmanager: Failed to set up cgroup mounts
> . ok

That was an upstream bug, should be fixed in 0.28-2.  The default of
having memory show up in /proc/cgroups but not be mountable was being
mishandled.

There was also mention of having a systemd unit linked to /dev/null to
not run cgmanager in systemd.  I assume that's what systemd itself would
actually prefer and I'm fine with it, but for the sake of supporting
nested containers it would be nicer if we could have it actually run
(for now).

> on a default jessie kernel.
> 
> Interestingly, the return code of the init script was 0.
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725213503.GL31507@ubuntumail

Re: systemd now appears to be only possible init system in testing

[Adam D. Barratt]

On Fri, 2014-07-25 at 23:10 +0200, Michael Biebl wrote:
> I just installed systemd-shim 6-4 and cgmanager 0.28-1.
> Unfortunately the cgmanager package seems to be not quite ready yet.
> 
> The init script fails with
> 
> # service cgmanager start
> [] Starting cgroup management daemon: cgmanagercgmanager: Failed
> mounting memory onto /run/cgmanager/fs/memory: No such file or directory
> cgmanager: Failed mounting cgroups
> cgmanager: Failed to set up cgroup mounts
> . ok

That's #755990, which was fixed a couple of hours ago.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1406323916.16854.3.ca...@jacala.jungle.funky-badger.org

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 19:23, schrieb Steve Langasek:
> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> cgmanager, implementing the new post-v205 interfaces. 

I just installed systemd-shim 6-4 and cgmanager 0.28-1.
Unfortunately the cgmanager package seems to be not quite ready yet.

The init script fails with

# service cgmanager start
[] Starting cgroup management daemon: cgmanagercgmanager: Failed
mounting memory onto /run/cgmanager/fs/memory: No such file or directory
cgmanager: Failed mounting cgroups
cgmanager: Failed to set up cgroup mounts
. ok

on a default jessie kernel.

Interestingly, the return code of the init script was 0.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 22:43, schrieb Vincent Lefevre:
> On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
>> And we already concluded that you need to logout anyway, even with
>> systemd-shim. A reboot and relogin isn't that much different from a
>> users POV.
> 
> Screen sessions, SSH sessions and computation processes running in
> background are lost after a reboot, not after a relogin.

You are doing a dist-upgrade while there are running computation
processes? That sounds like a recipe for disaster.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 20:44, schrieb Steve Langasek:
> Correct.  But it's well-established that, when you upgrade your system,
> things may be broken in a currently logged-in desktop session until you
> log out and log back in.

The release notes actually mention that the system should *not* be
upgraded from within an X session [1] which renders the point about
broken reboot buttons kinda moot.

The release notes also clearly say, that the system should be rebooted
after a dist-upgrade.



[1]
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgrade-preparations
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-25 22:18:23 +0200, Michael Biebl wrote:
> And we already concluded that you need to logout anyway, even with
> systemd-shim. A reboot and relogin isn't that much different from a
> users POV.

Screen sessions, SSH sessions and computation processes running in
background are lost after a reboot, not after a relogin.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725204345.ga15...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 10:00:07PM +0200, Michael Biebl wrote:
> Am 25.07.2014 21:20, schrieb Steve Langasek:
> > I can't imagine how anyone can simultaneously hold the view that Debian
> > should use systemd for improved integration with end-user-targeted desktop
> > environments, and believe that Debian should leave these end users grubbing
> > around on the console to do something as fundamental as rebooting their
> > system after upgrade.

> You can always reboot from your display manager.
> All the major ones in Debian support that.

> So no, that's simply incorrect: users don't need to switch to the
> console to reboot their system after a dist-upgrade.

If that's so, then I stand corrected.  I assumed this would fail from the DM
as well as from the desktop.

AIUI other functions, such as suspending the laptop, still fail with
systemd alone until you reboot.  And we do have the means to address this
now.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 12:50:53PM -0700, Russ Allbery wrote:
> Steve Langasek  writes:

> > I can't imagine how anyone can simultaneously hold the view that Debian
> > should use systemd for improved integration with end-user-targeted
> > desktop environments, and believe that Debian should leave these end
> > users grubbing around on the console to do something as fundamental as
> > rebooting their system after upgrade.

> This confuses me, however.  Surely the difference between a one-time
> disruption and ongoing pain is too obvious to need stating?

consolekit was never an ongoing pain for the end users, it was ongoing pain
for the developers and maintainers.  Shunting the pain from the maintainers
to the users is always a bug.  Not always a fixable bug, but nevertheless
not something we should be sanguine about.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 22:00, schrieb Michael Biebl:
> Am 25.07.2014 21:20, schrieb Steve Langasek:
>> I can't imagine how anyone can simultaneously hold the view that Debian
>> should use systemd for improved integration with end-user-targeted desktop
>> environments, and believe that Debian should leave these end users grubbing
>> around on the console to do something as fundamental as rebooting their
>> system after upgrade.
> 
> You can always reboot from your display manager.

And we already concluded that you need to logout anyway, even with
systemd-shim. A reboot and relogin isn't that much different from a
users POV.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 21:20, schrieb Steve Langasek:
> I can't imagine how anyone can simultaneously hold the view that Debian
> should use systemd for improved integration with end-user-targeted desktop
> environments, and believe that Debian should leave these end users grubbing
> around on the console to do something as fundamental as rebooting their
> system after upgrade.

You can always reboot from your display manager.
All the major ones in Debian support that.

So no, that's simply incorrect: users don't need to switch to the
console to reboot their system after a dist-upgrade.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Steve Langasek  writes:
> On Fri, Jul 25, 2014 at 11:42:16AM -0700, Russ Allbery wrote:

>> I continue to be baffled by people's apparent belief that this
>> happening during a major upgrade is some sort of regression.  Having
>> those buttons not work after a major component upgrade, until the X
>> session was restarted, has been typical behavior for as long as I've
>> been using Debian with a desktop environment.

> The distinction is between having to restart your *session* and having
> to restart your *system*.  The systemd/logind issue introduces a
> requirement for the latter, which /is/ a regression.

Yeah, I just figured that out.  I agree that's a regression.

> I can't imagine how anyone can simultaneously hold the view that Debian
> should use systemd for improved integration with end-user-targeted
> desktop environments, and believe that Debian should leave these end
> users grubbing around on the console to do something as fundamental as
> rebooting their system after upgrade.

This confuses me, however.  Surely the difference between a one-time
disruption and ongoing pain is too obvious to need stating?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87silpkyjm@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Steve Langasek  writes:

> The difference here is that, without systemd-shim, logging out and
> logging back in still does not give the user a working session, you
> would have to completely reboot instead.  I think this is an important
> difference in the quality of the upgrade experience.

Ah, *that's* what you're getting at.  Yes, while we can argue about
severity, I agree that's a regression from the previous state of things.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wqb1kyt8@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 11:42:16AM -0700, Russ Allbery wrote:
> Steve Langasek  writes:

> > For the specific case of a change that makes basic desktop functions
> > unusable between upgrade and reboot (including the "reboot" button
> > itself), the right answer is "until it's ready, and if you want it
> > sooner then help."

> I continue to be baffled by people's apparent belief that this happening
> during a major upgrade is some sort of regression.  Having those buttons
> not work after a major component upgrade, until the X session was
> restarted, has been typical behavior for as long as I've been using Debian
> with a desktop environment.

The distinction is between having to restart your *session* and having to
restart your *system*.  The systemd/logind issue introduces a requirement
for the latter, which /is/ a regression.

I can't imagine how anyone can simultaneously hold the view that Debian
should use systemd for improved integration with end-user-targeted desktop
environments, and believe that Debian should leave these end users grubbing
around on the console to do something as fundamental as rebooting their
system after upgrade.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 08:19:14PM +0200, Michael Biebl wrote:
> Am 25.07.2014 19:23, schrieb Steve Langasek:
> > On Fri, Jul 25, 2014 at 06:56:06PM +0200, Tollef Fog Heen wrote:
> >> ]] Martin Steigerwald 

> >>> Sure I can go through setting up chroot for that, yet I really think if 
> >>> my 
> >>> work requires changes in other packages and the recent systemd changes do 
> >>> require this kind of work, I *help* with these changes, instead of 
> >>> uploading 
> >>> my changes to unstable *before* the other packages have been fixed.

> >> How long are do you think is reasonable to wait then?

> > For the specific case of a change that makes basic desktop functions
> > unusable between upgrade and reboot (including the "reboot" button itself),

> Well, systemd-shim doesn't solve that problem either.
> The policykit package in wheezy uses ConsoleKit as backend.
> So if you're logged into your wheezy desktop, you only have a CK session
> registered. Installing systemd-shim doesn't magically register an active
> logind session.

Correct.  But it's well-established that, when you upgrade your system,
things may be broken in a currently logged-in desktop session until you
log out and log back in.

The difference here is that, without systemd-shim, logging out and logging
back in still does not give the user a working session, you would have to
completely reboot instead.  I think this is an important difference in the
quality of the upgrade experience.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Russ Allbery]

Steve Langasek  writes:

> For the specific case of a change that makes basic desktop functions
> unusable between upgrade and reboot (including the "reboot" button
> itself), the right answer is "until it's ready, and if you want it
> sooner then help."

I continue to be baffled by people's apparent belief that this happening
during a major upgrade is some sort of regression.  Having those buttons
not work after a major component upgrade, until the X session was
restarted, has been typical behavior for as long as I've been using Debian
with a desktop environment.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877g31mgaf@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Michael Biebl]

Am 25.07.2014 19:23, schrieb Steve Langasek:
> On Fri, Jul 25, 2014 at 06:56:06PM +0200, Tollef Fog Heen wrote:
>> ]] Martin Steigerwald 
> 
>>> Sure I can go through setting up chroot for that, yet I really think if my 
>>> work requires changes in other packages and the recent systemd changes do 
>>> require this kind of work, I *help* with these changes, instead of 
>>> uploading 
>>> my changes to unstable *before* the other packages have been fixed.
> 
>> How long are do you think is reasonable to wait then?
> 
> For the specific case of a change that makes basic desktop functions
> unusable between upgrade and reboot (including the "reboot" button itself),

Well, systemd-shim doesn't solve that problem either.
The policykit package in wheezy uses ConsoleKit as backend.
So if you're logged into your wheezy desktop, you only have a CK session
registered. Installing systemd-shim doesn't magically register an active
logind session.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Martin Steigerwald]

Am Freitag, 25. Juli 2014, 10:23:02 schrieb Steve Langasek:
> On Fri, Jul 25, 2014 at 06:56:06PM +0200, Tollef Fog Heen wrote:
> > ]] Martin Steigerwald
> > 
> > > Sure I can go through setting up chroot for that, yet I really think if
> > > my
> > > work requires changes in other packages and the recent systemd changes
> > > do
> > > require this kind of work, I *help* with these changes, instead of
> > > uploading my changes to unstable *before* the other packages have been
> > > fixed.> 
> > How long are do you think is reasonable to wait then?
> 
> For the specific case of a change that makes basic desktop functions
> unusable between upgrade and reboot (including the "reboot" button itself),
> the right answer is "until it's ready, and if you want it sooner then help."

That is exactly the point I was trying to make.

> systemd-shim 6-4 has now been uploaded to unstable with a dependency on
> cgmanager, implementing the new post-v205 interfaces.  libpam-systemd now
> needs to be updated to depend again on systemd-shim (>= 6-4) | systemd-sysv.
> 
> Michael Biebl has said on IRC that he will take care of this in the next
> upload of systemd.

Thank you.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

signature.asc
Description: This is a digitally signed message part.

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Fri, Jul 25, 2014 at 06:56:06PM +0200, Tollef Fog Heen wrote:
> ]] Martin Steigerwald 

> > Sure I can go through setting up chroot for that, yet I really think if my 
> > work requires changes in other packages and the recent systemd changes do 
> > require this kind of work, I *help* with these changes, instead of 
> > uploading 
> > my changes to unstable *before* the other packages have been fixed.

> How long are do you think is reasonable to wait then?

For the specific case of a change that makes basic desktop functions
unusable between upgrade and reboot (including the "reboot" button itself),
the right answer is "until it's ready, and if you want it sooner then help."

systemd-shim 6-4 has now been uploaded to unstable with a dependency on
cgmanager, implementing the new post-v205 interfaces.  libpam-systemd now
needs to be updated to depend again on systemd-shim (>= 6-4) | systemd-sysv.

Michael Biebl has said on IRC that he will take care of this in the next
upload of systemd.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Tollef Fog Heen]

]] Martin Steigerwald 

> Sure I can go through setting up chroot for that, yet I really think if my 
> work requires changes in other packages and the recent systemd changes do 
> require this kind of work, I *help* with these changes, instead of uploading 
> my changes to unstable *before* the other packages have been fixed.

How long are do you think is reasonable to wait then?  Back in the big
discussion during the winter, I said we'd want to update around Easter
time.  That left four-ish months for those who wanted to have a logind
that would work without systemd as pid in.  We ended up updating in
early July, which means we're talking about six months or so of warning.

I think there are other people who have simply failed to act at anything
resembling a reasonable pace and that you are putting the blame in the
wrong place.

We want to make sure this actually works well for the people who use the
default init system, after all, and there's a freeze coming up.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m24my5nzrt@rahvafeir.err.no

Re: systemd now appears to be only possible init system in testing

[josh]

On Fri, Jul 25, 2014 at 04:00:31PM -0007, Cameron Norman wrote:
> El Fri, 25 de Jul 2014 a las 8:47 AM, Josh Triplett
>  escribió:
> >Martin Steigerwald wrote:
> >> Sure I can go through setting up chroot for that, yet I really
> >>think if my
> >> work requires changes in other packages and the recent systemd
> >>changes do require this kind of work, I *help* with these
> >>changes, instead of uploading my changes to unstable *before*
> >>the other packages have been fixed.
> >
> >One point of clarification: systemd does not require changes in
> >systemd-shim or cgmanager.  systemd runs just fine with no such
> >changes.
> >Those packages exist for people who for whatever reason don't want to
> >run systemd, and that's not something the systemd folks should be
> >expected to help with (any more than people who don't want to run
> >systemd would be expected to work on systemd).
> >
> >The systemd maintainers already held systemd 204 back in unstable for
> >months waiting for the alternative to become viable.
> >
> >It's not reasonable to expect every systemd upgrade in
> >unstable/testing
> >to wait for an alternative init system to keep up.  If it does
> >keep up,
> >great; there's no fundamental reason to *not* want that alternative to
> >work.  If it doesn't, oh well.
> 
> I agree, but would also add that other packages in Debian should at
> least try to keep support for other init systems by not depending on
> later logind's until systemd-shim is updated. It is clear (I think)
> that there are a number of reasons somebody would prefer to use an
> alternative init system (including a few unresolved bugs so far),
> and packages like GNOME or policykit should support more than just
> systemd-sysv.

That's another "best-effort" case: if those packages don't need features
of new logind or systemd, they certainly shouldn't gratuitously depend
on a newer version than they need.  But if they do, they should properly
express that dependency.

As for "a few unresolved bugs", that's also common in unstable, and I'm
sure they'll get fixed soon enough.  Which ones did you have in mind at
the moment?  Most of them have been fixed already.  The most significant
outstanding ones I know of are 753589 (which has a patch that needs
uploading), 618862 (keyscript support in crypttab), and 738965 (which is
*caused* by a Debian-specific patch).

Long-term, if a non-systemd init remains viable, people running it in
unstable and potentially in testing should likely get used to having to
put large swaths of their system on hold while waiting for updates.
That's a pretty common thing to need to do in unstable.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725163855.GA8713@cloud

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Fri, 25 de Jul 2014 a las 8:47 AM, Josh Triplett 
 escribió:

Martin Steigerwald wrote:
 Sure I can go through setting up chroot for that, yet I really 
think if my
 work requires changes in other packages and the recent systemd 
changes do require this kind of work, I *help* with these changes, 
instead of uploading my changes to unstable *before* the other 
packages have been fixed.


One point of clarification: systemd does not require changes in
systemd-shim or cgmanager.  systemd runs just fine with no such 
changes.

Those packages exist for people who for whatever reason don't want to
run systemd, and that's not something the systemd folks should be
expected to help with (any more than people who don't want to run
systemd would be expected to work on systemd).

The systemd maintainers already held systemd 204 back in unstable for
months waiting for the alternative to become viable.

It's not reasonable to expect every systemd upgrade in 
unstable/testing
to wait for an alternative init system to keep up.  If it does keep 
up,

great; there's no fundamental reason to *not* want that alternative to
work.  If it doesn't, oh well.


I agree, but would also add that other packages in Debian should at 
least try to keep support for other init systems by not depending on 
later logind's until systemd-shim is updated. It is clear (I think) 
that there are a number of reasons somebody would prefer to use an 
alternative init system (including a few unresolved bugs so far), and 
packages like GNOME or policykit should support more than just 
systemd-sysv.


--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Josh Triplett]

Martin Steigerwald wrote:
> Sure I can go through setting up chroot for that, yet I really think if my
> work requires changes in other packages and the recent systemd changes do
> require this kind of work, I *help* with these changes, instead of uploading
> my changes to unstable *before* the other packages have been fixed.

One point of clarification: systemd does not require changes in
systemd-shim or cgmanager.  systemd runs just fine with no such changes.
Those packages exist for people who for whatever reason don't want to
run systemd, and that's not something the systemd folks should be
expected to help with (any more than people who don't want to run
systemd would be expected to work on systemd).

The systemd maintainers already held systemd 204 back in unstable for
months waiting for the alternative to become viable.

It's not reasonable to expect every systemd upgrade in unstable/testing
to wait for an alternative init system to keep up.  If it does keep up,
great; there's no fundamental reason to *not* want that alternative to
work.  If it doesn't, oh well.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140725154741.GA2327@thin

Re: systemd now appears to be only possible init system in testing

[Vincent Bernat]

 ❦ 25 juillet 2014 14:22 +0200, Martin Steigerwald  :

> Re: Bug#755989: cfdisk: german help page strangely formatted
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755989#15
>
> (In addition to NFS mounts broken with systemd currently.)
>
>
> Sure I can go through setting up chroot for that, yet I really think if my 
> work requires changes in other packages and the recent systemd changes do 
> require this kind of work, I *help* with these changes, instead of uploading 
> my changes to unstable *before* the other packages have been fixed.

As a DD, you should always use a clean chroot to build everything. It's
not like it's something difficult to do. apt-get install cowbuilder ;
pbuilder create --distribution sid. schroot would be another option.
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: systemd now appears to be only possible init system in testing

[Martin Steigerwald]

Am Dienstag, 22. Juli 2014, 22:54:55 schrieb Julian Gilbey:
> For me, this is a killer, as I still do not know how to solve the
> problem I asked a while back on debian-user
> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.
> 
> Answers to this question would also be much appreciated!

I really hope systemd will soon be able to be co-installed with sysvinit-core 
again.

Here is another reason why:

Re: Bug#755989: cfdisk: german help page strangely formatted
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755989#15

(In addition to NFS mounts broken with systemd currently.)


Sure I can go through setting up chroot for that, yet I really think if my 
work requires changes in other packages and the recent systemd changes do 
require this kind of work, I *help* with these changes, instead of uploading 
my changes to unstable *before* the other packages have been fixed.

Especially if its such an disruptive change with all kind of side effects.

I only package some quite easy packages so far and I know its a lot of work to 
do good debian packaging, a lot more so with complex stuff like systemd. I know 
upload has been announced five month ago or so. But still…

I know I will hold back systemd until this is resolved. I am not yet going 
systemd only. By trust in systemd is not deep enough to do this on production 
systems. Yes, unstable is unstable, but… but putting in onto selected 
production systems for testing allows me to test stuff without investing a lot 
of extra time for setting up and using test systems.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/26564292.iuxY1J9fz6@merkaba

Re: systemd now appears to be only possible init system in testing

[Thomas Goirand]

On 07/23/2014 04:42 PM, Sune Vuorela wrote:
> On 2014-07-23, Sune Vuorela  wrote:
>> On 2014-07-23, Thomas Goirand  wrote:
>> and you doesn't again say "Let's have
>> someone run over specific developers with a bus", then the CoC is good.
> 
> Dear Thomas
> 
> I sincerely apologize for the above line. Somehow my internal memory
> mixed up one T... G... with another. 

LOL ! I'm not that person you're referring to indeed (if we're thinking
about the same one). I hope my style is a bit less aggressive than this.

I've been trying hard to make my posts more readable over the last
years, I hope it shows. And if it doesn't, please let me know privately
why so I can correct myself, as mistakes can always happen.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d0abe0.1060...@debian.org

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Russ Allbery]

Vincent Lefevre  writes:
> On 2014-07-22 19:54:10 -0700, Russ Allbery wrote:

>> logind is also not mandatory in Debian now.  It's just required,
>> upstream, by all the major desktop environments.

> Not just by all the major desktop environments. It is also needed by
> hplip via dependencies[*], which is quite surprising for a "HP Linux
> Printing and Imaging System".

> [*] hplip -> policykit-1 -> libpam-systemd -> systemd

> Or is there any abuse of a dependency here?

Someone with more detailed desktop knowledge should read this over and
correct it as necessary.  This is just my understanding of what's going
on, and I don't work with the software in question and could be wrong in
some details.

There is a general class of problems around "let the user on console do
" that were originally controlled via UNIX groups.  The problem
with doing this via UNIX groups is that either you need complicated PAM
machinery to add supplemental groups based on whether the user is on
console, or you have to change the security model to "users who are
allowed to use the console but may not be on console at this time," which
poses other problems.

PolicyKit provided an alternative way of handling those problems, and I
suspect that's why HPLIP depended on PolicyKit.  It allowed a more direct
expression of rules like "only users on console can do this."

However, PolicyKit has basically been orphaned upstream, replaced by the
rewritten polkit, and I believe polkit depends on logind to provide core
functionality around knowing what users are on console.  So anything that
had switched from something group-based for handling this problem to
PolicyKit has probably moved or is moving to polkit, which relies on
facilities currently only provided by logind.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvhr3c11@windlord.stanford.edu

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Vincent Lefevre]

On 2014-07-22 19:54:10 -0700, Russ Allbery wrote:
> logind is also not mandatory in Debian now.  It's just required, upstream,
> by all the major desktop environments.

Not just by all the major desktop environments. It is also needed
by hplip via dependencies[*], which is quite surprising for a
"HP Linux Printing and Imaging System".

[*] hplip -> policykit-1 -> libpam-systemd -> systemd

Or is there any abuse of a dependency here?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723224655.ga14...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Agustin Martin]

On Tue, Jul 22, 2014 at 10:54:55PM +0100, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?
> Well, because the new version of libpam-systemd, 208-6, now depends on
> systemd-sysv rather than systemd-sysv | systemd-shim.  OK, so I'll
> remove libpam-systemd.  Ooops - that looks pretty disastrous, as so
> much depends on it, so that's not an option: gdm3, gnome-bluetooth,
> network-manager, policykit-1, udisks2.

I put old systemd stuff on hold until this is sorted out. Did not notice
any problem with that.

> So I would presume that for many or most Debian systems, systemd is
> now required, and no other /sbin/init providers will work.  I'm
> unclear whether this was a deliberate policy decision or an unintended
> consequence of various package requirements.

This should be a temporary problem until cgmanager makes its way into sid
and systemd-shim can start uting it.

There were two maintainers trying to package cgmanager independently and
have it into NEW. That was the reason for rejection. Both maintainers are
currently working together to get the cgmanager package ready, even if
merging changes from both sides means some days of delay (See #754910).

-- 
Agustin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723175631.ga19...@agmartin.aq.upm.es

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Russ Allbery]

Juliusz Chroboczek  writes:

>> However, you're doing this during boot, so there *are* no active users,
>> since the system hasn't come up far enough to let anyone log in yet.  So
>> it makes sense that you don't get a prompt.

> Does that mean that the new pid 1 expects users to be logged in before it
> starts the system?

No, of course not.

The tool that you're using isn't only for use during early boot, and
you're using it in a way that is incorrect for use during early boot.  The
solution is to use the tool correctly.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87egxc6les@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Matthias Urlichs]

Hi,

Juliusz Chroboczek:
> I don't think the comparison between texlive and systemd is quite fair.

Any comparison will have its "apples vs. potatoes" aspects.
That doesn't invalidate the comparable parts.

> I still believe that this is just bad coordination and bad communi-
> cation on the part of the systemd packagers

Steve (Langasek) already stated that he will not belabor this point,
and he's the systemd-shim maintainer. He is thus in a far better position
to assign blame / sinister motives / unwillingness to cooperate
to the systemd people.

Or not.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723163048.gh15...@smurf.noris.de

Re: systemd now appears to be only possible init system in testing

[Juliusz Chroboczek]

> I'm sure the texlive maintainers feel perfectly justified in breaking 
> existing setups and causing packages to FTBFS by doing this.

I don't think the comparison between texlive and systemd is quite fair.
Texlive updates don't break users' systems, they just make some packages
temporarily un-upgradeable.  And even if they did break, they wouldn't
break the systems of troff users.

To some of us, this transition is starting to feel like a rather unsubtle
attempt to force systemd down everyone's throat, whether we want it or
not.  I still believe that this is just bad coordination and bad communi-
cation on the part of the systemd packagers, and sincerely hope that this
is not a coordinated attack on non-systemd installations.

-- Juliusz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r41ccdrw.wl-...@pps.univ-paris-diderot.fr

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Juliusz Chroboczek]

> However, you're doing this during boot, so there *are* no active users,
> since the system hasn't come up far enough to let anyone log in yet.  So
> it makes sense that you don't get a prompt.

Does that mean that the new pid 1 expects users to be logged in before it
starts the system?

-- Juliusz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ppgwcdp5.wl-...@pps.univ-paris-diderot.fr

Re: systemd now appears to be only possible init system in testing

[Stuart Prescott]

Hi Norbert,

Please remember these arguments you have been making next time you make what 
you believe are perfectly justified changes to the texlive packaging by 
(once again) introducing new and incompatible versions of sty files or 
moving files between packages.

I'm sure the texlive maintainers feel perfectly justified in breaking 
existing setups and causing packages to FTBFS by doing this. I'm sure you 
can explain to me that it's all much better for the changes, even though it 
looks like it only makes work for me. I understand that to a large extent 
your hands are tied because you need to track upstream releases and you 
can't hold a style file at an ancient version forever just to make sure that 
nothing gets broken.

Because I trust the texlive maintainers to be fundamentally doing the right 
things for Debian, I don't reassign all the bugs you cause to the texlive 
packages because they were the ones that broke their reverse-dependencies. 
Rather, I spend the time to adapt to the new way. Similarly, I don't rant on 
mailing lists about how the world is going to end because of this breakage. 
I don't make insinuations about the competence of the texlive maintainers 
when I don't understand why they have done something. I don't belittle your 
work. I don't run around complaining that your approach to texlive is a 
giant conspiracy.

The same is true for a package like systemd-shim which would permit you to 
use the packages you talked about without running systemd. systemd-shim has 
to adapt to the changing landscape around it and it is the responsibility of 
its authors (NOT the systemd maintainers) to have it ready and functioning. 
What's more, I believe that work is well advanced and you'll find more 
information about that in this thread.

A little empathy for fellow developers, a little time looking in the mirror 
and some effort to see things from other perspectives would go a long way 
and be greatly appreciated.

Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lqogpu$i0r$1...@ger.gmane.org

Re: systemd now appears to be only possible init system in testing

[Thorsten Glaser]

Cameron Norman wrote:

>I noticed that not doing the libraries cause apt to try to upgrade them
>on dist-upgrade and do some weird operations like try to remove my
>current init system and install systemd-sysv or remove all of systemd,
>as well as NM and udisks and a lot of other packages.

FWIW, there¹⁴ is now a prevent-systemd-running package which only
Conflicts: live-config-systemd, systemd-cron, systemd-sysv, systemd-ui
and thus will keep all those packages you mentioned installed.
Since it is “Important: yes”, it probably²³ prevents APT from wanting
to upgrade those library packages.

① http://users.unixforge.de/~tglaser/debs/debidx.htm
  built from the “mirabilos-support” source package.

② I do not have prevent-systemd-running installed,
  only the harsher versions.

③ But the new contrib/prevent-nvidia-removal metapackage
  did prevent xserver-xorg-video-nvidia from being removed
  and let APT keep the older X.org installed instead of
  wishing to upgrade it, until non-free/nvidia-driver
  was updated, which is the same mechanism, so I’m positive
  that this will work for you.

④ Thanks to not only Wookey but also XTaran for contributing!

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lqo32n$8gm$1...@ger.gmane.org

Re: systemd now appears to be only possible init system in testing

[Sune Vuorela]

On 2014-07-23, Sune Vuorela  wrote:
> On 2014-07-23, Thomas Goirand  wrote:
> and you doesn't again say "Let's have
> someone run over specific developers with a bus", then the CoC is good.

Dear Thomas

I sincerely apologize for the above line. Somehow my internal memory
mixed up one T... G... with another. 

I'm really sorry.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lqnsh9$oeu$2...@ger.gmane.org

Re: systemd now appears to be only possible init system in testing

[Sune Vuorela]

On 2014-07-23, Thomas Goirand  wrote:
> If the CoC makes it impossible for Norbert to express himself in the way
> he just did, then the CoC is bad and should be repelled.

If the CoC helps ensure that Norbert doesn't again say "I don't give a
shit about other people's work" - and you doesn't again say "Let's have
someone run over specific developers with a bus", then the CoC is good.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lqnr8r$oeu$1...@ger.gmane.org

Re: systemd now appears to be only possible init system in testing

[Matthias Urlichs]

Hi,

Thomas Goirand:
> If the CoC makes it impossible for Norbert to express himself in the way
> he just did, then the CoC is bad and should be repelled.
> 
*repealed.

I disagree. Insinuating that the systemd proponents' goal is
>> "One init to rule them all, to bind them, and throw them into darkness!"
is not a contribution to this mailing list that's suitable for furthering
reasoned discourse. To put it mildly. Adding a disclaimer doesn't help,
frankly.

> I'm getting really tired of the internet police and thoughts control...
> 
Well, some other people are way past getting tired of people who jump in
with an anti-systemd rant every time somebody has a legitimate problem
with (part of) it, so I guess we're even.  :-P

In any case, requesting reasoned discourse instead of rants on this list
is not "thought control". You're free to think whatever you want about
systemd. You're also free to express these thoughts in any way, shape or
form you want – but if you need to do it in a way that is detrimental to
this list, please do it someplace else.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723080729.gg15...@smurf.noris.de

Re: systemd now appears to be only possible init system in testing

[Thomas Goirand]

On 07/23/2014 07:46 AM, Ben Finney wrote:
> Writing a disclaimer doesn't exempt you from the Code of conduct in
> Debian forums. Please don't violate it again.

If the CoC makes it impossible for Norbert to express himself in the way
he just did, then the CoC is bad and should be repelled.

I'm getting really tired of the internet police and thoughts control...

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53cf64f0.8030...@debian.org

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Russ Allbery]

Adam Borowski  writes:
> On Wed, Jul 23, 2014 at 03:58:32AM +0200, Holger Levsen wrote:

>> Well, the subject (and also the body) conveyed the wrong message, that
>> systemd is mandatory in Debian now. Which - as you also said - is
>> wrong, at least for two reasons: a.) it's logind, not systemd and b.)
>> only desktops are affected.

> apt-get install logind
> E: Unable to locate package logind

> If logind was detachable from systemd, it would be in a separate package.

logind is also not mandatory in Debian now.  It's just required, upstream,
by all the major desktop environments.

I think one point Holger was making is that *desktop environments* are not
mandatory in Debian.  I have lots of Debian systems, including my desktop,
that don't run any desktop environment at all.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbqohjjh@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Tue, 22 de Jul 2014 a las 4:39 PM, Vincent Lefevre 
 escribió:

On 2014-07-23 01:24:53 +0200, Vincent Lefevre wrote:

 On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
 > I just tried updating testing on my system.  I currently use
 > sysvinit-core (reasons below), but aptitude is telling me that I
 > should remove this in favour of systemd-sysv.  Hmm, why is that?
 > Well, because the new version of libpam-systemd, 208-6, now 
depends on

 > systemd-sysv rather than systemd-sysv | systemd-shim.
 
 As you can see with this dependency, you just need to install

 systemd-shim. No need to install systemd-sysv!
 
 The default (systemd-sysv) was just a poor choice from aptitude.


Sorry, I mixed up with another problem that occurred with previous
versions. I have no problems on my Debian/unstable machines
(libpam-systemd still depends on systemd-sysv | systemd-shim),
but I've just realized that the reason is that I temporarily
blocked systemd upgrades for another reason. This is probably
the best thing to do because seeing how things evolve.


I used this apt preferences part to keep systemd back to version 204 
until systemd-shim is updated:


   Package: systemd libsystemd-* libpam-systemd
   Pin: version 204*
   Pin-Priority: 1001

I noticed that not doing the libraries cause apt to try to upgrade them 
on dist-upgrade and do some weird operations like try to remove my 
current init system and install systemd-sysv or remove all of systemd, 
as well as NM and udisks and a lot of other packages.


Best wishes,
--
Cameron Norman

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Adam Borowski]

On Wed, Jul 23, 2014 at 03:58:32AM +0200, Holger Levsen wrote:
> Well, the subject (and also the body) conveyed the wrong message, that 
> systemd 
> is mandatory in Debian now. Which - as you also said - is wrong, at least for 
> two reasons: a.) it's logind, not systemd and b.) only desktops are affected.

apt-get install logind
E: Unable to locate package logind

If logind was detachable from systemd, it would be in a separate package.


For now, just use the last working version of policykit (0.105-4).

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723023548.ga23...@angband.pl

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Holger Levsen]

Hi Steve,

thanks for the technical details, much appreciated. 

On Mittwoch, 23. Juli 2014, Steve Langasek wrote:
> There was nothing in Julian's message which was a rant, so I don't think
> this response is called for.

Well, the subject (and also the body) conveyed the wrong message, that systemd 
is mandatory in Debian now. Which - as you also said - is wrong, at least for 
two reasons: a.) it's logind, not systemd and b.) only desktops are affected.

And, even though the rest of Julians message was as you described, it 
attracted two quite flamatory replies at first...

> He *was* doing something about a systemd
> integration problem that was a blocker for him - he was asking for help.
> 
> If we have to go through this same sequence of messages every time someone
> asks on debian-devel for help with a systemd issue, it's going to be a long
> release cycle.

I totally agree with these parts - and while I do think this thread startly 
badly I also think it has become a much nicer one by now. Hopefully this is 
more like how systemd threads will be in future too ;)


cheers,
Holger



signature.asc
Description: This is a digitally signed message part.

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Steve Langasek]

On Wed, Jul 23, 2014 at 01:26:47AM +0200, Holger Levsen wrote:
> On Dienstag, 22. Juli 2014, Julian Gilbey wrote:
> > I just tried updating testing on my system.  I currently use
> > sysvinit-core (reasons below), but aptitude is telling me that I
> > should remove this in favour of systemd-sysv.  Hmm, why is that?

> Because all modern desktops now need systemd so all features work. blame 
> upstream^w^wsend patches to upstream and Debian will have those...

What they need is logind.  Saying "needs systemd" for things that need
logind is as hopelessly confusing as if you were to say it for things that
need udev.

logind itself currently needs systemd as PID 1, because systemd 208 was
uploaded to unstable (and has migrated to testing) before systemd-shim has
been updated for compatibility.

I have already opined that I think this was a bad idea and will not belabor
the point.

> Really, get over it or do something. Ranting on -devel will not change 
> anything. 

There was nothing in Julian's message which was a rant, so I don't think
this response is called for.  He *was* doing something about a systemd
integration problem that was a blocker for him - he was asking for help.

If we have to go through this same sequence of messages every time someone
asks on debian-devel for help with a systemd issue, it's going to be a long
release cycle.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Ben Hutchings]

On Wed, 2014-07-23 at 00:08 +0100, Julian Gilbey wrote:
> On Wed, Jul 23, 2014 at 12:51:16AM +0200, Svante Signell wrote:
> > Forward this to the debian CTTE, please!
> 
> Thanks for the suggestion, Svante!  I've just reread
> https://www.debian.org/devel/tech-ctte and it does not yet seem
> appropriate for the CTTE; there has not yet been any discussion with
> the relevant package maintainers.
> 
> A bit more searching (reading the relevant changelogs) has shown that
> bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752939 and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754984 contain a lot
> more information about this issue.
> 
> It seems that once cgmanager 0.27 is allowed into unstable from NEW, a
> new version of systemd-shim will be able to be uploaded, which will
> allow libpam-systemd to coexist with sysvinit once again.
> 
> It's just a shame that various migrations to testing were allowed
> before this had been resolved :-(
> 
> Anyway, I would still love to know how to write a systemd script which
> pauses to accept input from the keyboard before continuing.

I believe you're supposed to do that through plymouth (which does not
imply a graphical boot splash; it has a text mode as well).

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Russ Allbery]

Holger Levsen  writes:
> On Dienstag, 22. Juli 2014, Julian Gilbey wrote:

>> For me, this is a killer, as I still do not know how to solve the
>> problem I asked a while back on debian-user
>> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
>> summary, I need to unlock an encrypted filesystem during boot time by
>> asking for a password to feed into encfs.  But I cannot figure out how
>> to do this under systemd.
>> 
>> Answers to this question would also be much appreciated!

> I hope someone will be able to help Julian with this question...

This is just speculation, and I've not tried this, but my first thought in
reading this message is that the --no-tty part is a mistake.  The
documentation of that option says:

When run with no TTY or with --no-tty it will query the password
system-wide and allow active users to respond via several agents. The
latter is only available to privileged processes.

However, you're doing this during boot, so there *are* no active users,
since the system hasn't come up far enough to let anyone log in yet.  So
it makes sense that you don't get a prompt.

I suspect you instead need to run systemd-ask-password with a tty.  Take a
look at systemd.exec(5) at the TTY* options for the systemd unit file.  I
suspect you need to write a unit file corresponding to your init script
that runs systemd-ask-password and uses TTYPath=/dev/tty1.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ha29ndyf@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Ben Finney]

Norbert Preining  writes:

> [ IMPORTANT - COC DISCLAIMER - IMPORTANT - PLEASE READ BEFORE
> CONTINUING ]

Writing a disclaimer doesn't exempt you from the Code of conduct in
Debian forums. Please don't violate it again.

-- 
 \  “It's up to the masses to distribute [music] however they want |
  `\… The laws don't matter at that point. People sharing music in |
_o__)their bedrooms is the new radio.” —Neil Young, 2008-05-06 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85d2cxot2z@benfinney.id.au

Re: systemd now appears to be only possible init system in testing

[Matthias Urlichs]

Hi,

Julian Gilbey:
> I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.
> 
"encfs --extpass=systemd-ask-password" ?

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722234438.ge15...@smurf.noris.de

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-23 01:24:53 +0200, Vincent Lefevre wrote:
> On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
> > I just tried updating testing on my system.  I currently use
> > sysvinit-core (reasons below), but aptitude is telling me that I
> > should remove this in favour of systemd-sysv.  Hmm, why is that?
> > Well, because the new version of libpam-systemd, 208-6, now depends on
> > systemd-sysv rather than systemd-sysv | systemd-shim.
> 
> As you can see with this dependency, you just need to install
> systemd-shim. No need to install systemd-sysv!
> 
> The default (systemd-sysv) was just a poor choice from aptitude.

Sorry, I mixed up with another problem that occurred with previous
versions. I have no problems on my Debian/unstable machines
(libpam-systemd still depends on systemd-sysv | systemd-shim),
but I've just realized that the reason is that I temporarily
blocked systemd upgrades for another reason. This is probably
the best thing to do because seeing how things evolve.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722233957.gd3...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Charles Plessy]

Le Wed, Jul 23, 2014 at 12:08:04AM +0100, Julian Gilbey a écrit :
> 
> Anyway, I would still love to know how to write a systemd script which
> pauses to accept input from the keyboard before continuing.

Hi Julian,

I suggest to ask this question on 
pkg-systemd-maintain...@lists.alioth.debian.org
or even on systemd-de...@lists.freedesktop.org.  Pepole there are supportive and
may be able to help you to find the way to boot your encrypted filesystem while
using systemd.

On debian-devel unfortunately, there are too many people who will actively
repel any attempt of solving your problem (a few pepole are enough to destroy
the productivity of a mailing list).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722233445.gc17...@falafel.plessy.net

all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Holger Levsen]

Hi,

(as this thread has already attracted two "interesting replies", I'll try 
again to convey the message which has not been heard yet... I don't have high 
hopes this thread won't become a flamefest, but I want to at least try to kill 
the flames before they explode...)

(And if you know systemd, please scroll down and help Julian with his actual 
question...)

On Dienstag, 22. Juli 2014, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?

Because all modern desktops now need systemd so all features work. blame 
upstream^w^wsend patches to upstream and Debian will have those...

Really, get over it or do something. Ranting on -devel will not change 
anything. 

And this is actually pretty old news too: see 
http://layer-acht.org/thinking/blog/2014-06-03-systemd-mostly-harmless/

Thank you.

> So I would presume that for many or most Debian systems, systemd is
> now required

s#most Debian systems#most Debian desktop systems#

> For me, this is a killer, as I still do not know how to solve the
> problem I asked a while back on debian-user
> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.
> 
> Answers to this question would also be much appreciated!

I hope someone will be able to help Julian with this question...


cheers,
Holger




signature.asc
Description: This is a digitally signed message part.

Disclaimers (was: Re: systemd now appears to be only possible init system in testing)

[Christian Hofstaedtler]

* Norbert Preining  [140723 01:09]:
> [ IMPORTANT - COC DISCLAIMER - IMPORTANT - PLEASE READ BEFORE CONTINUING ]
> This email is the personal opinion of its author.
> As we are not allowed to criticize due to the newly installed 
> Code of Conduct, you are required to pre- or postfix *every* sentence
> in the following email with one of the following fragments:
>   . I thing it might be an option to say that 
>   . I could reach the opinion that under certain circumstances ...
>   . In my all too humble opinion, which is not important, ...
> Failure to do the above will result in wrong interpretation of the
> following email, so stop reading here if you are not ready to do that.
> [ COC DISCLAIMER ENDS HERE ]

How does "write a disclaimer in the hope of justifying possible
violations of rules instead of doing something productive" fit into
anybody's applied business logic?

  C.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722232628.ga96...@sx.home.zeha.at

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?
> Well, because the new version of libpam-systemd, 208-6, now depends on
> systemd-sysv rather than systemd-sysv | systemd-shim.

As you can see with this dependency, you just need to install
systemd-shim. No need to install systemd-sysv!

The default (systemd-sysv) was just a poor choice from aptitude.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722232452.gb3...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Marco d'Itri]

On Jul 22, Julian Gilbey  wrote:

> So I would presume that for many or most Debian systems, systemd is
> now required, and no other /sbin/init providers will work.  I'm
> unclear whether this was a deliberate policy decision or an unintended
> consequence of various package requirements.
It is a consequence of systemd-shim not being ready at the time systemd 
was last updated in unstable. I understand that now it is, but it still 
waiting for NEW processing of one of its dependencies.
If you care so much then maybe you could help the maintainers.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Tue, Jul 22, 2014 at 10:54:55PM +0100, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?
> Well, because the new version of libpam-systemd, 208-6, now depends on
> systemd-sysv rather than systemd-sysv | systemd-shim.  OK, so I'll
> remove libpam-systemd.  Ooops - that looks pretty disastrous, as so
> much depends on it, so that's not an option: gdm3, gnome-bluetooth,
> network-manager, policykit-1, udisks2.

> So I would presume that for many or most Debian systems, systemd is
> now required, and no other /sbin/init providers will work.  I'm
> unclear whether this was a deliberate policy decision or an unintended
> consequence of various package requirements.

See bug #752939, which is currently blocked on cgmanager, which was in the
NEW queue but for some reason seems to have been rejected rather than
accepted.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Christian Hofstaedtler]

* Julian Gilbey  [140723 00:36]:
> For me, this is a killer, as I still do not know how to solve the
> problem I asked a while back on debian-user
> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.

Can't directly help you with this, but the manual page text for
`--no-tty` reads as if it would do the opposite of what you actually
want to do.

  C.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722231233.ga96...@sx.home.zeha.at

Re: systemd now appears to be only possible init system in testing

[Julian Gilbey]

On Wed, Jul 23, 2014 at 12:51:16AM +0200, Svante Signell wrote:
> Forward this to the debian CTTE, please!

Thanks for the suggestion, Svante!  I've just reread
https://www.debian.org/devel/tech-ctte and it does not yet seem
appropriate for the CTTE; there has not yet been any discussion with
the relevant package maintainers.

A bit more searching (reading the relevant changelogs) has shown that
bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752939 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754984 contain a lot
more information about this issue.

It seems that once cgmanager 0.27 is allowed into unstable from NEW, a
new version of systemd-shim will be able to be uploaded, which will
allow libpam-systemd to coexist with sysvinit once again.

It's just a shame that various migrations to testing were allowed
before this had been resolved :-(

Anyway, I would still love to know how to write a systemd script which
pauses to accept input from the keyboard before continuing.

   Julian

> On Tue, 2014-07-22 at 22:54 +0100, Julian Gilbey wrote:
> > I just tried updating testing on my system.  I currently use
> > sysvinit-core (reasons below), but aptitude is telling me that I
> > should remove this in favour of systemd-sysv.  Hmm, why is that?
> > Well, because the new version of libpam-systemd, 208-6, now depends on
> > systemd-sysv rather than systemd-sysv | systemd-shim.  OK, so I'll
> > remove libpam-systemd.  Ooops - that looks pretty disastrous, as so
> > much depends on it, so that's not an option: gdm3, gnome-bluetooth,
> > network-manager, policykit-1, udisks2.
> > 
> > So I would presume that for many or most Debian systems, systemd is
> > now required, and no other /sbin/init providers will work.  I'm
> > unclear whether this was a deliberate policy decision or an unintended
> > consequence of various package requirements.
> > 
> > For me, this is a killer, as I still do not know how to solve the
> > problem I asked a while back on debian-user
> > (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> > summary, I need to unlock an encrypted filesystem during boot time by
> > asking for a password to feed into encfs.  But I cannot figure out how
> > to do this under systemd.
> > 
> > Answers to this question would also be much appreciated!
> > 
> >Julian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722230804.ga30...@d-and-j.net

Re: systemd now appears to be only possible init system in testing

[Svante Signell]

Forward this to the debian CTTE, please!

On Tue, 2014-07-22 at 22:54 +0100, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?
> Well, because the new version of libpam-systemd, 208-6, now depends on
> systemd-sysv rather than systemd-sysv | systemd-shim.  OK, so I'll
> remove libpam-systemd.  Ooops - that looks pretty disastrous, as so
> much depends on it, so that's not an option: gdm3, gnome-bluetooth,
> network-manager, policykit-1, udisks2.
> 
> So I would presume that for many or most Debian systems, systemd is
> now required, and no other /sbin/init providers will work.  I'm
> unclear whether this was a deliberate policy decision or an unintended
> consequence of various package requirements.
> 
> For me, this is a killer, as I still do not know how to solve the
> problem I asked a while back on debian-user
> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.
> 
> Answers to this question would also be much appreciated!
> 
>Julian
> 
> 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1406069476.2350.0.camel@PackardBell-PC

Re: systemd now appears to be only possible init system in testing

[Norbert Preining]

Hi Julian,

long time no see!

[ IMPORTANT - COC DISCLAIMER - IMPORTANT - PLEASE READ BEFORE CONTINUING ]
This email is the personal opinion of its author.
As we are not allowed to criticize due to the newly installed 
Code of Conduct, you are required to pre- or postfix *every* sentence
in the following email with one of the following fragments:
. I thing it might be an option to say that 
. I could reach the opinion that under certain circumstances ...
. In my all too humble opinion, which is not important, ...
Failure to do the above will result in wrong interpretation of the
following email, so stop reading here if you are not ready to do that.
[ COC DISCLAIMER ENDS HERE ]

[ JOKE DISCLAIMER START ]
If you are without humour - stop reading here!
[ JOKE DISCLAIMER END ]

On Tue, 22 Jul 2014, Julian Gilbey wrote:
> much depends on it, so that's not an option: gdm3, gnome-bluetooth,
> network-manager, policykit-1, udisks2.

Yes, if you use *anything* slightly gnome related, you are hosed
and need to install systemd.

You need to get rid of gdm3, gnome-bluetooth, and network-manager,
then it should be possible to get a system without systemd.
If you want one of these ... well, then the systemd mafia got you!

That is Debian, as long nobody steps forward and stops this.

> unclear whether this was a deliberate policy decision or an unintended

Deliberate. Since systemd* 208, systemd-shim is "said to be not compatible"
anymore. Well, here we go with freedom.

> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.

Everything can be done in systemd, since it is Turing complete.
The only problem is that nobody knows how to, it is not predicatable
what will actually happen (formatted hard disk, crashed kernel, etc).

In your case I *strongly* recommend to remove nm, gdm3 and by this
get rid of systemd, too.

> Answers to this question would also be much appreciated!

There are thousands of emails here, all with the same effect:

We have commit rights, so go away and shut up!

or alternatively

We are systemd, and we are now the only init system in Debian,
so go away and shut up.

or again alternatively

One init to rule them all, to bind them, and throw them into
darkness!

Fortunately, I don't use encrypted disks or anything fancy, so I am 
stupid dummy user that has no special requirements. So I am free to
use systemd, because this is the target audience!

If you would fall into the same category, you could be happy, too, but
alas, ... you are a power user and thus hosed.

Norbert

[ END OF DISCLAIMER GOVERNED TEXT ]


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014075305.gb6...@auth.logic.tuwien.ac.at