Re: systemd-fsck?

[Salvo Tomaselli]

> As far as I have read in this thread, the only reported problem with
> upgrading from sysv to systemd concerns remote virtual machines that
> won't boot.
As I said earlier: some bits of my log entries are getting discarded by 
journald.


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/


-- 
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/21221428.hoSJR14PtD@hal9000

Re: systemd-fsck?

[Tomas Pospisek]

Am 13.05.2014 21:49, schrieb Cyril Brulebois:
> Thibaut Paumard  (2014-05-13):
>> Le 13/05/2014 17:36, Russ Allbery a écrit :
>>> Right, which I've been arguing for already in this thread.  I don't think
>>> we should force this on upgrades.  There should be a prompt and an
>>> opportunity to not change init systems.
>>
>> Instead of or in addition to such prompting, I expect this switch will
>> be documented in the Release Notes so that people who really care are
>> aware of the risks and the cases which are known to break.
> 
> The sad thing is: almost nobody reads the release notes.

Are you saying this just like that or can you back it up with facts somehow?

As far as I have read in this thread, the only reported problem with
upgrading from sysv to systemd concerns remote virtual machines that
won't boot.

Remote virtual machines are a problem that will mostly concern
sysadmins. Me as a responsible sysadmin am reading the release notes,
because I do not want to have downtimes with my machines and so I want
to know beforehand if there are any known problems that I should be
aware of. And I have trouble imagining that other people that call
themselves sysadmins do not act the same. Or do they?

*t




-- 
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/53765d0c.1000...@sourcepole.ch

Re: systemd-fsck?

[Tomas Pospisek]

Am 15.05.2014 01:42, schrieb Marc Haber:
> On Tue, 13 May 2014 17:28:27 +0200, Vincent Bernat 
> wrote:
>> ? 13 mai 2014 15:01 +0200, Marc Haber  :
 Thank you so much for volunteering to contribute to GNOME packaging and
 to make it work on configurations nobody will actually ever use.

 We are eagerly waiting for your patches.
>>>
>>> This sort of behavior is precisely why many users are migrating away
>>> from Debian.
>>
>> Could you please stop FUD? Do you have some reference for this claim?
> 
> I know at least two of them. And I, for myself, have greatly reduced
> my efforts to report bugs in Debian since I alredy know the reaction
> of many maintainers.

Oh, please don't. When I have a problem, searching the BTS is one of the
most efficient ways to improve my knowledge. Please also for the sake of
me and maybe also of other users, please do report bugs, even if you
expect the maintainer to ignore you.

*t


-- 
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/5376637c.80...@sourcepole.ch

Re: systemd-fsck?

[Lars Wirzenius]

On Fri, May 16, 2014 at 11:01:14AM +0200, Marc Haber wrote:
> On Thu, 15 May 2014 21:51:10 +0200, Josselin Mouette 
> wrote:
> >Given the fact/bullshit ratio of your recent posts, I invite you, again,
> >to take a step back from debian-devel.
> 
> Given the insult/information ratio of your (not only recent) posts...

In a galaxy, far, far away,
a clan of software freedom
warriers had retreated to a
secret base to plan and
prepare for their next big
attack. They were honing their
scripts, cleaning their codes,
triaging their bugs, and
generally making sure to be
ready for "The Big Freeze"
come November.

Then Adam called Bob a baby
and Charles got upset and David
was sarcastic at Edgar and Frank
pulled Gabriel's hair and then
they all woke up and it had all
been a dream and they started
crying in the nursery.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
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/20140516102314.gb5...@mavolio.codethink.co.uk

Re: systemd-fsck?

[Marc Haber]

On Thu, 15 May 2014 21:51:10 +0200, Josselin Mouette 
wrote:
>Given the fact/bullshit ratio of your recent posts, I invite you, again,
>to take a step back from debian-devel.

Given the insult/information ratio of your (not only recent) posts...

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1wle0w-0005h3...@swivel.zugschlus.de

Re: systemd-fsck?

[Guido Günther]

On Thu, May 15, 2014 at 07:51:37AM +, Thorsten Glaser wrote:
> >   From: Guido =?iso-8859-1?Q?G=FCnther?= 
> 
> >GTK+3 supports themes
> 
> GTK/GNOME people have stated numerous times that they do not want
> them.

There's not Debian people and not Gtk+/GNOME people, this current
thread shows this perfectly. And if nobody wanted themes they'd got
removed with Gtk+3, not enhanced and blogged about by Gtk+ upstream:

http://blogs.gnome.org/mclasen/2014/05/06/tweaking-a-the-gtk-theme-using-css/

> >. This
> >> is a perfectly fine job for a derivate or Pure Blend: to provide a
> >> polished system that serves one use case well.
> >
> >Proper integration certainly belongs into Debian or did we become a
> >supermarket:
> 
> Proper integration of components: yes. That is the _job_ of a distro.
> 
> Integration of some components at the cost of disabling the freedom
> of users to choose a different free component that also does the
> job,

It's just that the opinion about "the job" differ so widely.

> and at the cost of removing some users' use cases: no. That is not
> the job of a "Univeral OS". So-called Enterprise distributions can
> do that, sure. Downstreams and pure blends, too. But not Debian.

Fortunately that's not you or me to decide:

   https://www.debian.org/devel/constitution#item-2
   https://www.debian.org/devel/constitution#item-3

I'm having a hard time to see use cases go away. /etc/init.d/$foo is
not a use case it's a pattern that can easily be emulated or even be
provided by a package that creates wrappers for systemd units.
Cheers,
 -- Guido


-- 
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/20140515195543.gb2...@bogon.m.sigxcpu.org

Re: systemd-fsck?

[Josselin Mouette]

Le jeudi 15 mai 2014 à 07:51 +, Thorsten Glaser a écrit :
> >   From: Guido =?iso-8859-1?Q?G=FCnther?= 
> 
> >GTK+3 supports themes
> 
> GTK/GNOME people have stated numerous times that they do not want them.

Do you have a quote to back up your claims?

The fact is that themes are supported, and that a program was written
*by GNOME developers* to choose (among other things) the theme.

Given the fact/bullshit ratio of your recent posts, I invite you, again,
to take a step back from debian-devel.

-- 
 .''`.  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/1400183470.7850.7.ca...@kagura.malsain.org

Re: Release Notes (and any other documentation) (was: systemd-fsck?)

[Stefano Zacchiroli]

On Thu, May 15, 2014 at 06:33:41PM +0200, Luca Capello wrote:
> ...despite the above, MANY THANKS to all people writing the Release
> Notes (and any other official documentation), which is highly
> important at least for me, as well as a pleasure to read.

Hear hear, strongly and fully ack'd.
(And sorry for not being able to volunteer time to write some of them.)

I guess one reason why we are inclined to think that nobody reads the
release notes is that people who do read them are less likely to
encounter upgrade problems. Those who don't read them often encounter
problems, get back to us, and then we realize pretty quickly that the
root cause of their problems is precisely that they haven't read the
release notes.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Release Notes (and any other documentation) (was: systemd-fsck?)

[Luca Capello]

Hi there!

Nothing related to any init system in Debian, but...

On Tue, 13 May 2014 19:19:54 +0200, Cyril Brulebois wrote:
> Thibaut Paumard  (2014-05-13):
>> Le 13/05/2014 17:36, Russ Allbery a écrit :
>> > Right, which I've been arguing for already in this thread.  I don't think
>> > we should force this on upgrades.  There should be a prompt and an
>> > opportunity to not change init systems.
>> 
>> Instead of or in addition to such prompting, I expect this switch will
>> be documented in the Release Notes so that people who really care are
>> aware of the risks and the cases which are known to break.
>
> The sad thing is: almost nobody reads the release notes.

...despite the above, MANY THANKS to all people writing the Release
Notes (and any other official documentation), which is highly important
at least for me, as well as a pleasure to read.

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Re: systemd-fsck?

[Gergely Nagy]

Thibaut Paumard  writes:

> Le 15/05/2014 10:55, Gergely Nagy a écrit :
>> You do realise we have one libc (sure, you can install *additional*
>> ones, but we have one libc the archive is compiled against), we have one
>> package manager (you can, of course, install rpm too, it is packaged!),
>> we have one "make" we use to build packages (you can try with others, at
>> your own peril, though), and we have one init system (you can install
>> anything else packaged, of course), right?
>
> If I follow your logic:
>
> "We have one desktop environment (xfce). Sure you can run GNOME, at your
> own peril."
>
> I'm not sure you wanted to reach this conclusion, but here it is.

That is a perfectly fine conclusion. If I want something else than the
default desktop, I'll make it work, and put in the effort (patches, if
need be) to make sure it is smooth for my use case. If there are others
who prefer an alternative too, and make it so that I don't have to do
anything at all, just an apt-get install gnome, so much the better!

-- 
|8]


--
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/87fvkb9ved@balabit.hu

Re: systemd-fsck?

[Thibaut Paumard]

Le 15/05/2014 10:55, Gergely Nagy a écrit :
> You do realise we have one libc (sure, you can install *additional*
> ones, but we have one libc the archive is compiled against), we have one
> package manager (you can, of course, install rpm too, it is packaged!),
> we have one "make" we use to build packages (you can try with others, at
> your own peril, though), and we have one init system (you can install
> anything else packaged, of course), right?

If I follow your logic:

"We have one desktop environment (xfce). Sure you can run GNOME, at your
own peril."

I'm not sure you wanted to reach this conclusion, but here it is.




signature.asc
Description: OpenPGP digital signature

Re: systemd-fsck?

[Svante Signell]

On Thu, 2014-05-15 at 10:55 +0200, Gergely Nagy wrote:
> Thorsten Glaser  writes:

> > Integration of some components at the cost of disabling the freedom
> > of users to choose a different free component that also does the job,
> > and at the cost of removing some users' use cases: no. That is not
> > the job of a "Univeral OS". So-called Enterprise distributions can
> > do that, sure. Downstreams and pure blends, too. But not Debian.

Agreed!

> We have a default, that's what Debian is integrating to. You want to
> change the default, that's what downstreams are for. You have the
> freedom to change whichever component you want, if you find people to do
> the neccessary work. Trying to support N+1 options and integrating them
> *all* places a huge burden on every single maintainer, a burden you do
> not want, nor need.

The problem (for me) is not the default init system, the problem is that
init system is changed without a debconf prompt, in my case by
installing network-manager. And NM can be used outside the gnome
environment as well as other gnome components.


-- 
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/1400145718.10012.50.ca...@g3620.my.own.domain

Re: systemd-fsck?

[Gergely Nagy]

Thorsten Glaser  writes:

>>. This
>>> is a perfectly fine job for a derivate or Pure Blend: to provide a
>>> polished system that serves one use case well.
>>
>>Proper integration certainly belongs into Debian or did we become a
>>supermarket:
>
> Proper integration of components: yes. That is the _job_ of a distro.
>
> Integration of some components at the cost of disabling the freedom
> of users to choose a different free component that also does the job,
> and at the cost of removing some users' use cases: no. That is not
> the job of a "Univeral OS". So-called Enterprise distributions can
> do that, sure. Downstreams and pure blends, too. But not Debian.

You do realise we have one libc (sure, you can install *additional*
ones, but we have one libc the archive is compiled against), we have one
package manager (you can, of course, install rpm too, it is packaged!),
we have one "make" we use to build packages (you can try with others, at
your own peril, though), and we have one init system (you can install
anything else packaged, of course), right?

We have a default, that's what Debian is integrating to. You want to
change the default, that's what downstreams are for. You have the
freedom to change whichever component you want, if you find people to do
the neccessary work. Trying to support N+1 options and integrating them
*all* places a huge burden on every single maintainer, a burden you do
not want, nor need.

-- 
|8]


-- 
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/87sioba09u@balabit.hu

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Michael Biebl:
> I can not confirm this behaviour Matthias describes with v204.
> 
Sorry, my bad. Turns out that this was not done via the rescue shell.
I was using the root shell which you get on TTY9 (assuming it is enabled,
which it usually isn't for obvious reasons).

Thanks for double-checking this.

-- 
-- 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/20140515075912.ga2...@smurf.noris.de

Re: systemd-fsck?

[Thorsten Glaser]

>   From: Guido =?iso-8859-1?Q?G=FCnther?= 

>GTK+3 supports themes

GTK/GNOME people have stated numerous times that they do not want them.

>. This
>> is a perfectly fine job for a derivate or Pure Blend: to provide a
>> polished system that serves one use case well.
>
>Proper integration certainly belongs into Debian or did we become a
>supermarket:

Proper integration of components: yes. That is the _job_ of a distro.

Integration of some components at the cost of disabling the freedom
of users to choose a different free component that also does the job,
and at the cost of removing some users' use cases: no. That is not
the job of a "Univeral OS". So-called Enterprise distributions can
do that, sure. Downstreams and pure blends, too. But not Debian.

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/ll1rm9$q9g$1...@ger.gmane.org

Re: systemd-fsck?

[Russ Allbery]

Jordan Metzmeier  writes:

> It's not loaded from /etc/profile by default (which would probably
> throw errors with other shells since all login shells source
> /etc/profile).

It is for me, via:

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
  . $i
fi
  done
  unset i
fi

See /etc/profile.d/bash_completion.sh.

However, I agree with the rest of your analysis.

-- 
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/8761l7wz9v@windlord.stanford.edu

Re: systemd-fsck?

[Jordan Metzmeier]

On Wed, May 14, 2014 at 7:22 PM, Russ Allbery  wrote:
> Roger Lynn  writes:
>> On 13/05/14 20:30, Salvo Tomaselli wrote:
>>> In data martedì 13 maggio 2014 19:42:32, David Goodenough ha scritto:
>
> service foo  works across Linux distributions, with or without
> systemd, and does the right thing.
>
 The big shame with service is that tab completion does not work properly.
 If I use /etc/init.d/ then tab tells me what is there and spells it right.
>
>>> You should install bash-completion
>
>> Bash-completion has never worked for me from a root prompt.
>
> bash-completion is loaded from /etc/profile, which is only sourced by bash
> for a login shell.  I suspect that you're using su, which does not create
> a login shell.  In that case, only /etc/bash.bashrc is sourced, and its
> code to load bash-completion for interactive shells is commented out.  (I
> don't know why.)
>
> I just confirmed that bash-completion works properly with service as root
> if you run . /etc/profile.d/bash_completion.sh first.
>

It's not loaded from /etc/profile by default (which would probably
throw errors with other shells since all login shells source
/etc/profile). The default /etc/skel/.bashrc contains the following:

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
  fi
fi


That is why it works for user accounts but not for root by default. As
the comment suggests you can uncomment the same code block in
/etc/bash.bashrc. It would be nice if the default /root/.bashrc
contained the same snippet. I am not sure how the initial
/root/.bashrc gets put in place or where root's default lives. I
assume it is done by d-i?

Regards,
Jordan Metzmeier


--
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/CAD758Rjzddwf7WvpZk+EsVcu7ct=m41zzpomyl_wmpm4xdw...@mail.gmail.com

Re: systemd-fsck?

[Russ Allbery]

Roger Lynn  writes:
> On 13/05/14 20:30, Salvo Tomaselli wrote:
>> In data martedì 13 maggio 2014 19:42:32, David Goodenough ha scritto:

 service foo  works across Linux distributions, with or without
 systemd, and does the right thing.

>>> The big shame with service is that tab completion does not work properly.
>>> If I use /etc/init.d/ then tab tells me what is there and spells it right.

>> You should install bash-completion

> Bash-completion has never worked for me from a root prompt.

bash-completion is loaded from /etc/profile, which is only sourced by bash
for a login shell.  I suspect that you're using su, which does not create
a login shell.  In that case, only /etc/bash.bashrc is sourced, and its
code to load bash-completion for interactive shells is commented out.  (I
don't know why.)

I just confirmed that bash-completion works properly with service as root
if you run . /etc/profile.d/bash_completion.sh first.

-- 
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/8738gbyjoz@windlord.stanford.edu

Re: systemd-fsck?

[Roger Lynn]

On 13/05/14 20:30, Salvo Tomaselli wrote:
> In data martedì 13 maggio 2014 19:42:32, David Goodenough ha scritto:
>> > service foo  works across Linux distributions, with or without
>> > systemd, and does the right thing.
>> 
>> The big shame with service is that tab completion does not work properly.
>> If I use /etc/init.d/ then tab tells me what is there and spells it right.
> 
> You should install bash-completion

Bash-completion has never worked for me from a root prompt.

Roger


-- 
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/qs8d4b-laq@silverstone.rilynn.me.uk

Re: systemd-fsck?

[Marc Haber]

On Tue, 13 May 2014 17:28:27 +0200, Vincent Bernat 
wrote:
> ? 13 mai 2014 15:01 +0200, Marc Haber  :
>>>Thank you so much for volunteering to contribute to GNOME packaging and
>>>to make it work on configurations nobody will actually ever use.
>>>
>>>We are eagerly waiting for your patches.
>>
>> This sort of behavior is precisely why many users are migrating away
>> from Debian.
>
>Could you please stop FUD? Do you have some reference for this claim?

I know at least two of them. And I, for myself, have greatly reduced
my efforts to report bugs in Debian since I alredy know the reaction
of many maintainers.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1wkgtc-0005pn...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Tue, 13 May 2014 20:08:18 +0100, "Adam D. Barratt"
 wrote:
>adam@wheezy:~$ service 

|[6/505]mh@swivel:~/transfer$ service  
|.directorykarte4.png
|fotovoltaik.png   lageplan.png
|karte1.pngpdns-backend-mysql_3.1-4.log
|karte2.pngxing.png
|karte3.png
|[6/505]mh@swivel:~/transfer$ service 

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1wkgnh-0005og...@swivel.zugschlus.de

Re: systemd-fsck?

[Michael Biebl]

Am 14.05.2014 18:30, schrieb The Wanderer:
> On 05/14/2014 12:07 PM, Jakub Wilk wrote:
> 
>> * Matthias Urlichs , 2014-05-14, 17:30:
> 
>>> In fact, rescuing a system becomes way easier even without learning
>>> any magic tools. For example, when bootup breaks you get dropped
>>> into a rescue shell, same as before. The difference with systemd is
>>> that as soon as you manage to mount that recalcitrant file system,
>>> bootup just continues; you don't actually have to *do* anything to
>>> trigger that.
> 
>> Oh, so the rescue shell disappearing in the least expected moment is
>> by design?
> 
> I thought of mentioning something in that direction myself.
> 
> When I've successfully mounted a missing filesystem in a rescue
> environment, I don't necessarily *want* to continue booting immediately;

I can not confirm this behaviour Matthias describes with v204.

If I have mount point in /etc/fstab which points to a
non-existing/non-available device, systemd *does* drop me into a rescue
shell, but mounting the mount point manually does *not* automatically
make the boot continue.
I have to exit the rescue shell for that.

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-fsck?

[Russ Allbery]

Matthias Urlichs  writes:

> I see two cases here.

> * I'm a logged-in user and use su to run … whatever.
>   In this case, whether it creates a new session or not doesn't matter
>   (because there already is one), so one more cannot add more blockage to
>   hibernation et al. than there already is.

PAM sessions are not just for blocking hibernation.  They do many other
things as well.  If you use su to run a command as another user where you
have to authenticate with a password, and you're using pam-krb5, you may
indeed want to create a new session so that your new Kerberos tickets are
properly stored (for NFSv4 access, for example) and removed properly when
that command or shell exits.

(Now, as it happens, in that particular case, I think only calling setcred
will do the right thing if the parent sticks around to call pam_end after
the command finishes.  But I don't believe that's universally the case.)

> * I'm a startup script or cron job.
>   For me, su should just set credentials, but *not* create any session
>   or similar.

Right.  (Or you should use something other than su.)

> * Oh, wait, there's a third one:
>   I'm using su to manually run "/etc/init.d/skeleton start", and expect the
>   daemon thus started to hang around indefinitely.

>   Not a problem with systemd since it redirects the actual
>   starting-of-the-daemon part to itself, thanks to the LSB function
>   inclusion which IMHO every init script should have these days (NB,
>   does Lintian check for that?).

Right.  And I think it does, although I'm not sure.

-- 
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/87wqdo2tkl@windlord.stanford.edu

Re: systemd-fsck?

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/14/2014 12:07 PM, Jakub Wilk wrote:

> * Matthias Urlichs , 2014-05-14, 17:30:
> 
>> In fact, rescuing a system becomes way easier even without learning
>> any magic tools. For example, when bootup breaks you get dropped
>> into a rescue shell, same as before. The difference with systemd is
>> that as soon as you manage to mount that recalcitrant file system,
>> bootup just continues; you don't actually have to *do* anything to
>> trigger that.
> 
> Oh, so the rescue shell disappearing in the least expected moment is
> by design?

I thought of mentioning something in that direction myself.

When I've successfully mounted a missing filesystem in a rescue
environment, I don't necessarily *want* to continue booting immediately;
I might want to check it and see if I can figure out what went wrong,
and/or make notes about what I did to get it working, or fix something
else that I know or suspect will have also gone wrong due to the same
cause and which I want to make sure is working before boot continues, or
any of a number of other things.

I would find having the system automatically continue boot just because
a filesystem got mounted to be quite surprising. At the bare minimum, I
would expect to need to terminate the rescue shell ('exit' or Ctrl-D)
before any such thing would occur. In fact, I would consider the need to
do so to be desirable.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTc5ovAAoJEASpNY00KDJrNXwP/3H3L7ydW010W6IAnFa3IDje
nzjDG12PVXcyP9n8AYbrWqONqhC5B2qNUGEDE2XwMz8WL1dhPLSYv0/vh3/9wiXR
6JOjo/5kCHh8BiD2BlQ4j1Un+obz3N/m3iwgCTFidABY7dj7CPzvFFkxge/Cjvme
idUA0VzzlIPktGn+f86iNS+4bDd9z0uum3ABxhPygJm5TkWKMJWhY9h30W4Aa9MQ
E904a3C8IlQGY/qgJ2lhzPMbWeRXiF1lAD0L/ffBdmKQewPkjFgkpM5Yvh6SiuZT
jAdGqq4282q3QPvTgxVCoDrePpFT07mYdnnrYEEx3GntQ0bWQ8vz8UmFt+BF8qc5
l/T8VFhGM5XoBs95i4y+oS+6FLQ6MRqMTe/05nadUWHLxk3v3LhK7+vXbZlavCck
R6C1v2oZ/seXtNnzss2gM6Ov/oYCpwSWvI5wqIaSBzrFepcBu52Jtf2DPWOoFcZc
7d2OXtTR3/RDF+FLIOQwZ5bmfCaQHGhnArddjWKf0vITlJAkg9F/3ihgAKVIXuB3
M99DagPwbUdWae38XU0Oq5xE9xT1k39T2BVqk0pXXnpSQzu/BuTgUMtbJxjRVIY5
3eHPUJU6cMUgkD14zDU5MLFeM2HqrWT2XsS+EuD8bBv0daB+ieetCu7kyqtlTSRF
KR5NIMl6+kO/Vg+EP0GU
=hgUJ
-END PGP SIGNATURE-


-- 
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/53739a2f.40...@fastmail.fm

Re: systemd-fsck?

[Jakub Wilk]

* Matthias Urlichs , 2014-05-14, 17:30:
In fact, rescuing a system becomes way easier even without learning any 
magic tools. For example, when bootup breaks you get dropped into a 
rescue shell, same as before. The difference with systemd is that as 
soon as you manage to mount that recalcitrant file system, bootup just 
continues; you don't actually have to *do* anything to trigger that.


Oh, so the rescue shell disappearing in the least expected moment is by 
design?


--
Jakub Wilk


--
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/20140514160729.ga2...@jwilk.net

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Thorsten Glaser:
> There’s not really a line between them, you know. (But it was
> nice to have a published list of those people who maybe could
> accidentally be hit by a tactical small-bus…)
> 
I hereby apologize to the list at large for replying to your earlier emails.

*PLONK*.

-- 
-- 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/20140514155948.gd15...@smurf.noris.de

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Thorsten Glaser:
> OK. But who says this is to stay? The systemd developers are
> hostile towards legacy stuff in a really intricate way. Take
> not jornal here but something else as example: they support
> running both ntpd and their own thing, to sweeten the deal
> now, but plan on dropping ntpd support later:
> http://www.ohloh.net/p/systemd/commits/335063290
> 
Maybe because ntpd has a different use case, and running a time *server*
on a system with no stable network connection does not make much sense?

This way of arguing is like a hydra.
You refute one, three others pop up.

-- 
-- 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/20140514155054.gc15...@smurf.noris.de

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Thorsten Glaser:
> • no /etc/init.d/$foo (to tabcomplete, no less!) any more
> 
Why you think these are going away? They're not, not any time soon;
and you can still use them when you're running systemd (assuming that you
include the LSB functions, like init.d/skeleton has been advising you for
the last umpteen years), no matter whether you have a native .service file.

And even if your init script is from the stone ages, it won't suddenly
break. More than before, that is.

> • totally different ways to rescue a system that does not boot
>   cleanly any more
> 
You choose the 'rescue' option in your boot manager. Same as now.

In fact, rescuing a system becomes way easier even without learning any
magic tools. For example, when bootup breaks you get dropped into a rescue
shell, same as before. The difference with systemd is that as soon as you
manage to mount that recalcitrant file system, bootup just continues;
you don't actually have to *do* anything to trigger that.

Contrast that to the SysV way where your best way to get a clean startup
in that situation is a reboot.

Anyway, yeah, the tools are different. They're also much more capable;
(wearing my sysadmin hat) I can fix my system / daemon a whole lot
faster than before -- don't ask me how often I had to use strace on some
daemon because its stderr got "helpfully" redirected to /dev/null or,
worse, to an already-recycled log file somewhere.

With a sensible systemd unit file, this becomes a non-issue.

So what *is* the problem?

> And CVS does not need replacing. (git’s got different use cases.)
> 
Frankly, I do not know of a single usecase for CVS which git doesn't
handle *way* better.

-- 
-- 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/20140514153013.gb15...@smurf.noris.de

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Russ Allbery:
> > How difficult would it be, for the sake of compatibility if nothing
> > else, to teach su not to create a new PAM session when it doesn't
> > already run within one?
> 
> You don't want to do that in general since that defeats the primary
> purpose of su: creating a new session as a different user.
> 
That's exactly my point. *In general*.

I see two cases here.

* I'm a logged-in user and use su to run … whatever.
  In this case, whether it creates a new session or not doesn't matter
  (because there already is one), so one more cannot add more blockage to
  hibernation et al. than there already is.

* I'm a startup script or cron job.
  For me, su should just set credentials, but *not* create any session
  or similar.

* Oh, wait, there's a third one:
  I'm using su to manually run "/etc/init.d/skeleton start", and expect the
  daemon thus started to hang around indefinitely.

  Not a problem with systemd since it redirects the actual starting-of-the-
  -daemon part to itself, thanks to the LSB function inclusion which IMHO
  every init script should have these days (NB, does Lintian check for
  that?).

> It's sort of an interesting question as to whether you want to set up a
> new session when running a single command.

Since su can't really know whether the command it runs is to be used like
a shell, a one-off, or a daemon, I'm afraid that this question doesn't have
a good answer.

-- 
-- 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/20140514151206.ga15...@smurf.noris.de

Re: systemd-fsck?

[Guido Günther]

On Tue, May 13, 2014 at 04:31:28PM +0200, Thorsten Glaser wrote:
> On Tue, 13 May 2014, Josselin Mouette wrote:
> 
> > My opinion is that many users are migrating away from Debian because we
> > are unable to make decisions on important technical topics and leave
> > them with 3 different setups, none of which actually work, instead of
> > providing one that is correctly polished.
> 
> That’s precisely the GNOME 3 attitude (“no themes allowed in GTK+3”,
> “our way or the highway”). I’m not surprised it’s also systemd’s, and
> yours.

GTK+3 supports themes

https://developer.gnome.org/gtk3/3.12/gtk-migrating-GtkStyleContext.html

and they can even be configured graphically via gnome-tweak-tool.

> And I say you’re wrong. This does not belong into Debian itself. This
> is a perfectly fine job for a derivate or Pure Blend: to provide a
> polished system that serves one use case well.

Proper integration certainly belongs into Debian or did we become a
supermarket:

http://joeyh.name/blog/entry/the_supermarket_thing/

Cheers,
 -- Guido


-- 
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/20140514131850.ga8...@bogon.m.sigxcpu.org

Re: systemd-fsck?

[Stephan Seitz]

On Tue, May 13, 2014 at 11:06:10AM -0700, Russ Allbery wrote:

Thorsten Glaser  writes:

• no /etc/init.d/$foo (to tabcomplete, no less!) any more

I've been telling people to stop using this for years.  You should stop


Doesn’t matter in mixed environments. Suse SLES11 has the service command 
as well but no tab completion and no package bash-completion.


So what do you think people will use in the end?


service foo  works across Linux distributions, with or without
systemd, and does the right thing.


Of course, as long as you know the name foo. And of course foo in Suse 
may be an other name as in Debian (sshd <-> ssh).



• the init system breaking init scripts hand-written by people
  who don’t really know what they’re doing, have not even heard
  of LSB, much less “units”
This was indeed a more difficult transition... which we already did 
years ago when we switched to dependency-based boot.  Which did cause 


We still have init scripts without LSB headers in our environment. No one 
is planning to fix them. There is even new third party software shipping 
init scripts without LSB headers.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: systemd-fsck?

[Didier 'OdyX' Raboud]

Le mardi, 13 mai 2014, 17.21:45 Thorsten Glaser a écrit :
> Didier 'OdyX' Raboud dixit:
> >Le mardi, 13 mai 2014, 16.25:31 Thorsten Glaser a écrit :
> >> On Mon, 12 May 2014, Tollef Fog Heen wrote:
> >> > Are you aware that Joss isn't a systemd maintainer?  (He's one of
> >> > the GNOME maintainers.)
> >> 
> >> There’s not really a line between them, you know. (But it was
> >
> >On top of your first sentence being factually wrong (check the
> >maintainer fields of the respective packages), I really think your
> 
> I *know* that the people listed as maintainers of the respective
> Debian packages, (…)

Please don't quote private mails in public. Also, don't evade the 
criticism on on your unacceptable words and retract your statement.

TIA, OdyX


--
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/2755547.vUKYPZ7X3A@gyllingar

Re: systemd-fsck?

[Michael Biebl]

Am 13.05.2014 23:46, schrieb David Goodenough:
> Does bash-completion work when the command is sudo not service?  Never seems
> to for me.  I never log in as root, I always do root things using sudo.

Sure, works fine.

-- 
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-fsck?

[Josselin Mouette]

Le mardi 13 mai 2014 à 22:46 +0100, David Goodenough a écrit :
> Does bash-completion work when the command is sudo not service?

Yes.

-- 
 .''`.  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/1400018843.4735.3.ca...@kagura.malsain.org

Re: systemd-fsck?

[David Goodenough]

On Tuesday 13 May 2014 21:09:14 Salvo Tomaselli wrote:
> In data martedì 13 maggio 2014 19:42:32, David Goodenough ha scritto:
> > > service foo  works across Linux distributions, with or without
> > > systemd, and does the right thing.
> > 
> > The big shame with service is that tab completion does not work properly.
> > If I use /etc/init.d/ then tab tells me what is there and spells it right.
> 
> You should install bash-completion
Does bash-completion work when the command is sudo not service?  Never seems
to for me.  I never log in as root, I always do root things using sudo.

David


--
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/2558668.ZfZG2MVDSV@stargate

Re: systemd-fsck?

[Thorsten Glaser]

Steve Langasek dixit:

>On Tue, May 13, 2014 at 08:23:55PM +, Thorsten Glaser wrote:
>> >service foo  works across Linux distributions, with or without
>> >systemd, and does the right thing.
>
>> It doesn’t work on lenny, and (unless service /etc/init.d/foo is
>> allowed) does not tabcomplete well (in all scenarios).
>
>Lots of things don't work on a Debian release that *stopped being supported

Yes, but we *are* talking about “enterprise” use in this thread.
This is not the only old thing people use (ours and others), and
lenny is definitely less smelly than some others.

(I recently had to install a _new_ lenny system. It was necessary.)

bye,
//mirabilos
-- 
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh").  [aus dasr]


--
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/pine.bsm.4.64l.1405132110240.23...@herc.mirbsd.org

Re: systemd-fsck?

[Steve Langasek]

On Tue, May 13, 2014 at 08:23:55PM +, Thorsten Glaser wrote:
> >service foo  works across Linux distributions, with or without
> >systemd, and does the right thing.

> It doesn’t work on lenny, and (unless service /etc/init.d/foo is
> allowed) does not tabcomplete well (in all scenarios).

Lots of things don't work on a Debian release that *stopped being supported
two years ago*.

-- 
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

Upgrade troubles with Perl (was: systemd-fsck?)

[gregor herrmann]

On Tue, 13 May 2014 18:57:03 +0200, Thijs Kinkhorst wrote:

> I could not agree more. In our enterprise environment, I have no
> expectation at all that systemd will cause us significant trouble on
> upgrades. Our troubles have centered things like grub1 to grub2 or,
> indeed, new PHP and Perl versions, and I find it very likely that the
> upgrade to jessie will again be around that and not at all around the init
> system.

Out of curiosity: I've experienced fun with new PHP versions as well
but I don't remember anything serious with Perl updates (I might be
biased a bit ...).

Which kind of problems did you see with new Perl versions (I could
imagine incompatible old third-party software), and is there
something the Debian perl maintainers and/or the Debian Perl Group
can do to improve the situation?


Cheers,
gregor, cc'ing debian-perl and suggesting to move the sub-thread
there

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Peter Jones: Love Is A Battle Field


signature.asc
Description: Digital Signature

Re: systemd-fsck?

[Thorsten Glaser]

Thibaut Paumard dixit:

>People who run testing or unstable should be prepared to deal with
>occasional breakages.

With occasional *temporary* breakages, such as packages disappearing
(in testing) or needing to be set on “hold” temporarily, yes.

With the init system suddenly be swapped out under one’s arse, no.

bye,
//mirabilos
-- 
“When udev happened I wrote mdev.”
-- Rob Landley in http://www.landley.net/notes.html#23-04-2014
Although I am proud to be an enemy of systemd, myself.  --mirabilos
And CVS does not need replacing. (git’s got different use cases.)


--
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/pine.bsm.4.64l.1405132029460.23...@herc.mirbsd.org

Re: systemd-fsck?

[Thorsten Glaser]

Russ Allbery dixit:

>> • no /etc/init.d/$foo (to tabcomplete, no less!) any more
>
>I've been telling people to stop using this for years.  You should stop
>using this too, regardless of what init system you're using, since it
>doesn't sanitize environment variables.  You leak all kinds of crap from

Right, see my other posting (the “cleanenv” script).

>service foo  works across Linux distributions, with or without
>systemd, and does the right thing.

It doesn’t work on lenny, and (unless service /etc/init.d/foo is
allowed) does not tabcomplete well (in all scenarios).

>> • journal
>
>With the default systemd configuration on Debian, you won't ever know this
>exists unless you use one of the features that takes advantage of it.
>There's literally nothing to adjust to, so yes, of course they'll cope.

OK. But who says this is to stay? The systemd developers are
hostile towards legacy stuff in a really intricate way. Take
not jornal here but something else as example: they support
running both ntpd and their own thing, to sweeten the deal
now, but plan on dropping ntpd support later:
http://www.ohloh.net/p/systemd/commits/335063290

>> • the init system breaking init scripts hand-written by people
>>   who don’t really know what they’re doing, have not even heard
>>   of LSB, much less “units”
>
>This was indeed a more difficult transition... which we already did years
>ago when we switched to dependency-based boot.  Which did cause people a
>fair bit of trouble.  But it's now been handled, and systemd is unlikely
>to make any remaining issues any worse.

It’s not fully handled everywhere yet.


Thijs Kinkhorst dixit:

>One thing that strikes me in your mail is the underlying sentiment that 
>enterprise admins would be averse of change. Environments and technologies 

Fun thing: ours are. I wish we had IPv6… I used to run a BSD VM that
was a tunnel endpoint and just announced it into our LAN, but now that
we have separate admin areas, firewalls deny by default, etc. this is
no longer allowed. Some do investigate ceph, but even changing from
tomcat5.5 to tomcat6 is hard, tomcat7 does not work everywhere, and
developers don’t cooperate here either (I’m still trying to get all
java5 and java6 installs removed), though they all want maven 3.x…

Just don’t assume all installations are equal, nor that all people
who run them share the equal mindset. (We’re rid of etch for a few
months, and dapper and sarge for a few months more, thank the gods…)

bye,
//mirabilos
-- 
“When udev happened I wrote mdev.”
-- Rob Landley in http://www.landley.net/notes.html#23-04-2014
Although I am proud to be an enemy of systemd, myself.  --mirabilos
And CVS does not need replacing. (git’s got different use cases.)


--
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/pine.bsm.4.64l.1405132014150.23...@herc.mirbsd.org

Re: systemd-fsck?

[Thibaut Paumard]

Le 13/05/2014 19:38, Thorsten Glaser a écrit :
> Cyril Brulebois dixit:
> 
>> The sad thing is: almost nobody reads the release notes.
> 
> Many people run testing or unstable, so there are no “release”s
> to have notes for, either… (but yes, even those who run stable
> don’t).

People who run testing or unstable should be prepared to deal with
occasional breakages. I do hope admins who upgrade remote, inaccessible
servers do read the release notes.

Kind regards, Thibaut.



signature.asc
Description: OpenPGP digital signature

Re: systemd-fsck?

[Christian Hofstaedtler]

* Russ Allbery  [140513 18:21]:
> > We would be wise to make the last non-systemd release an LTS one so that
> > enterprise users can stay on that release until the systems these
> > installations run are retired.
> 
> You're aware, right, that my primary background is with enterprise use,
> and I've been doing large-site systems administration for twenty years?
> 
> systemd is a godsend with basically no downside for our enterprise use
> cases.  I expect almost no problems across our entire environment, plus,
> as a bonus, the opportunity to replace a bunch of homegrown hacks and
> obscure approaches (such as all our lingering use of daemontools) with
> something supportable, maintainable, and much better-documented.
> 
> Upgrading to systemd will be less painful than the sorts of things that we
> have to do with every Debian upgrade.  Particularly PHP changes, which
> always result in at least some heartburn.  It will also be much less
> painful than the Apache 2.4 transition (which I'm also really looking
> forward to, but which will involve way more work for us) and moving to
> Puppet 3.x.  Compared to those, the minor bits of fiddling required to
> make sure systemd works properly is noise.

I agree with all of this 100%.

Figuring out the required changes for UUID names, new HP device names,
the grub1 -> grub2 migration, insserv/dependency based boot, and, as
much as I've seen so far, the switch to systemd as init -- all of this
is just noise, esp. in an enterprise environment where you already
support multiple distributions, which today already ship with different
init systems which are "incompatible" with each other.

Or, to name it in a different way: all those changes are small one
time costs, and sysadmins alreay deal with such things in a mostly
trivial way.

The real issues in an enterprise environment are way higher in the
stack.

I'm also looking forward to systemd to replace various local hacks
(@reboot anyone?), similar to what Russ already said above.

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



pgpz6i7Cm9IIo.pgp
Description: PGP signature

Re: systemd-fsck?

[Thijs Kinkhorst]

Op dinsdag 13 mei 2014 19:36:35 schreef Thorsten Glaser:
> Thijs Kinkhorst dixit:
> >I could not agree more. In our enterprise environment, I have no
> >expectation at all that systemd will cause us significant trouble on
> >upgrades. Our troubles have centered things like grub1 to grub2 or,
> 
> Yes, there were issues with e.g. grub1 to grub2, but do you honestly
> think that sysadmins in a medium-sized company will cope with these?

Yes! No problem.

> • no /etc/init.d/$foo (to tabcomplete, no less!) any more
> • journal
> • totally different ways to handle services
> • totally different ways to rescue a system that does not boot
>   cleanly any more
> • the init system breaking init scripts hand-written by people
>   who don’t really know what they’re doing, have not even heard
>   of LSB, much less “units”

We're already in the habit of using "service $foo start", because you do not 
want the nl_NL locale of the sysadmin starting Tomcat to leak into the app 
it's running. Our admins are very versed at working with rsyslog, which will 
still be there, so I expect no problems. We indeed discovered some half-baked 
init scripts in the dependency based boot transition, which proved to be an 
excellent opportunity to actually fix those up and we were better off after.

> I’m *positive* they won’t.

One thing that strikes me in your mail is the underlying sentiment that 
enterprise admins would be averse of change. Environments and technologies 
around us are changing constantly, and at our job we need to cope with such 
things as a new backup solution, changed network policies, rolling out IPv6, 
virtualizating systems, changing from one virtualization to another and then 
another, investigating ceph, building a DNSSEC-enabled DNS infrastructure, 
changing insights in SSL protocols and ciphers, or even just in-Debian changes 
like a new Django release or moving from Tomcat 6 to Tomcat 7. Something will 
probably change for us admins when systemd comes, although I doubt it will be 
as major as you imagine. Nonetheless, our admins are very well equipped to 
cope with something changing or working differently than it did before.


Cheers,
Thijs


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

Re: systemd-fsck?

[Steve Langasek]

On Tue, May 13, 2014 at 07:42:32PM +0100, David Goodenough wrote:

> > service foo  works across Linux distributions, with or without
> > systemd, and does the right thing.
> The big shame with service is that tab completion does not work properly.
> If I use /etc/init.d/ then tab tells me what is there and spells it right.

The bash-completion package knows how to complete arguments to 'service'.
If you use a different login shell, there's probably an equivalent.  In any
case, we shouldn't let ourselves be held back from improving our interfaces
simply because historically the interface was one that happened to be
compatible with filesystem-based tab completion implementations.

-- 
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-fsck?

[Michael Biebl]

Am 13.05.2014 20:42, schrieb David Goodenough:
> On Tuesday 13 May 2014 11:06:10 Russ Allbery wrote:

>> service foo  works across Linux distributions, with or without
>> systemd, and does the right thing.
> The big shame with service is that tab completion does not work properly.
> If I use /etc/init.d/ then tab tells me what is there and spells it right.

Might I suggest bash-completion here:
service  or
systemctl 
works just fine with bash-completion enabled.

At least for systemd, we also have completion support for zsh.

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-fsck?

[Salvo Tomaselli]

In data martedì 13 maggio 2014 19:42:32, David Goodenough ha scritto:

> > service foo  works across Linux distributions, with or without
> > systemd, and does the right thing.
> 
> The big shame with service is that tab completion does not work properly.
> If I use /etc/init.d/ then tab tells me what is there and spells it right.

You should install bash-completion

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/


--
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/2033473.pXqKuMbjij@hal9000

Re: systemd-fsck?

[Adam D. Barratt]

On Tue, 2014-05-13 at 19:42 +0100, David Goodenough wrote:
> On Tuesday 13 May 2014 11:06:10 Russ Allbery wrote:
> > service foo  works across Linux distributions, with or without
> > systemd, and does the right thing.
> The big shame with service is that tab completion does not work properly.

In what way does it not work?

adam@wheezy:~$ service 
acpid   checkroot-bootclean.sh  hdapsd  motd
pulseaudio  speech-dispatcher
acpi-fakekeycheckroot.shhdparm  
mountall-bootclean.sh   rc  stop-bootlogd
acpi-supportconsole-setup   hostname.sh 
mountall.sh rc.localstop-bootlogd-single
alsa-utils  cpufrequtilshwclock.sh  
mountdevsubfs.shrcS sudo
anacron cronkbd 
mountkernfs.sh  README  thinkfan
apmdcryptdisks  kerneloops  
mountnfs-bootclean.sh   reboot  udev
atd cryptdisks-earlykeyboard-setup  
mountnfs.sh rmnologin   udev-mtab
avahi-daemoncupskillprocs   mtab.sh 
rpcbind umountfs
binfmt-support  dbuskmod
networking  rsync   umountnfs.sh
bluetooth   exim4   libvirt-bin 
network-manager rsyslog umountroot
bootlogdfancontrol  libvirt-guests  
nfs-common  saned   unattended-upgrades
bootlogsfuselm-sensors  openvpn 
sendsigsurandom
bootmisc.sh gdm3loadcpufreq 
pppd-dnssingle  x11-common
checkfs.sh  haltminissdpd   procps  
skeleton
adam@wheezy:~$ service f
fancontrol  fuse
adam@wheezy:~$ service f

(It could do with skipping non-executable scripts, but...)

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/148098.4567.26.ca...@jacala.jungle.funky-badger.org

Re: systemd-fsck?

[Clint Adams]

On Tue, May 13, 2014 at 07:42:32PM +0100, David Goodenough wrote:
> The big shame with service is that tab completion does not work properly.
> If I use /etc/init.d/ then tab tells me what is there and spells it right.

Sounds like maybe you need a better shell.


-- 
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/20140513190119.ga10...@scru.org

Re: systemd-fsck?

[David Goodenough]

On Tuesday 13 May 2014 11:06:10 Russ Allbery wrote:
> Thorsten Glaser  writes:
> > Yes, there were issues with e.g. grub1 to grub2, but do you honestly
> > think that sysadmins in a medium-sized company will cope with these?
> > 
> > • no /etc/init.d/$foo (to tabcomplete, no less!) any more
> 
> I've been telling people to stop using this for years.  You should stop
> using this too, regardless of what init system you're using, since it
> doesn't sanitize environment variables.  You leak all kinds of crap from
> your personal shell environment into the daemon environment that can cause
> mysterious and difficult-to-debug problems.
> 
> service foo  works across Linux distributions, with or without
> systemd, and does the right thing.
The big shame with service is that tab completion does not work properly.
If I use /etc/init.d/ then tab tells me what is there and spells it right.

David
> 
> > • journal
> 
> With the default systemd configuration on Debian, you won't ever know this
> exists unless you use one of the features that takes advantage of it.
> There's literally nothing to adjust to, so yes, of course they'll cope.
> 
> > • totally different ways to handle services
> 
> In that way in which what you're doing now continues to work and you can
> use the new stuff when you feel like it.
> 
> > • totally different ways to rescue a system that does not boot
> > 
> >   cleanly any more
> 
> In that way in which booting from the rescue entry in Grub continues to
> work just the way that it does right now.
> 
> > • the init system breaking init scripts hand-written by people
> > 
> >   who don’t really know what they’re doing, have not even heard
> >   of LSB, much less “units”
> 
> This was indeed a more difficult transition... which we already did years
> ago when we switched to dependency-based boot.  Which did cause people a
> fair bit of trouble.  But it's now been handled, and systemd is unlikely
> to make any remaining issues any worse.
> 
> > I’m *positive* they won’t.
> 
> Good thing most of the problems you're worried about are figments of your
> imagination, then, huh?


--
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/3214916.OKkfycKpZM@stargate

Re: systemd-fsck?

[Russ Allbery]

Thorsten Glaser  writes:

> Yes, there were issues with e.g. grub1 to grub2, but do you honestly
> think that sysadmins in a medium-sized company will cope with these?

> • no /etc/init.d/$foo (to tabcomplete, no less!) any more

I've been telling people to stop using this for years.  You should stop
using this too, regardless of what init system you're using, since it
doesn't sanitize environment variables.  You leak all kinds of crap from
your personal shell environment into the daemon environment that can cause
mysterious and difficult-to-debug problems.

service foo  works across Linux distributions, with or without
systemd, and does the right thing.

> • journal

With the default systemd configuration on Debian, you won't ever know this
exists unless you use one of the features that takes advantage of it.
There's literally nothing to adjust to, so yes, of course they'll cope.

> • totally different ways to handle services

In that way in which what you're doing now continues to work and you can
use the new stuff when you feel like it.

> • totally different ways to rescue a system that does not boot
>   cleanly any more

In that way in which booting from the rescue entry in Grub continues to
work just the way that it does right now.

> • the init system breaking init scripts hand-written by people
>   who don’t really know what they’re doing, have not even heard
>   of LSB, much less “units”

This was indeed a more difficult transition... which we already did years
ago when we switched to dependency-based boot.  Which did cause people a
fair bit of trouble.  But it's now been handled, and systemd is unlikely
to make any remaining issues any worse.

> I’m *positive* they won’t.

Good thing most of the problems you're worried about are figments of your
imagination, then, huh?

-- 
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/87tx8ttuy5@windlord.stanford.edu

Re: systemd-fsck?

[Cyril Brulebois]

Thorsten Glaser  (2014-05-13):
> (But it was nice to have a published list of those people who maybe
> could accidentally be hit by a tactical small-bus…)

That's absolutely shocking and intolerable.

KiBi.


signature.asc
Description: Digital signature

Re: systemd-fsck?

[Thorsten Glaser]

Thijs Kinkhorst dixit:

>On Tue, May 13, 2014 18:03, Russ Allbery wrote:

>> You're aware, right, that my primary background is with enterprise use,
>> and I've been doing large-site systems administration for twenty years?
>>
>> systemd is a godsend with basically no downside for our enterprise use
[…]
>I could not agree more. In our enterprise environment, I have no
>expectation at all that systemd will cause us significant trouble on
>upgrades. Our troubles have centered things like grub1 to grub2 or,

Yes, there were issues with e.g. grub1 to grub2, but do you honestly
think that sysadmins in a medium-sized company will cope with these?

• no /etc/init.d/$foo (to tabcomplete, no less!) any more

• journal

• totally different ways to handle services

• totally different ways to rescue a system that does not boot
  cleanly any more

• the init system breaking init scripts hand-written by people
  who don’t really know what they’re doing, have not even heard
  of LSB, much less “units”

I’m *positive* they won’t.

bye,
//mirabilos
-- 
“When udev happened I wrote mdev.”
-- Rob Landley in http://www.landley.net/notes.html#23-04-2014
Although I am proud to be an enemy of systemd, myself.  --mirabilos
And CVS does not need replacing. (git’s got different use cases.)


--
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/pine.bsm.4.64l.1405131734280.23...@herc.mirbsd.org

Re: systemd-fsck?

[Thorsten Glaser]

Cyril Brulebois dixit:

>The sad thing is: almost nobody reads the release notes.

Many people run testing or unstable, so there are no “release”s
to have notes for, either… (but yes, even those who run stable
don’t).

bye,
//mirabilos
-- 
“When udev happened I wrote mdev.”
-- Rob Landley in http://www.landley.net/notes.html#23-04-2014
Although I am proud to be an enemy of systemd, myself.  --mirabilos
And CVS does not need replacing. (git’s got different use cases.)


--
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/pine.bsm.4.64l.1405131738020.23...@herc.mirbsd.org

Re: systemd-fsck?

[Thorsten Glaser]

Didier 'OdyX' Raboud dixit:

>Le mardi, 13 mai 2014, 16.25:31 Thorsten Glaser a écrit :

>> On Mon, 12 May 2014, Tollef Fog Heen wrote:

>> > Are you aware that Joss isn't a systemd maintainer?  (He's one of
>> > the GNOME maintainers.)
>> 
>> There’s not really a line between them, you know. (But it was

>On top of your first sentence being factually wrong (check the 
>maintainer fields of the respective packages), I really think your 

I *know* that the people listed as maintainers of the respective
Debian packages, and the people listed as developers of the
respective upstreams, are not identical. What I was saying with
“There’s not really a line between them” relates to how they act
and what they propose, and, to a far greater amount, to how someone
from outside their “circles” perceives them (I’m by far not alone
in that).

bye,
//mirabilos (not suggesting, merely smiling at the idea)
-- 
“When udev happened I wrote mdev.”
-- Rob Landley in http://www.landley.net/notes.html#23-04-2014
Although I am proud to be an enemy of systemd, myself.  --mirabilos
And CVS does not need replacing. (git’s got different use cases.)


--
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/pine.bsm.4.64l.1405131718590.23...@herc.mirbsd.org

Re: systemd-fsck?

[Cyril Brulebois]

Thibaut Paumard  (2014-05-13):
> Le 13/05/2014 17:36, Russ Allbery a écrit :
> > Right, which I've been arguing for already in this thread.  I don't think
> > we should force this on upgrades.  There should be a prompt and an
> > opportunity to not change init systems.
> 
> Instead of or in addition to such prompting, I expect this switch will
> be documented in the Release Notes so that people who really care are
> aware of the risks and the cases which are known to break.

The sad thing is: almost nobody reads the release notes.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: systemd-fsck?

[Don Armstrong]

On Tue, 13 May 2014, Thorsten Glaser wrote:
> (But it was nice to have a published list of those people who maybe
> could accidentally be hit by a tactical small-bus…)

This is absolutely inappropriate and has no place on a Debian mailing
list or anywhere else. Please retract this statement.

-- 
Don Armstrong  http://www.donarmstrong.com

I have no use for "before and after" pictures.
I can't remember starting, and I'm never done.
 -- a softer world #221
http://www.asofterworld.com/index.php?id=221


-- 
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/20140513171324.gu13...@teltox.donarmstrong.com

Re: systemd-fsck?

[Stephen Frost]

* Thorsten Glaser (t...@mirbsd.org) wrote:
> (But it was
> nice to have a published list of those people who maybe could
> accidentally be hit by a tactical small-bus…)

These comments are not necessary nor appropriate, ever.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: systemd-fsck?

[Thibaut Paumard]

Hi,

Le 13/05/2014 17:36, Russ Allbery a écrit :
> Right, which I've been arguing for already in this thread.  I don't think
> we should force this on upgrades.  There should be a prompt and an
> opportunity to not change init systems.

Instead of or in addition to such prompting, I expect this switch will
be documented in the Release Notes so that people who really care are
aware of the risks and the cases which are known to break.

Just my 2c.

Kind regards, Thibaut.





signature.asc
Description: OpenPGP digital signature

Re: systemd-fsck?

[Thijs Kinkhorst]

On Tue, May 13, 2014 18:03, Russ Allbery wrote:
>
>> The update to the first Debian stable release running systemd will most
>> probably be the most painful update Debian has ever had since switching
>> to glibc (which was well before I started using Linux).
>
> I highly doubt it.
>
>> We would be wise to make the last non-systemd release an LTS one so that
>> enterprise users can stay on that release until the systems these
>> installations run are retired.
>
> You're aware, right, that my primary background is with enterprise use,
> and I've been doing large-site systems administration for twenty years?
>
> systemd is a godsend with basically no downside for our enterprise use
> cases.  I expect almost no problems across our entire environment, plus,
> as a bonus, the opportunity to replace a bunch of homegrown hacks and
> obscure approaches (such as all our lingering use of daemontools) with
> something supportable, maintainable, and much better-documented.
>
> Upgrading to systemd will be less painful than the sorts of things that we
> have to do with every Debian upgrade.  Particularly PHP changes, which
> always result in at least some heartburn.  It will also be much less
> painful than the Apache 2.4 transition (which I'm also really looking
> forward to, but which will involve way more work for us) and moving to
> Puppet 3.x.  Compared to those, the minor bits of fiddling required to
> make sure systemd works properly is noise.

I could not agree more. In our enterprise environment, I have no
expectation at all that systemd will cause us significant trouble on
upgrades. Our troubles have centered things like grub1 to grub2 or,
indeed, new PHP and Perl versions, and I find it very likely that the
upgrade to jessie will again be around that and not at all around the init
system.


Cheers,
Thijs


-- 
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/feba9b47fd4b0d80ce3ccc7faa3f237e.squir...@aphrodite.kinkhorst.nl

Re: systemd-fsck?

[Russ Allbery]

Thorsten Glaser  writes:
> On Mon, 12 May 2014, Tollef Fog Heen wrote:

>> Are you aware that Joss isn't a systemd maintainer?  (He's one of the
>> GNOME maintainers.)

> There’s not really a line between them, you know. (But it was nice to
> have a published list of those people who maybe could accidentally be
> hit by a tactical small-bus…)

Wow.

Did you really just say that?

> I find it absolutely appalling that you, a systemd apologist, have such
> an eMail signature, since systemd is violating the spirit of UNIX and
> aiming to replace it with FLOS.

If you can't cope with the idea that there are other smart people in the
world who have access to all of the same data that you have and yet come
to different conclusions that you come to, you're in for a very
frustrating and difficult time.

-- 
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/87mwelvd3c@windlord.stanford.edu

Re: systemd-fsck?

[Russ Allbery]

Apologies for the last few mangled messages with bad attributions or
character sets.  Emacs 24 didn't like its header and body separator
overridden (it thought my separator was a continuation line of a previous
header), which caused subtle problems with mail sending until I figured
out what was going on.  It should be fixed now (although I'm having to get
used to the ugly "--text follows this line--" marker again).

-- 
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/87wqdpve91@windlord.stanford.edu

Re: systemd-fsck?

[Thorsten Glaser]

On Mon, 12 May 2014, Tollef Fog Heen wrote:

> ]] Andrew Shadura

> > This sort of behaviour is precisely why so many people not only
> > dislike systemd, but also it's maintainers.
>
> Are you aware that Joss isn't a systemd maintainer?  (He's one of the
> GNOME maintainers.)

There’s not really a line between them, you know. (But it was
nice to have a published list of those people who maybe could
accidentally be hit by a tactical small-bus…)

> UNIX is user friendly, it's just picky about who its friends are

I find it absolutely appalling that you, a systemd apologist,
have such an eMail signature, since systemd is violating the
spirit of UNIX and aiming to replace it with FLOS.


On Tue, 13 May 2014, Marc Haber wrote:

> This sort of behavior is precisely why many users are migrating away
> from Debian.

Right – but where to?

Maybe we shouldn’t make “the last version before systemd” an LTS
(it would probably end up being wheezy anyway, which enterprise
users already switched away from, by now, as I’ve given up believing
being able to install jessie from scratch without it), but fork
Debian, take with us as many developers as possible, and leave
the systemd people to be a separate distro.

bye,
//mirabilos, not ashamed
-- 
“When udev happened I wrote mdev.”
-- Rob Landley in http://www.landley.net/notes.html#23-04-2014
Although I am proud to be an enemy of systemd, myself.  --mirabilos
And CVS does not need replacing. (git’s got different use cases.)


--
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/alpine.deb.2.10.1405131622000.23...@tglase.lan.tarent.de

Re: systemd-fsck?

[Russ Allbery]

> The update to the first Debian stable release running systemd will most
> probably be the most painful update Debian has ever had since switching
> to glibc (which was well before I started using Linux).

I highly doubt it.

> We would be wise to make the last non-systemd release an LTS one so that
> enterprise users can stay on that release until the systems these
> installations run are retired.

You're aware, right, that my primary background is with enterprise use,
and I've been doing large-site systems administration for twenty years?

systemd is a godsend with basically no downside for our enterprise use
cases.  I expect almost no problems across our entire environment, plus,
as a bonus, the opportunity to replace a bunch of homegrown hacks and
obscure approaches (such as all our lingering use of daemontools) with
something supportable, maintainable, and much better-documented.

Upgrading to systemd will be less painful than the sorts of things that we
have to do with every Debian upgrade.  Particularly PHP changes, which
always result in at least some heartburn.  It will also be much less
painful than the Apache 2.4 transition (which I'm also really looking
forward to, but which will involve way more work for us) and moving to
Puppet 3.x.  Compared to those, the minor bits of fiddling required to
make sure systemd works properly is noise.

-- 
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/87fvkdzmw6@windlord.stanford.edu

Re: systemd-fsck?

[Russ Allbery]

> Matthias Urlichs  wrote:

>> In theory, yes you could discover whether a package was installed
>> explicity or has been pulled in as a dependency.

>> In practice, however, a "normal" Debian installation marks each and
>> every package as being installed explicitly.

> ? huh ? This has never been the case AFAICT. That's how apt-get
> autoremove works. Each package you specify on an individual apt-get
> install line gets marked as manually installed - the dependencies of
> those are not so marked.

I think you missed the "installation" part, and Matthias is talking about
the behavior of d-i.

-- 
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/87k39pzn55@windlord.stanford.edu

Re: systemd-fsck?

[Russ Allbery]

> How difficult would it be, for the sake of compatibility if nothing
> else, to teach su not to create a new PAM session when it doesn't
> already run within one?

You don't want to do that in general since that defeats the primary
purpose of su: creating a new session as a different user.

It's sort of an interesting question as to whether you want to set up a
new session when running a single command.  I'm a little surprised that su
does this as opposed to only calling setcred.

-- 
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/87oaz1znhv@windlord.stanford.edu

Re: systemd-fsck?

[Russ Allbery]

> On Mon, May 12, 2014 at 07:01:14PM -0700, Russ Allbery wrote:

>> Dependency-based boot, the change to /bin/sh, and UUID-based mounting
>> were all not drop-in replacements by that criteria.

> Note that also none of them were forced on existing installations.  The
> change of /bin/sh to dash (which is what you mean, I presume?) featured
> a debconf prompt which IIRC defaulted to "continue using bash", the
> other two were added in d-i and existing installations were not touched,
> AFAIR.

Right, which I've been arguing for already in this thread.  I don't think
we should force this on upgrades.  There should be a prompt and an
opportunity to not change init systems.

It remains to be seen if we will ship some software with jessie that
requires systemd be running as the init system, or if people will have the
time and resources to provide the necessary interfaces with sysvinit or
other init systems.  I certainly hope the latter is the case, and Steve
felt quite confident it would be, but the work hasn't happened yet, so we
can't be sure we won't end up in that situation.  If that's the case, then
some software may not work if you choose not to run systemd.  But we
should still prompt and not change without the user's permission.

-- 
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/87siodzo56@windlord.stanford.edu

Re: systemd-fsck?

[Vincent Bernat]

 ❦ 13 mai 2014 15:01 +0200, Marc Haber  :

>>Thank you so much for volunteering to contribute to GNOME packaging and
>>to make it work on configurations nobody will actually ever use.
>>
>>We are eagerly waiting for your patches.
>
> This sort of behavior is precisely why many users are migrating away
> from Debian.

Could you please stop FUD? Do you have some reference for this claim?
-- 
Avoid multiple exits from loops.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: systemd-fsck?

[Thorsten Glaser]

On Tue, 13 May 2014, Josselin Mouette wrote:

> My opinion is that many users are migrating away from Debian because we
> are unable to make decisions on important technical topics and leave
> them with 3 different setups, none of which actually work, instead of
> providing one that is correctly polished.

That’s precisely the GNOME 3 attitude (“no themes allowed in GTK+3”,
“our way or the highway”). I’m not surprised it’s also systemd’s, and
yours.

And I say you’re wrong. This does not belong into Debian itself. This
is a perfectly fine job for a derivate or Pure Blend: to provide a
polished system that serves one use case well.

Debian is the Universal OS, which means it provides high customisability
for people who want to choose their use cases themselves, and for those
whose use cases may differ from these of GNOME 3 developers.

bye,
//mirabilos, wearing DD hat in this eMail
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!


--
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/alpine.deb.2.10.1405131629280.2...@tglase.lan.tarent.de

Re: systemd-fsck?

[Josselin Mouette]

Le mardi 13 mai 2014 à 15:01 +0200, Marc Haber a écrit : 
> This sort of behavior is precisely why many users are migrating away
> from Debian.

You are entitled to think that users make decisions on the alleged
behavior of people they never heard of.

My opinion is that many users are migrating away from Debian because we
are unable to make decisions on important technical topics and leave
them with 3 different setups, none of which actually work, instead of
providing one that is correctly polished.

-- 
 .''`.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/1399989341.5437.964.camel@dsp0698014

Re: systemd-fsck?

[Marc Haber]

On Mon, 12 May 2014 21:16:49 +0200, Bas Wijnen 
wrote:
>I, as a user, did not expect to be moved over to systemd, and given the
>discussions about it and the older TC decisions about network manager getting
>its dependencies right (to stop forcing all of gnome onto the user's system),
>it felt to me as something that was sneaked past me.  I don't want Debian to do
>that.  I don't really care about what init system I use, but I do care that I
>can trust my system. 

+1

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1wkctl-0004wd...@swivel.zugschlus.de

Re: systemd-fsck?

[Matthias Klumpp]

2014-05-13 15:01 GMT+02:00 Marc Haber :
> On Mon, 12 May 2014 13:58:31 +0200, Josselin Mouette 
> wrote:
>>Le lundi 12 mai 2014 à 12:16 +0200, Andrew Shadura a écrit :
>>> > As far as GDM is concerned, any bug reported with systemd-shim installed
>>> > will be ignored. The bug script should probably be updated to that
>>> > effect, BTW.
>>>
>>> This sort of behaviour is precisely why so many people not only
>>> dislike systemd, but also it's maintainers.
>>
>>Thank you so much for volunteering to contribute to GNOME packaging and
>>to make it work on configurations nobody will actually ever use.
>>
>>We are eagerly waiting for your patches.
>
> This sort of behavior is precisely why many users are migrating away
> from Debian.
While the "nobody will actually ever use" can hardly be called
"deescalating", admittedly, in the matter Joss is absolutely right:
Better spend the limited time we as volunteers have to support one
thing best, instead of having multiple half-baked solutions, like
"GNOME support 4 init-systems, unfortunately session management
doesn't work properly on any of them".
If you want an additional configuration to be supported, where nobody
is working on yet, you should commit to maintaining it. If there is a
huge group of people who *want* that feature to happen, it will happen
and it will get all the manpower it needs.
And I am pretty sure Joss wouldn't block properly maintained patches
for alternative configurations (as long as they don't lead to problems
in the default configuration). In the same way, nobody will (and
should) block properly maintainer upstart/sysvinit/systemd units.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


--
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/caknhny8bgxzgv4em8zgl5aqrpbh9cj3i4_gr2p_i30q6sgc...@mail.gmail.com

Re: systemd-fsck?

[Marc Haber]

On Mon, 12 May 2014 13:35:15 +0200, Tollef Fog Heen 
wrote:
>> On 12 May 2014 11:54, Josselin Mouette  wrote:
>> > Systemd is the default init system for jessie, and it should be listed
>> > as the first alternative. The fact that an alternative codepath exists
>> > for users with specific needs is nice for them, but it is not what we
>> > should focus our efforts on.
>> 
>> > As far as GDM is concerned, any bug reported with systemd-shim installed
>> > will be ignored. The bug script should probably be updated to that
>> > effect, BTW.
>> 
>> This sort of behaviour is precisely why so many people not only
>> dislike systemd, but also it's maintainers.
>
>Are you aware that Joss isn't a systemd maintainer?  (He's one of the
>GNOME maintainers.)

He is undoubtedly one of the less polite Debian people. This hurts the
distribution, its users, and open source.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1wkckl-0004lu...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Mon, 12 May 2014 13:58:31 +0200, Josselin Mouette 
wrote:
>Le lundi 12 mai 2014 à 12:16 +0200, Andrew Shadura a écrit : 
>> > As far as GDM is concerned, any bug reported with systemd-shim installed
>> > will be ignored. The bug script should probably be updated to that
>> > effect, BTW.
>> 
>> This sort of behaviour is precisely why so many people not only
>> dislike systemd, but also it's maintainers.
>
>Thank you so much for volunteering to contribute to GNOME packaging and
>to make it work on configurations nobody will actually ever use.
>
>We are eagerly waiting for your patches.

This sort of behavior is precisely why many users are migrating away
from Debian.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1wkckl-0004li...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Mon, 12 May 2014 19:01:14 -0700, Russ Allbery 
wrote:
>Dependency-based boot, the change to /bin/sh, and UUID-based mounting were
>all not drop-in replacements by that criteria.

The update to the first Debian stable release running systemd will
most probably be the most painful update Debian has ever had since
switching to glibc (which was well before I started using Linux).

We would be wise to make the last non-systemd release an LTS one so
that enterprise users can stay on that release until the systems these
installations run are retired.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1wkcj4-0004l8...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sun, 11 May 2014 22:34:47 -0700, Steve Langasek 
wrote:
>On Sun, May 11, 2014 at 09:10:21AM +0200, Marc Haber wrote:
>> >> The plain fact:
>
>> >> Using systemd breaks something that worked for probably a decade or longer
>> >> before however long that su is in that init script.  So on what account do
>> >> you call calling "su" in an init script a bug?  It may not be the most
>> >> elegant solution to do things, granted, but a bug?  Come on.  Calling it a
>> >> bug just cause systemd / policykit treat calling su in an initscript as
>> >> they do is quite arrogant in my eyes.
>
>> >As the maintainer of the pam package in Debian, I assure you: this is a bug
>> >in dirmngr.  System services should not (must not) call interfaces that
>> >launch pam sessions as part of their init scripts.  su is one of those
>> >interfaces.
>
>> Is this documented anywhere, or is this only clear with detailed PAM
>> knowledge, which I have tried to build numerous times in the last ten
>> years and was never able due to (in my opinion) inadequate
>> documentation on the beginner level.
>
>It's not documented anywhere; it's an emergent property which is obvious if
>you understand the underlying design, but not something that was ever
>designed per se.  It might not be a bad idea to document it, though I'm not
>sure where the best place to do this would be.

Where is the underlying design explained?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1wkcfd-0004k9...@swivel.zugschlus.de

Re: systemd-fsck?

[Neil Williams]

On Tue, 13 May 2014 11:31:19 +0200
Matthias Urlichs  wrote:

> Hi,
> 
> Cameron Norman:
> > Is it not possible to tell if the sysvinit or upstart packages were
> > installed manually, and give a prompt then (in addition to
> > something like you described) ?
> > 
> In theory, yes you could discover whether a package was installed
> explicity or has been pulled in as a dependency.
>
> In practice, however, a "normal" Debian installation marks each and
> every package as being installed explicitly.

? huh ? This has never been the case AFAICT. That's how apt-get
autoremove works. Each package you specify on an individual apt-get
install line gets marked as manually installed - the dependencies of
those are not so marked. The marks can also be updated with apt-mark.
When the top-level package is removed, apt shows the packages which
were not manually installed in a list of packages which are potentially
suitable for autoremove.

> This may be a deficiency
> which we want to do something about, but doesn't help right now.

However, apt-mark status is probably not the answer to the original
question which needs to be based on what packages are currently
installed.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: systemd-fsck?

[Josselin Mouette]

Le lundi 12 mai 2014 à 11:42 -0700, Steve Langasek a écrit : 
> > As far as GDM is concerned, any bug reported with systemd-shim installed
> > will be ignored. The bug script should probably be updated to that
> > effect, BTW.
> 
> A better solution would be for you to step down as maintainer, since you
> clearly are not interested in proper integration of your packages with the
> rest of Debian.

If you really wish it so, I can write a script to automatically redirect
such bug reports to your mailbox. 

We have done the necessary steps for “proper integration” with your pet
package. It doesn’t mean anyone is interested in supporting it.

-- 
 .''`.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/1399975011.5437.921.camel@dsp0698014

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Cameron Norman:
> Is it not possible to tell if the sysvinit or upstart packages were
> installed manually, and give a prompt then (in addition to something like
> you described) ?
> 
In theory, yes you could discover whether a package was installed explicity
or has been pulled in as a dependency.

In practice, however, a "normal" Debian installation marks each and every
package as being installed explicitly. This may be a deficiency which we
want to do something about, but doesn't help right now.

-- 
-- 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/20140513093118.gg13...@smurf.noris.de

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Bas Wijnen:
> Sounds like those packages should conflict with each other.  It isn't a reason
> to uninstall anything.
> 
If you've used aptitude for any length of time, its affinity towards
uninstalling half of your system in favor of *any* other way to resolve
a conflict should not be surprising, systemd or not.

> I, as a user, did not expect to be moved over to systemd

I expect *users* to not care one way or another.
Their system booted quite well before systemd and it will boot, hopefully even
better otherwise this was all for nothing, afterwards.

I expect people who *really* do not want systemd to blacklist it,
by way of apt-preferences. Problem solved.

A mere re-ordering of dependencies in random packages will not accomplish
that; such re-ordering is also a disservice to that packages' maintainers
who use it to express *their* preference. Who says yours trumps theirs?

-- 
-- 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/20140513092723.gf13...@smurf.noris.de

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Steve Langasek:
> As the maintainer of the pam package in Debian, I assure you: this is a bug
> in dirmngr.  System services should not (must not) call interfaces that
> launch pam sessions as part of their init scripts.  su is one of those
> interfaces.
> 
How difficult would it be, for the sake of compatibility if nothing else,
to teach su not to create a new PAM session when it doesn't already run
within one?

… and … would we, as a project, actually _want_ to do that?

-- 
-- 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/20140513072228.ge13...@smurf.noris.de

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Kevin Chadwick:
> previously on this list Matthias Urlichs contributed:
> 
> > I haven't yet seen a system where booting with init=/bin/bash works but
> > booting systemd in emergency mode does not.
> 
> Have you added me to a killfile?

* Am I under some sort of obligation to read each and every message in this
  thread, or indeed on debian-devel?

* Are you capable of understanding what other people write?
  _I_ have not seen such a system.
  If I had, (a) I'd admit that and (b) I'd have tracked down the problem.

> I mentioned such a bug as happened in Arch testing in this very thread
> or do you mean a debian system?
> 
I'd be very interested in the cause of that bug, and presumably so do the
systemd maintainers. However, on my machines systemd's emergency mode
worked flawlessly every time I needed it.

(SysVinit's "single" mode, for the record, did not.)

> How it wasn't found before hitting testing beats me 

* Boot your system in emergency mode.
* It works.

How else would you test that?

-- 
-- 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/20140513071313.gd13...@smurf.noris.de

Re: systemd-fsck?

[Bas Wijnen]

On Mon, May 12, 2014 at 07:01:14PM -0700, Russ Allbery wrote:
> Dependency-based boot, the change to /bin/sh, and UUID-based mounting were
> all not drop-in replacements by that criteria.

Note that also none of them were forced on existing installations.  The change
of /bin/sh to dash (which is what you mean, I presume?) featured a debconf
prompt which IIRC defaulted to "continue using bash", the other two were added
in d-i and existing installations were not touched, AFAIR.

Thanks,
Bas


-- 
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/20140513055123.ga10...@fmf.nl

Re: systemd-fsck?

[Brian May]

On 13 May 2014 12:47, Norbert Preining  wrote:

> Yes, that is true, because at that time it was about booting with
> init=/bin/systemd
> and *not* about automatic upgrade to systemd without any checking back.
>

No, the title of the bug was changed to "systemd drops into emergency mode
if devices from /etc/fstab are missing".

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743265
-- 
Brian May 

Re: systemd-fsck?

[Norbert Preining]

> > If a device is not available but listed without "noauto" or "nofail"
> > in /etc/fstab, systemd drops into emergency mode.
> >
> 
> Maybe I am mistaken, however I thought this was standard behaviour for SYSV
> boot systems too

No, it is not standard behaviour. It warns you, but continues booting.

> That bug is closed and archived, BTW.

Yes, that is true, because at that time it was about booting with
init=/bin/systemd
and *not* about automatic upgrade to systemd without any checking back.

If a sysamd boots with init=/bin/systemd then he should know that
there might be troubles.

If he just made dist-upgrade and suddently the system does not boot,
then this is a different things.

So yes, should be unearthed.

Norbert


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/20140513024706.gh31...@auth.logic.tuwien.ac.at

Re: systemd-fsck?

[Norbert Preining]

On Mon, 12 May 2014, Russ Allbery wrote:
> In this case, maybe we can add some transitional smarts to the same
> package that takes responsibility for upgrade prompting.  What comes to
> mind is scanning /etc/fstab and look for filesystems that aren't set
> noauto or nofail but that aren't mounted and warn the user with debconf
> that behavior may change.

Good idea, agreed upon.

What I want to say: If we switch during an upgrade to systemd and
there is no warning and no asking, and then the system does not boot
anymore, sysadms could get quite angry.

sysv did allow it for many years, so we have to be careful here.

Norbert


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/20140513024503.gg31...@auth.logic.tuwien.ac.at

Re: systemd-fsck?

[Russ Allbery]

Norbert Preining  writes:

> This can happen on *any* server that has been booting happily since many
> many years. Thus, systemd is *not* a drop-in replacement for now.

We should be realistic about this: it's not going to be, either, at least
for a definition of drop-in replacement that involves no changes in
behavior.

Completely identical behavior is a very high bar that hasn't been met by
any other transition of this type that we've made in the past.
Dependency-based boot, the change to /bin/sh, and UUID-based mounting were
all not drop-in replacements by that criteria.  We *are* going to uncover
latent bugs in packages, in system configurations, and in other things,
and in some cases there will just be differences, which are not obviously
bugs anywhere.  We should do what we can to diagnose and fix or warn about
those, but we also shouldn't be surprised that they exist (and should let
users know via at least the release notes that this is a fairly
significant change to the boot process).

In this case, maybe we can add some transitional smarts to the same
package that takes responsibility for upgrade prompting.  What comes to
mind is scanning /etc/fstab and look for filesystems that aren't set
noauto or nofail but that aren't mounted and warn the user with debconf
that behavior may change.

-- 
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/87ppji8mj9@windlord.stanford.edu

Re: systemd-fsck?

[Brian May]

On 13 May 2014 11:11, Norbert Preining  wrote:

> #743265: systemd: booting with init=/bin/systemd drops into emergency mode
>
> If a device is not available but listed without "noauto" or "nofail"
> in /etc/fstab, systemd drops into emergency mode.
>

Maybe I am mistaken, however I thought this was standard behaviour for SYSV
boot systems too

That bug is closed and archived, BTW.
-- 
Brian May 

Re: systemd-fsck?

[Norbert Preining]

On Mon, 12 May 2014, Steve Langasek wrote:
> Bug #746587 is a prime example.  But more generally, I'm looking for
> evidence that we're being systematic about making sure the packages that
> hook into early boot, either via /etc/rcS.d or /etc/network/if-up.d, will
> still work correctly after the transition.  Maybe we won't have all of these

#743265: systemd: booting with init=/bin/systemd drops into emergency mode

If a device is not available but listed without "noauto" or "nofail"
in /etc/fstab, systemd drops into emergency mode.

If this happens on a remote server the system is practically hosed
and needs intervention from a local technician.

This can happen on *any* server that has been booting happily since
many many years. Thus, systemd is *not* a drop-in replacement for now.

The usual response is "the fstab is wrong, systemd is right", and
in the bug report I first subscribed to it. But I changed my mind
thinking about servers (e.g., mine, across in a different continent).
If a system happens to be automatically and *without* interaction
to be switched to systemd and become unbootable without local
access, then this is a serious degradation.

Norbert

PS: There might even me relevant use cases of the above - imagine
a early boot script that checks for a special mounted directory
and if it is present boots into a special USB mode, thing Tails or
gpg signing or similar.


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/20140513011130.gc31...@auth.logic.tuwien.ac.at

Re: systemd-fsck?

[Steve Langasek]

On Fri, May 09, 2014 at 08:30:22PM +0200, Michael Biebl wrote:
> Am 09.05.2014 19:56, schrieb Steve Langasek:

> > I don't think systemd integration is in a state today that this is ready to
> > become the default.

> What are you missing?

Bug #746587 is a prime example.  But more generally, I'm looking for
evidence that we're being systematic about making sure the packages that
hook into early boot, either via /etc/rcS.d or /etc/network/if-up.d, will
still work correctly after the transition.  Maybe we won't have all of these
packages fixed ahead of time, but the information should at least be
available about which packages do or don't work so that we can make an
informed decision.

-- 
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/20140513003006.gc32...@virgil.dodds.net

Re: systemd-fsck?

[Steve Langasek]

On Mon, May 12, 2014 at 04:21:56PM -0700, Josh Triplett wrote:
> > > Consider a system which has systemd installed, systemd-sysv *not*
> > > installed, and systemd used as PID 1 via init=/bin/systemd.  Since
> > > systemd-sysv is not already installed, "systemd-shim | systemd-sysv" will
> > > pull in systemd-shim instead, which will atttempt to supply services that
> > > conflict with systemd's.

> > systemd-shim is bus-activated-only.  The dbus name will already be claimed
> > by systemd itself on startup, so systemd-shim will be a no-op on such a
> > system.

> I appreciate the clarification; thanks.

> In that case, as one possible option, given that systemd-shim exists "to
> run the systemd helpers", which the systemd package provides (logind,
> etc), how crazy would it be for systemd-shim to depend on systemd rather
> than providing its own (currently binary-identical) copy of
> /etc/dbus-1/system.d/org.freedesktop.systemd1.conf?  If it did so, then
> there should be approximately zero danger of the two conflicting in any
> way, and it should be zero risk to have the two coexisting on the same
> system.

> (I realize that that inverts the dependency relationship a bit, but
> nonetheless it seems potentially sensible for maintainability and
> risk-reduction.)

Such a dependency probably wouldn't be terribly harmful, but it does seem to
me that it would be a hack.  Since the main impact of the duplication is
that systemd-shim has to be updated each time the systemd dbus security
policy changes, I prefer to wait and see whether this becomes a problem in
practice (in terms of either maintenance overhead, or impact to users).

> I'd still argue that "systemd-sysv | systemd-shim" is the right way
> around, but nonetheless the above seems helpful from the point of view
> of making sure sysvinit-core+systemd-shim and systemd can coexist on the
> same system to allow runtime selection.

It's not the right way around until we've decided that we're ready to make
the switch to systemd as default, which is a decision that should be made
collectively, and not as a result of libpam-systemd pulling it in
automatically on some (desktop) systems while other systems continue with
sysvinit.

Even after making the switch to systemd by default in unstable, listing
systemd-shim first arguably gives less surprising results to users who try
to install a desktop environment on top of an existing system: if they've
already picked up the dependency on systemd-sysv via sysvinit (once the
default has been changed), then the dependency will be satisfied as-is; and
if the user has deliberately avoided the selection of systemd-sysv, there's
no technical reason that gdm3->libpam-systemd should be the thing that pulls
it in.

> > Stop spreading FUD.

> Please consider assuming good faith; I appreciate you providing
> a correction and participating in the discussion.

Good faith doesn't enter into it.  You made a claim, clearly not based on
any first-hand knowledge, that the software didn't work.  That's
inappropriate regardless of any good intentions you might hold, and
especially on a highly contentious topic like this one.

-- 
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/20140513002643.gb32...@virgil.dodds.net

Re: systemd-fsck?

[Josh Triplett]

Steve Langasek wrote:
> On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
> > > I don't think I understand what you mean.  What does "having systemd
> > > installed" mean, if not that it's being used as the init system?  And if
> > > it isn't used as the init system (presumably because the user chose no
> > > to do that), why is it a good idea to change that?
> 
> > > In other words: what isn't handled properly?  What should happen, and
> > > what does happen?
> 
> > Consider a system which has systemd installed, systemd-sysv *not*
> > installed, and systemd used as PID 1 via init=/bin/systemd.  Since
> > systemd-sysv is not already installed, "systemd-shim | systemd-sysv" will
> > pull in systemd-shim instead, which will atttempt to supply services that
> > conflict with systemd's.
> 
> systemd-shim is bus-activated-only.  The dbus name will already be claimed
> by systemd itself on startup, so systemd-shim will be a no-op on such a
> system.

I appreciate the clarification; thanks.

In that case, as one possible option, given that systemd-shim exists "to
run the systemd helpers", which the systemd package provides (logind,
etc), how crazy would it be for systemd-shim to depend on systemd rather
than providing its own (currently binary-identical) copy of
/etc/dbus-1/system.d/org.freedesktop.systemd1.conf?  If it did so, then
there should be approximately zero danger of the two conflicting in any
way, and it should be zero risk to have the two coexisting on the same
system.

(I realize that that inverts the dependency relationship a bit, but
nonetheless it seems potentially sensible for maintainability and
risk-reduction.)

I'd still argue that "systemd-sysv | systemd-shim" is the right way
around, but nonetheless the above seems helpful from the point of view
of making sure sysvinit-core+systemd-shim and systemd can coexist on the
same system to allow runtime selection.

> Stop spreading FUD.

Please consider assuming good faith; I appreciate you providing
a correction and participating in the discussion.

- 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/20140512232122.GA14816@jtriplet-mobl1

Re: Re: systemd-fsck?

[Laurent Bigonville]

Thorsten Glaser wrote:
> On Sun, 11 May 2014, Marc Haber wrote:
[...]
> On Sun, 11 May 2014, Cyril Brulebois wrote:
> 
> > Marc Haber  (2014-05-11):
> > > Just curious as the maintainer of another package using su in an
> > > init script since 2001, how am I supposed to start a non-root
> > > process from an init script?
> > 
> > start-stop-daemon has:
> > 
> >-c, --chuid username|uid[:group|gid]
> 
> But the start-stop-daemon documentation seems to imply (please
> correct me if I’m wrong) that it’s for starting (and stopping)
> specific executables, as dæmons, with pidfiles, etc. – not for
> just running some shell code (which may or may not start other
> processes and/or dæmons) as another user.
> 
> Taking dirmngr as example again:
> 
> output=$(su -c ". /lib/lsb/init-functions && umask 027 &&
> start_daemon -p $PIDFILE $DAEMON --daemon --sh" dirmngr) || return 1
> eval "$output" || return 1
> 
> Before preparing the NMU¹, I searched long and wide for something
> using start-stop-daemon which could replace this piece of code,
> and found it not.

I've prepared a NMU to replace su by start-stop-daemon and the change
was pretty straightforward:

 output=$(start-stop-daemon --start --quiet --exec $DAEMON --oknodo --pidfile 
$PIDFILE --umask 027 --chuid dirmngr -- --daemon --sh) || return 1
 eval "$output" || return 1

Cheers,

Laurent Bigonville

> 
> ① Note I did NMU dirmngr to remove the -l from the su call,
>   which was causing problems.


--
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/20140513011414.0dad6...@fornost.bigon.be

Re: [OT] Re: systemd-fsck?

[Russ Allbery]

Charles Plessy  writes:
> Le Mon, May 12, 2014 at 12:16:48PM +0200, Andrew Shadura a écrit :
>> On 12 May 2014 11:54, Josselin Mouette  wrote:

>>> Systemd is the default init system for jessie, and it should be listed
>>> as the first alternative. The fact that an alternative codepath exists
>>> for users with specific needs is nice for them, but it is not what we
>>> should focus our efforts on.

>>> As far as GDM is concerned, any bug reported with systemd-shim
>>> installed will be ignored. The bug script should probably be updated
>>> to that effect, BTW.

>> This sort of behaviour is precisely why so many people not only dislike
>> systemd, but also it's maintainers.

> Hi Andrew,

> this is the tragedy of the commons: the time and patience of maintainers
> can be equally spent by anybody who thinks that his opinion on systemd
> ought to be listened, and therefore by the time one has a valid
> criticism to make, the maintainers time and patience has been spent up
> by others.  Message filters are a solution to this.

I hate to post a simple "me too" message, but this is so well put that I
just have to.  This, exactly.

-- 
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/87ha4ud20s@windlord.stanford.edu

Re: systemd-fsck?

[Cameron Norman]

El Mon, 12 de May 2014 a las 3:48 PM, Charles Plessy 
 escribió:

Le Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett a écrit :
 
 There *is* a reason we should push our users away from the 
non-default
 init: we want to make sure that only the users who specifically 
*want* a
 non-default init run one, and those are exactly the users prepared 
to
 deal with the additional challenges and support issues with doing 
so.
 Uers who don't care should end up running the default init system.  
It's
 easy enough for any user who *does* care to select a different set 
of

 installed packages.


Hi Josh and everybody,

how about the following heuristic:

on systems where appropriate task-desktop metapackages are installed, 
migrate automatically; on other systems, ask.


I think that it would minimise the total number of people who a) 
break their
desktop systems or block their upgrade by being afraid to migrate and 
b) break their server with an unsupervised migration.


Said differently, judging from what is written in the long threads 
here, people who do not want systemd seem to be running servers or 
exotic desktop systems, so how about only sending a debconf prompt in 
these cases ?




Is it not possible to tell if the sysvinit or upstart packages were 
installed manually, and give a prompt then (in addition to something 
like you described) ?


Best,
--
Cameron Norman

Re: systemd-fsck?

[Charles Plessy]

Le Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett a écrit :
> 
> There *is* a reason we should push our users away from the non-default
> init: we want to make sure that only the users who specifically *want* a
> non-default init run one, and those are exactly the users prepared to
> deal with the additional challenges and support issues with doing so.
> Uers who don't care should end up running the default init system.  It's
> easy enough for any user who *does* care to select a different set of
> installed packages.

Hi Josh and everybody,

how about the following heuristic:

on systems where appropriate task-desktop metapackages are installed, migrate
automatically; on other systems, ask.

I think that it would minimise the total number of people who a) break their
desktop systems or block their upgrade by being afraid to migrate and b) break
their server with an unsupervised migration.

Said differently, judging from what is written in the long threads here, people
who do not want systemd seem to be running servers or exotic desktop systems,
so how about only sending a debconf prompt in these cases ?

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/20140512224849.ga7...@falafel.plessy.net

Re: systemd-fsck?

[Svante Signell]

On Mon, 2014-05-12 at 21:16 +0200, Bas Wijnen wrote:

> 
> > It's easy enough for any user who *does* care to select a different set of
> > installed packages.
> 
> It's not so much about caring which init system to use.  It's about being in
> control over your own computer.  There are many packages that I use and while 
> I
> like them being upgraded to new versions, I don't like them to be replaced 
> with
> different programs.  Not unless I ask for it.

+100++


-- 
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/1399928030.10012.0.ca...@g3620.my.own.domain

Re: systemd-fsck?

[Bas Wijnen]

On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
> > In other words: what isn't handled properly?  What should happen, and what 
> > does
> > happen?
> 
> Consider a system which has systemd installed, systemd-sysv *not* installed,
> and systemd used as PID 1 via init=/bin/systemd.  Since systemd-sysv is not
> already installed, "systemd-shim | systemd-sysv" will pull in systemd-shim
> instead, which will atttempt to supply services that conflict with systemd's.

Sounds like those packages should conflict with each other.  It isn't a reason
to uninstall anything.

More generally, the order of dependencies doesn't matter for what options the
user can choose.  If one of those options is buggy, it shouldn't be an option.

> we want to make sure that only the users who specifically *want* a
> non-default init run one,

I, as a user, did not expect to be moved over to systemd, and given the
discussions about it and the older TC decisions about network manager getting
its dependencies right (to stop forcing all of gnome onto the user's system),
it felt to me as something that was sneaked past me.  I don't want Debian to do
that.  I don't really care about what init system I use, but I do care that I
can trust my system.  When this happened, I was thinking "what else are they
going to force onto my system when I'm not watching closely enough?"  That's my
default attitude towards any install or upgrade on a proprietary system, and I
most certainly don't want to grow it for Debian users.

> It's easy enough for any user who *does* care to select a different set of
> installed packages.

It's not so much about caring which init system to use.  It's about being in
control over your own computer.  There are many packages that I use and while I
like them being upgraded to new versions, I don't like them to be replaced with
different programs.  Not unless I ask for it.

The exception is when the program I use is no longer supported.  When that
happens, I'll need something else, and using whatever is default on new
installs is a good choice in that case.  But again, as long as other init
systems are supported, I don't want to do anything to continue using them.  Not
even something "easy".

Thanks,
Bas


-- 
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/20140512191649.gz10...@fmf.nl

Re: systemd-fsck?

[Steve Langasek]

On Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett wrote:
> > I don't think I understand what you mean.  What does "having systemd
> > installed" mean, if not that it's being used as the init system?  And if
> > it isn't used as the init system (presumably because the user chose no
> > to do that), why is it a good idea to change that?

> > In other words: what isn't handled properly?  What should happen, and
> > what does happen?

> Consider a system which has systemd installed, systemd-sysv *not*
> installed, and systemd used as PID 1 via init=/bin/systemd.  Since
> systemd-sysv is not already installed, "systemd-shim | systemd-sysv" will
> pull in systemd-shim instead, which will atttempt to supply services that
> conflict with systemd's.

systemd-shim is bus-activated-only.  The dbus name will already be claimed
by systemd itself on startup, so systemd-shim will be a no-op on such a
system.

Stop spreading FUD.

-- 
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-fsck?

[Steve Langasek]

On Mon, May 12, 2014 at 11:54:43AM +0200, Josselin Mouette wrote:
> Le vendredi 09 mai 2014 à 21:13 +0200, Bas Wijnen a écrit : 
> > I think it would be good for libpam-systemd to list systemd-shim first.

> Certainly not.

> Systemd is the default init system for jessie, and it should be listed
> as the first alternative. The fact that an alternative codepath exists
> for users with specific needs is nice for them, but it is not what we
> should focus our efforts on.

> As far as GDM is concerned, any bug reported with systemd-shim installed
> will be ignored. The bug script should probably be updated to that
> effect, BTW.

A better solution would be for you to step down as maintainer, since you
clearly are not interested in proper integration of your packages with the
rest of Debian.

-- 
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-fsck?

[Josh Triplett]

Bas Wijnen wrote:
> On Mon, May 12, 2014 at 09:19:40AM -0700, Josh Triplett wrote:
> > Having libpam-systemd depend on "systemd-shim | systemd-sysv" will not 
> > properly
> > handle systems that already have systemd installed but not systemd-sysv.
> 
> I don't think I understand what you mean.  What does "having systemd 
> installed"
> mean, if not that it's being used as the init system?  And if it isn't used as
> the init system (presumably because the user chose no to do that), why is it a
> good idea to change that?
> 
> In other words: what isn't handled properly?  What should happen, and what 
> does
> happen?

Consider a system which has systemd installed, systemd-sysv *not* installed,
and systemd used as PID 1 via init=/bin/systemd.  Since systemd-sysv is not
already installed, "systemd-shim | systemd-sysv" will pull in systemd-shim
instead, which will atttempt to supply services that conflict with systemd's.

It might be possible to make an installed systemd-shim play nice with an
installed and running systemd, and that'd be needed to allow sysvinit-core and
systemd to coexist on the same system as something the user can select.

> > > That being said, I don't really care much about the init system; sysv 
> > > worked
> > > fine for me, and now I apparently have systemd and it doesn't seem to 
> > > cause
> > > problems either.
> > 
> > Given the lack of a massive number of new bug reports against either
> > systemd packages or the desktop packages depending on them, I suspect
> > that's the general result, as well: uneventful upgrade to a system
> > that's still sysvinit-compatible, where we can deal with bugs as they
> > come up.
> 
> Yes, and it's good that upgrades are generally smooth, but I don't like the
> idea to migrate people by default.  As long as the other init systems are
> supported, there's no reason that we should push our users away from them.  If
> there are problems with them that aren't fixed, then we should stop supporting
> them.  As long as that hasn't happened, users should be free to use the other
> init systems and not be treated as second class.

There *is* a reason we should push our users away from the non-default
init: we want to make sure that only the users who specifically *want* a
non-default init run one, and those are exactly the users prepared to
deal with the additional challenges and support issues with doing so.
Uers who don't care should end up running the default init system.  It's
easy enough for any user who *does* care to select a different set of
installed packages.

- 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/20140512182113.GA8374@jtriplet-mobl1