Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-12-01 Thread Reindl Harald



Am 01.12.2016 um 02:36 schrieb Manuel Amador (Rudd-O):

On 09/26/2016 10:31 AM, Reindl Harald wrote:


Am 26.09.2016 um 11:27 schrieb Oliver Neukum:

On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote:


RTFM - when you don't say "nofail" it's ecpected to be crucial

your entry says it's crucial


That in turn raises the question why the default should be different
than what is used in earlier systems


because earlier systems (sysvinit) hat no concept like emergency mode
as they where a lousy bunch of scripts where you ended in case of a
crucial disk failing in a undefined state?

because earlier systems had no concept for "nofail" or "fail" at all


Yes, they did.  Boot would fail if a device in fstab was set to mount on
boot (option "noauto" absent) and it was not present during boot.

This is precisely why nofail is the default.


that's nonsesne just because common sense

when "nofail" would be the default "nofail" would be useless at all and 
you would need a "afil" option - isn't that crystal clear?



Sergei is right.  RTFM


which one?

"man fstab" says clearly "don't report errrors if the device does not 
exist" which clearly implies "report errors when nofail is missing" and 
what should happen when something repots and erorr is pretty clear 
defined these days

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-30 Thread Manuel Amador (Rudd-O)
On 09/26/2016 10:31 AM, Reindl Harald wrote:
>
>
> Am 26.09.2016 um 11:27 schrieb Oliver Neukum:
>> On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote:
>>>
>>> RTFM - when you don't say "nofail" it's ecpected to be crucial
>>>
>>> your entry says it's crucial
>>
>> That in turn raises the question why the default should be different
>> than what is used in earlier systems
>
> because earlier systems (sysvinit) hat no concept like emergency mode
> as they where a lousy bunch of scripts where you ended in case of a
> crucial disk failing in a undefined state?
>
> because earlier systems had no concept for "nofail" or "fail" at all

Yes, they did.  Boot would fail if a device in fstab was set to mount on
boot (option "noauto" absent) and it was not present during boot.

This is precisely why nofail is the default.

Sergei is right.  RTFM.

-- 
Rudd-O
http://rudd-o.com/




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-27 Thread Reindl Harald



Am 27.11.2016 um 19:23 schrieb Jonathan de Boyne Pollard:

Lennart Poettering:

"nofail" has been around as long as fstab has been around really.


This is a falsehood.  /etc/fstab has a history that goes back to the
20th century.  It was in UNIX System 5 Release 3, 4.2BSD, and OSF/1, for
examples.  In contrast,  the "nofail" option was invented in December
2007 for the Linux mount command by Matthias Koenig, Kay Sievers, and
Karel Zak.

* http://marc.info/?l=util-linux-ng=118425639718187=2


well, nearly 10 years - long before systemd even was considered fro 
initial development and long anough for anybody to do "man fstab" in 
that decade

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-27 Thread Jonathan de Boyne Pollard

Lennart Poettering:

"nofail" has been around as long as fstab has been around really.


This is a falsehood.  /etc/fstab has a history that goes back to the 
20th century.  It was in UNIX System 5 Release 3, 4.2BSD, and OSF/1, for 
examples.  In contrast,  the "nofail" option was invented in December 
2007 for the Linux mount command by Matthias Koenig, Kay Sievers, and 
Karel Zak.


* http://marc.info/?l=util-linux-ng=118425639718187=2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-11 Thread Lennart Poettering
On Sun, 06.11.16 11:41, Reindl Harald (h.rei...@thelounge.net) wrote:

> > You mix two different things.
> > 
> > 1. The behavior that if filesystem from /etc/fstab fails to mount, boot
> > is stopped and administrator intervention is required existed long
> > before systemd.
> > 
> > 2. Password is requested not by systemd, but by command that it starts
> > to present shell. Default is sulogin. You are free to override it with
> > anything you want, including /bin/sh. Again, sulogin was often default
> > in this case before systemd as well
> 
> no he don't - fact is before systemd the amchine bootet as long as the disk
> containing the operating system was there with or without "nofail"
> 
> the current behavior is correct but "machine stops booting and require
> password" in fact is "new" on systemd driven machines

Some distros chose to ignore failure reported by "mount". systemd does
not. I think it was a bug in those systems to ignore it. But of
course, people are welcome to disagree, and downstream distros may
of course choose to patch systemd to ignore the exit code of mount if
they like. But quite frankly, I am pretty sure that'd be a *very*
poor choice...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-10 Thread Marc Haber
On Sun, Nov 06, 2016 at 09:28:59AM +0300, Andrei Borzenkov wrote:
> 1. The behavior that if filesystem from /etc/fstab fails to mount, boot
> is stopped and administrator intervention is required existed long
> before systemd.

I have never seen this.

> 2. Password is requested not by systemd, but by command that it starts
> to present shell. Default is sulogin. You are free to override it with
> anything you want, including /bin/sh. Again, sulogin was often default
> in this case before systemd as well.

Yes, that right. Before the systemd era, systems usually continued to
boot in case (1) until they hit something hard and unmoving. systemd
systems stop voluntarily.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-06 Thread Andrei Borzenkov
06.11.2016 13:41, Reindl Harald пишет:
> 
> the current behavior is correct but "machine stops booting and require
> password" in fact is "new" on systemd driven machines
> 

It may be new for this or that distribution. It is certainly not new in
general.

echo "fsck failed for at least one filesystem (not /)."
echo "Please repair manually and reboot."
echo "The root file system is is already mounted
read-write."
echo
echo "Attention: Only CONTROL-D will reboot the
system in this"
echo "maintanance mode. shutdown or reboot will not
work."
echo
PS1="(repair filesystem) # "
export PS1
/sbin/sulogin /dev/console


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-06 Thread Reindl Harald



Am 06.11.2016 um 07:28 schrieb Andrei Borzenkov:

04.11.2016 18:14, Marc Haber пишет:

"nofail" has been around as long as fstab has been around really. It's
not a systemd invention.


I cannot say anything about that, I don't have any non-systemd
machines left. However, that machines stop booting and require the
root password is a totally new experience for me that came with systemd.


You mix two different things.

1. The behavior that if filesystem from /etc/fstab fails to mount, boot
is stopped and administrator intervention is required existed long
before systemd.

2. Password is requested not by systemd, but by command that it starts
to present shell. Default is sulogin. You are free to override it with
anything you want, including /bin/sh. Again, sulogin was often default
in this case before systemd as well


no he don't - fact is before systemd the amchine bootet as long as the 
disk containing the operating system was there with or without "nofail"


the current behavior is correct but "machine stops booting and require 
password" in fact is "new" on systemd driven machines




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-06 Thread Andrei Borzenkov
04.11.2016 18:14, Marc Haber пишет:
> On Thu, Nov 03, 2016 at 10:55:35PM +0100, Lennart Poettering wrote:
>> On Mon, 26.09.16 07:02, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
>>> On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
 The emergency mode assumes console access, which requires physical access,
 which is quiet difficult if the machine is remote.
>>>
>>> It does also assume knowledge of the root password, which is in
>>> enterprise environments not often the case. Enterprises usually have
>>> root passwords stowed away in a safe, behind a three-headed guard dog,
>>> requiring management approval, and > 2 eyes mechanisms, and usually
>>> have password-changing processes attached that touch other machines
>>> sharign the same root password as well (for example because the root
>>> password hash is stamped into the golden image).
>>>
>>> Many enterprise environments that I know have their processes geared
>>> in a way that the root password is not needed in daily operation.
>>> Login via ssh key, privilege escalation via sudo.
>>>
>>> systemd requiring the root password because some tertiary file system
>>> doesn't mount is a nuisance for those environments.
>>>
>>> Some sites have resorted to adding "nofail" to all fstab lines just to
>>> find themselves with the next issue since the initramfs of some
>>> distributions doesn't know this option yet. 
>>
>> "nofail" has been around as long as fstab has been around really. It's
>> not a systemd invention.
> 
> I cannot say anything about that, I don't have any non-systemd
> machines left. However, that machines stop booting and require the
> root password is a totally new experience for me that came with systemd.
> 

You mix two different things.

1. The behavior that if filesystem from /etc/fstab fails to mount, boot
is stopped and administrator intervention is required existed long
before systemd.

2. Password is requested not by systemd, but by command that it starts
to present shell. Default is sulogin. You are free to override it with
anything you want, including /bin/sh. Again, sulogin was often default
in this case before systemd as well.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-04 Thread Lennart Poettering
On Fri, 04.11.16 16:14, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> On Thu, Nov 03, 2016 at 10:55:35PM +0100, Lennart Poettering wrote:
> > On Mon, 26.09.16 07:02, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> > > On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
> > > > The emergency mode assumes console access, which requires physical 
> > > > access,
> > > > which is quiet difficult if the machine is remote.
> > > 
> > > It does also assume knowledge of the root password, which is in
> > > enterprise environments not often the case. Enterprises usually have
> > > root passwords stowed away in a safe, behind a three-headed guard dog,
> > > requiring management approval, and > 2 eyes mechanisms, and usually
> > > have password-changing processes attached that touch other machines
> > > sharign the same root password as well (for example because the root
> > > password hash is stamped into the golden image).
> > > 
> > > Many enterprise environments that I know have their processes geared
> > > in a way that the root password is not needed in daily operation.
> > > Login via ssh key, privilege escalation via sudo.
> > > 
> > > systemd requiring the root password because some tertiary file system
> > > doesn't mount is a nuisance for those environments.
> > > 
> > > Some sites have resorted to adding "nofail" to all fstab lines just to
> > > find themselves with the next issue since the initramfs of some
> > > distributions doesn't know this option yet. 
> > 
> > "nofail" has been around as long as fstab has been around really. It's
> > not a systemd invention.
> 
> I cannot say anything about that, I don't have any non-systemd
> machines left. However, that machines stop booting and require the
> root password is a totally new experience for me that came with systemd.

Well, some distros ignored the return value of mount -a, we generally
try to not to ignore error conditoins, in particular if they might be
relevant for security.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-04 Thread Marc Haber
On Thu, Nov 03, 2016 at 10:55:35PM +0100, Lennart Poettering wrote:
> On Mon, 26.09.16 07:02, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> > On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
> > > The emergency mode assumes console access, which requires physical access,
> > > which is quiet difficult if the machine is remote.
> > 
> > It does also assume knowledge of the root password, which is in
> > enterprise environments not often the case. Enterprises usually have
> > root passwords stowed away in a safe, behind a three-headed guard dog,
> > requiring management approval, and > 2 eyes mechanisms, and usually
> > have password-changing processes attached that touch other machines
> > sharign the same root password as well (for example because the root
> > password hash is stamped into the golden image).
> > 
> > Many enterprise environments that I know have their processes geared
> > in a way that the root password is not needed in daily operation.
> > Login via ssh key, privilege escalation via sudo.
> > 
> > systemd requiring the root password because some tertiary file system
> > doesn't mount is a nuisance for those environments.
> > 
> > Some sites have resorted to adding "nofail" to all fstab lines just to
> > find themselves with the next issue since the initramfs of some
> > distributions doesn't know this option yet. 
> 
> "nofail" has been around as long as fstab has been around really. It's
> not a systemd invention.

I cannot say anything about that, I don't have any non-systemd
machines left. However, that machines stop booting and require the
root password is a totally new experience for me that came with systemd.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-11-03 Thread Lennart Poettering
On Mon, 26.09.16 07:02, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
> > The emergency mode assumes console access, which requires physical access,
> > which is quiet difficult if the machine is remote.
> 
> It does also assume knowledge of the root password, which is in
> enterprise environments not often the case. Enterprises usually have
> root passwords stowed away in a safe, behind a three-headed guard dog,
> requiring management approval, and > 2 eyes mechanisms, and usually
> have password-changing processes attached that touch other machines
> sharign the same root password as well (for example because the root
> password hash is stamped into the golden image).
> 
> Many enterprise environments that I know have their processes geared
> in a way that the root password is not needed in daily operation.
> Login via ssh key, privilege escalation via sudo.
> 
> systemd requiring the root password because some tertiary file system
> doesn't mount is a nuisance for those environments.
> 
> Some sites have resorted to adding "nofail" to all fstab lines just to
> find themselves with the next issue since the initramfs of some
> distributions doesn't know this option yet. 

"nofail" has been around as long as fstab has been around really. It's
not a systemd invention.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-10-31 Thread Marc Haber
On Sun, Sep 25, 2016 at 08:09:20PM -0400, Dave Reisner wrote:
> Making bootup potentially interactive in this manner is strictly worse
> than dumping you into emergency mode. At least with emergency mode, you
> might be able to add dependencies to emergency.target such that, for
> example, an sshd comes up and an admin can login to the remote box.

Is there an example around for doing so? This looks way interesting.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-10-31 Thread Marc Haber
On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
> The emergency mode assumes console access, which requires physical access,
> which is quiet difficult if the machine is remote.

It does also assume knowledge of the root password, which is in
enterprise environments not often the case. Enterprises usually have
root passwords stowed away in a safe, behind a three-headed guard dog,
requiring management approval, and > 2 eyes mechanisms, and usually
have password-changing processes attached that touch other machines
sharign the same root password as well (for example because the root
password hash is stamped into the golden image).

Many enterprise environments that I know have their processes geared
in a way that the root password is not needed in daily operation.
Login via ssh key, privilege escalation via sudo.

systemd requiring the root password because some tertiary file system
doesn't mount is a nuisance for those environments.

Some sites have resorted to adding "nofail" to all fstab lines just to
find themselves with the next issue since the initramfs of some
distributions doesn't know this option yet. 

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-29 Thread Jonathan Dowland
On Mon, Sep 26, 2016 at 12:31:10PM +0200, Reindl Harald wrote:
> because earlier systems (sysvinit) hat no concept like emergency mode as
> they where a lousy bunch of scripts where you ended in case of a crucial
> disk failing in a undefined state?
> 
> because earlier systems had no concept for "nofail" or "fail" at all

At least on Debian, nofail was honoured and did have an effect, prior to
adopting systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-26 Thread Andrei Borzenkov
26.09.2016 17:58, Xen пишет:
> Andrei Borzenkov schreef op 26-09-2016 15:28:
> 
>> What effect do you expect? If service Requires mount point and mount
>> point is not available, service startup fails. That is correct and
>> expected behavior. If service does not require mount point, service
>> should be saying Wants and After. Which is at the end exactly what
>> "nofail" does w.r.t. local-fs.target.
> 
> Point is that many services are not exactly vital for system booting and
> I don't know how long it takes to get a maintainance prompt, if at all.

Emergency service (if you mean that) is entered only if local-fs.target
fails, at least as shipped by upstream.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-26 Thread Xen

Andrei Borzenkov schreef op 26-09-2016 15:28:


What effect do you expect? If service Requires mount point and mount
point is not available, service startup fails. That is correct and
expected behavior. If service does not require mount point, service
should be saying Wants and After. Which is at the end exactly what
"nofail" does w.r.t. local-fs.target.


Point is that many services are not exactly vital for system booting and 
I don't know how long it takes to get a maintainance prompt, if at all.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-26 Thread Andrei Borzenkov
On Mon, Sep 26, 2016 at 4:20 PM, Xen  wrote:
...
>>
>> because earlier systems (sysvinit) hat no concept like emergency mode
>> as they where a lousy bunch of scripts where you ended in case of a
>> crucial disk failing in a undefined state?
>>
>> because earlier systems had no concept for "nofail" or "fail" at all
>
>
> It is worth noting that nofail will have no effect if any services pull in
> the mount target.
>

What effect do you expect? If service Requires mount point and mount
point is not available, service startup fails. That is correct and
expected behavior. If service does not require mount point, service
should be saying Wants and After. Which is at the end exactly what
"nofail" does w.r.t. local-fs.target.

So yes, "nofail" won't magically convert Requires into Wants for every
service definition that mentions mount point.

> I'm not sure if I can use nofail to disable swap service from being
> activated, for instance.
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-26 Thread Xen

Reindl Harald schreef op 26-09-2016 12:31:

Am 26.09.2016 um 11:27 schrieb Oliver Neukum:

On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote:


Am 25.09.2016 um 23:52 schrieb Sergei Franco:
I am looking at correct way to disable the "feature" of emergency 
mode

when systemd encounters missing block device entires in fstab.

For example:

the following entry is in /etc/fstab:
UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data   xfs
defaults0   0

If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been 
detached
and machine rebooted it stops booting with Emergency mode, even 
though

the /data is not crucial for boot


RTFM - when you don't say "nofail" it's ecpected to be crucial

your entry says it's crucial


That in turn raises the question why the default should be different
than what is used in earlier systems


because earlier systems (sysvinit) hat no concept like emergency mode
as they where a lousy bunch of scripts where you ended in case of a
crucial disk failing in a undefined state?

because earlier systems had no concept for "nofail" or "fail" at all


It is worth noting that nofail will have no effect if any services pull 
in the mount target.


I'm not sure if I can use nofail to disable swap service from being 
activated, for instance.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-26 Thread Reindl Harald



Am 26.09.2016 um 11:27 schrieb Oliver Neukum:

On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote:


Am 25.09.2016 um 23:52 schrieb Sergei Franco:

I am looking at correct way to disable the "feature" of emergency mode
when systemd encounters missing block device entires in fstab.

For example:

the following entry is in /etc/fstab:
UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data   xfs
defaults0   0

If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been detached
and machine rebooted it stops booting with Emergency mode, even though
the /data is not crucial for boot


RTFM - when you don't say "nofail" it's ecpected to be crucial

your entry says it's crucial


That in turn raises the question why the default should be different
than what is used in earlier systems


because earlier systems (sysvinit) hat no concept like emergency mode as 
they where a lousy bunch of scripts where you ended in case of a crucial 
disk failing in a undefined state?


because earlier systems had no concept for "nofail" or "fail" at all

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-26 Thread Andrei Borzenkov
On Mon, Sep 26, 2016 at 12:27 PM, Oliver Neukum  wrote:
> On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote:
>>
>> Am 25.09.2016 um 23:52 schrieb Sergei Franco:
>> > I am looking at correct way to disable the "feature" of emergency mode
>> > when systemd encounters missing block device entires in fstab.
>> >
>> > For example:
>> >
>> > the following entry is in /etc/fstab:
>> > UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data   xfs
>> > defaults0   0
>> >
>> > If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been detached
>> > and machine rebooted it stops booting with Emergency mode, even though
>> > the /data is not crucial for boot
>>
>> RTFM - when you don't say "nofail" it's ecpected to be crucial
>>
>> your entry says it's crucial
>
> That in turn raises the question why the default should be different
> than what is used in earlier systems.
>

How it is different? SLES11 would not boot if SAN device mentioned in
/etc/fstab is not present.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-26 Thread Oliver Neukum
On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote:
> 
> Am 25.09.2016 um 23:52 schrieb Sergei Franco:
> > I am looking at correct way to disable the "feature" of emergency mode
> > when systemd encounters missing block device entires in fstab.
> >
> > For example:
> >
> > the following entry is in /etc/fstab:
> > UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data   xfs
> > defaults0   0
> >
> > If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been detached
> > and machine rebooted it stops booting with Emergency mode, even though
> > the /data is not crucial for boot
> 
> RTFM - when you don't say "nofail" it's ecpected to be crucial
> 
> your entry says it's crucial

That in turn raises the question why the default should be different
than what is used in earlier systems.

Regards
Oliver


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-26 Thread Andrei Borzenkov
On Mon, Sep 26, 2016 at 8:11 AM, Mantas Mikulėnas  wrote:
> That said, I suspect the reason it's not done by default is that it also
> needs *networking*, and every distro has its own network setup services,

It also needs logind unless you prepare special PAM configuration for
emergency service only.

> some of them dragging in *other* services like udev or dbus, which is
> somewhat contrary to emergency.target being completely minimal... (Maybe
> there should be system-failure.target for this?)
>
> --
> Mantas Mikulėnas 
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-25 Thread Mantas Mikulėnas
On Mon, Sep 26, 2016 at 4:00 AM, Sergei Franco 
wrote:

> From further reading of documentation, please correct me if I am wrong,
> one way (not sure if correct) to start SSH during emergency mode is to edit
> /etc/systemd/system/sshd.service and modify:
>
> WantedBy=multi-user.target
>
> to
>
> WantedBy=multi-user.target emergency.target
>
> Do I need to do anything with networking service or systemd will figure
> dependency of SSH service automatically? Any reason why emergency mode is
> not running SSH by default?
>

Just WantedBy= is not enough; you need the actual symlink to happen, and
`systemctl add-wants emergency.target sshd.service` is probably quicker
than WantedBy+enable.

That said, I suspect the reason it's not done by default is that it also
needs *networking*, and every distro has its own network setup services,
some of them dragging in *other* services like udev or dbus, which is
somewhat contrary to emergency.target being completely minimal... (Maybe
there should be system-failure.target for this?)

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-25 Thread Sergei Franco
>From further reading of documentation, please correct me if I am wrong, one
way (not sure if correct) to start SSH during emergency mode is to edit
/etc/systemd/system/sshd.service and modify:

WantedBy=multi-user.target

to

WantedBy=multi-user.target emergency.target

Do I need to do anything with networking service or systemd will figure
dependency of SSH service automatically? Any reason why emergency mode is
not running SSH by default?

Sergei.


On 26 September 2016 at 13:37, Sergei Franco 
wrote:

> I wasn't aware of emergency.target existence (systemd is new to me).
> What would be correct way to automatically start networking/ssh in
> emergency mode?
>
> The only thing I could find is this bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=1213781
>
>
> Sergei.
>
>
>
>
>
> On 26 September 2016 at 13:09, Dave Reisner  wrote:
>
>> On Mon, Sep 26, 2016 at 11:35:51AM +1300, Sergei Franco wrote:
>> > Thank you for your quick reply.
>> >
>> > I just tested this scenario on Ubuntu 12.04LTS (with upstart) and it
>> > present the following message:
>> >
>> > The disk drive for /data is not ready yet or not present.
>> > keys:Continue to wait, or Press S to skip mounting or M for manual
>> recovery
>> >
>> > So it is not as big difference as I initially thought, except it is much
>> > easier to deal with by simply pressing S, while I believe there is no
>> > such option for systemd (it would be nice).
>>
>> Making bootup potentially interactive in this manner is strictly worse
>> than dumping you into emergency mode. At least with emergency mode, you
>> might be able to add dependencies to emergency.target such that, for
>> example, an sshd comes up and an admin can login to the remote box.
>> How's this supposed to work with a random prompt which must be accessed
>> on /dev/console?  Enforce that everyone has some sort of out of band
>> console?
>>
>> Unclear why you consider this a superior design decision...
>>
>> > So in future for non crucial disks I will use nofail.
>> >
>> > Best regards.
>> >
>> > Sergei.
>> >
>> > P.S. As advised I have replied to correct address.
>> >
>> > On 26 September 2016 at 11:30, Reindl Harald 
>> wrote:
>> >
>> > if you post somehting to a mailing-list and you get a response on
>> the list
>> > POST REPLIES TO THE LIST - *period*
>> >
>> > Am 26.09.2016 um 00:28 schrieb Sergei Franco:
>> >
>> > Thank you for your quick reply.
>> >
>> > I just tested this scenario on Ubuntu 12.04LTS (with upstart)
>> and it
>> > present the following message:
>> >
>> > The disk drive for /data is not ready yet or not present.
>> > keys:Continue to wait, or Press S to skip mounting or M for
>> manual
>> > recovery
>> >
>> > So it is not as big difference as I initially thought, except
>> it is
>> > much
>> > easier to deal with by simply pressing S, while I believe there
>> is no
>> > such option for systemd (it would be nice).
>> >
>> > So in future for non crucial disks I will use nofail.
>> >
>> > Best regards.
>> >
>> > Sergei.
>> >
>> > On 26 September 2016 at 10:57, Reindl Harald <
>> h.rei...@thelounge.net
>> > > wrote:
>> >
>> >
>> >
>> > Am 25.09.2016 um 23:52 schrieb Sergei Franco:
>> >
>> > I am looking at correct way to disable the "feature" of
>> > emergency mode
>> > when systemd encounters missing block device entires in
>> fstab.
>> >
>> > For example:
>> >
>> > the following entry is in /etc/fstab:
>> > UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data
>>
>> >  xfs
>> > defaults0   0
>> >
>> > If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff)
>> has been
>> > detached
>> > and machine rebooted it stops booting with Emergency
>> mode, even
>> > though
>> > the /data is not crucial for boot
>> >
>> >
>> > RTFM - when you don't say "nofail" it's ecpected to be
>> crucial
>> >
>> > your entry says it's crucial
>> >
>> > http://unix.stackexchange.com/
>> questions/53456/what-is-the-di
>> > fference-between-nobootwait-and-nofail-in-fstab
>> > > > difference-between-nobootwait-and-nofail-in-fstab>
>> >
>> >
>> >
>> >
>>
>> > ___
>> > systemd-devel mailing list
>> > systemd-devel@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-25 Thread Sergei Franco
I wasn't aware of emergency.target existence (systemd is new to me).
What would be correct way to automatically start networking/ssh in
emergency mode?

The only thing I could find is this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1213781


Sergei.





On 26 September 2016 at 13:09, Dave Reisner  wrote:

> On Mon, Sep 26, 2016 at 11:35:51AM +1300, Sergei Franco wrote:
> > Thank you for your quick reply.
> >
> > I just tested this scenario on Ubuntu 12.04LTS (with upstart) and it
> > present the following message:
> >
> > The disk drive for /data is not ready yet or not present.
> > keys:Continue to wait, or Press S to skip mounting or M for manual
> recovery
> >
> > So it is not as big difference as I initially thought, except it is much
> > easier to deal with by simply pressing S, while I believe there is no
> > such option for systemd (it would be nice).
>
> Making bootup potentially interactive in this manner is strictly worse
> than dumping you into emergency mode. At least with emergency mode, you
> might be able to add dependencies to emergency.target such that, for
> example, an sshd comes up and an admin can login to the remote box.
> How's this supposed to work with a random prompt which must be accessed
> on /dev/console?  Enforce that everyone has some sort of out of band
> console?
>
> Unclear why you consider this a superior design decision...
>
> > So in future for non crucial disks I will use nofail.
> >
> > Best regards.
> >
> > Sergei.
> >
> > P.S. As advised I have replied to correct address.
> >
> > On 26 September 2016 at 11:30, Reindl Harald 
> wrote:
> >
> > if you post somehting to a mailing-list and you get a response on
> the list
> > POST REPLIES TO THE LIST - *period*
> >
> > Am 26.09.2016 um 00:28 schrieb Sergei Franco:
> >
> > Thank you for your quick reply.
> >
> > I just tested this scenario on Ubuntu 12.04LTS (with upstart)
> and it
> > present the following message:
> >
> > The disk drive for /data is not ready yet or not present.
> > keys:Continue to wait, or Press S to skip mounting or M for
> manual
> > recovery
> >
> > So it is not as big difference as I initially thought, except it
> is
> > much
> > easier to deal with by simply pressing S, while I believe there
> is no
> > such option for systemd (it would be nice).
> >
> > So in future for non crucial disks I will use nofail.
> >
> > Best regards.
> >
> > Sergei.
> >
> > On 26 September 2016 at 10:57, Reindl Harald <
> h.rei...@thelounge.net
> > > wrote:
> >
> >
> >
> > Am 25.09.2016 um 23:52 schrieb Sergei Franco:
> >
> > I am looking at correct way to disable the "feature" of
> > emergency mode
> > when systemd encounters missing block device entires in
> fstab.
> >
> > For example:
> >
> > the following entry is in /etc/fstab:
> > UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data
>
> >  xfs
> > defaults0   0
> >
> > If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has
> been
> > detached
> > and machine rebooted it stops booting with Emergency
> mode, even
> > though
> > the /data is not crucial for boot
> >
> >
> > RTFM - when you don't say "nofail" it's ecpected to be
> crucial
> >
> > your entry says it's crucial
> >
> > http://unix.stackexchange.com/questions/53456/what-is-the-di
> > fference-between-nobootwait-and-nofail-in-fstab
> >  > difference-between-nobootwait-and-nofail-in-fstab>
> >
> >
> >
> >
>
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-25 Thread Dave Reisner
On Mon, Sep 26, 2016 at 11:35:51AM +1300, Sergei Franco wrote:
> Thank you for your quick reply.
> 
> I just tested this scenario on Ubuntu 12.04LTS (with upstart) and it
> present the following message:
> 
> The disk drive for /data is not ready yet or not present.
> keys:Continue to wait, or Press S to skip mounting or M for manual recovery
> 
> So it is not as big difference as I initially thought, except it is much
> easier to deal with by simply pressing S, while I believe there is no
> such option for systemd (it would be nice).

Making bootup potentially interactive in this manner is strictly worse
than dumping you into emergency mode. At least with emergency mode, you
might be able to add dependencies to emergency.target such that, for
example, an sshd comes up and an admin can login to the remote box.
How's this supposed to work with a random prompt which must be accessed
on /dev/console?  Enforce that everyone has some sort of out of band
console?

Unclear why you consider this a superior design decision...

> So in future for non crucial disks I will use nofail.
> 
> Best regards.
> 
> Sergei.
> 
> P.S. As advised I have replied to correct address.
> 
> On 26 September 2016 at 11:30, Reindl Harald  wrote:
> 
> if you post somehting to a mailing-list and you get a response on the list
> POST REPLIES TO THE LIST - *period*
> 
> Am 26.09.2016 um 00:28 schrieb Sergei Franco:
>
> Thank you for your quick reply.
> 
> I just tested this scenario on Ubuntu 12.04LTS (with upstart) and it
> present the following message:
> 
> The disk drive for /data is not ready yet or not present.
> keys:Continue to wait, or Press S to skip mounting or M for manual
> recovery
> 
> So it is not as big difference as I initially thought, except it is
> much
> easier to deal with by simply pressing S, while I believe there is no
> such option for systemd (it would be nice).
> 
> So in future for non crucial disks I will use nofail.
> 
> Best regards.
> 
> Sergei.
> 
> On 26 September 2016 at 10:57, Reindl Harald  > wrote:
> 
> 
> 
>     Am 25.09.2016 um 23:52 schrieb Sergei Franco:
> 
>         I am looking at correct way to disable the "feature" of
>         emergency mode
>         when systemd encounters missing block device entires in fstab.
> 
>         For example:
> 
>         the following entry is in /etc/fstab:
>         UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data             
>  xfs
>         defaults        0       0
> 
>         If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been
>         detached
>         and machine rebooted it stops booting with Emergency mode, 
> even
>         though
>         the /data is not crucial for boot
> 
> 
>     RTFM - when you don't say "nofail" it's ecpected to be crucial
> 
>     your entry says it's crucial
> 
>     http://unix.stackexchange.com/questions/53456/what-is-the-di
> fference-between-nobootwait-and-nofail-in-fstab
>      difference-between-nobootwait-and-nofail-in-fstab>
> 
> 
> 
> 

> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-25 Thread Sergei Franco
Thank you for your quick reply.

I just tested this scenario on Ubuntu 12.04LTS (with upstart) and it
present the following message:

The disk drive for /data is not ready yet or not present.
keys:Continue to wait, or Press S to skip mounting or M for manual recovery

So it is not as big difference as I initially thought, except it is much
easier to deal with by simply pressing S, while I believe there is no
such option for systemd (it would be nice).

So in future for non crucial disks I will use nofail.

Best regards.

Sergei.

P.S. As advised I have replied to correct address.

On 26 September 2016 at 11:30, Reindl Harald  wrote:

> if you post somehting to a mailing-list and you get a response on the list
> POST REPLIES TO THE LIST - *period*
>
> Am 26.09.2016 um 00:28 schrieb Sergei Franco:
>
>> Thank you for your quick reply.
>>
>> I just tested this scenario on Ubuntu 12.04LTS (with upstart) and it
>> present the following message:
>>
>> The disk drive for /data is not ready yet or not present.
>> keys:Continue to wait, or Press S to skip mounting or M for manual
>> recovery
>>
>> So it is not as big difference as I initially thought, except it is much
>> easier to deal with by simply pressing S, while I believe there is no
>> such option for systemd (it would be nice).
>>
>> So in future for non crucial disks I will use nofail.
>>
>> Best regards.
>>
>> Sergei.
>>
>> On 26 September 2016 at 10:57, Reindl Harald > > wrote:
>>
>>
>>
>> Am 25.09.2016 um 23:52 schrieb Sergei Franco:
>>
>> I am looking at correct way to disable the "feature" of
>> emergency mode
>> when systemd encounters missing block device entires in fstab.
>>
>> For example:
>>
>> the following entry is in /etc/fstab:
>> UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data   xfs
>> defaults0   0
>>
>> If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been
>> detached
>> and machine rebooted it stops booting with Emergency mode, even
>> though
>> the /data is not crucial for boot
>>
>>
>> RTFM - when you don't say "nofail" it's ecpected to be crucial
>>
>> your entry says it's crucial
>>
>> http://unix.stackexchange.com/questions/53456/what-is-the-di
>> fference-between-nobootwait-and-nofail-in-fstab
>> > difference-between-nobootwait-and-nofail-in-fstab>
>>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-25 Thread Dave Reisner
On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
> Hi,
> 
> I am looking at correct way to disable the "feature" of emergency mode when
> systemd encounters missing block device entires in fstab.
> 
> For example:
> 
> the following entry is in /etc/fstab:
> UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data   xfs
> defaults    0   0
> 
> If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been detached and
> machine rebooted it stops booting with Emergency mode, even though the /data 
> is
> not crucial for boot.
>
> In past (eg. with upstart) it would simply generate a warning and continue to
> boot.
>
> The emergency mode assumes console access, which requires physical access,
> which is quiet difficult if the machine is remote.
> 
> I believe the boot should be best effort, give warning and continue to boot,
> giving at least partial working system.
> 
> Actually further thinking about it, this behaviour is bad even for desktop
> scenario.

What you seem to want is "nofail", potentially coupled with
"noauto,x-systemd.automount".

> The correct behaviour should be following: drop in emergency mode only when
> crucial to boot files are not available otherwise warn about missing drives 
> and
> continue to boot.

Critical filesystems are those listed in /etc/fstab without the "nofail"
option.

> Regards.
> 
> Sergei.
> 
> 
> 

> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-25 Thread Reindl Harald



Am 25.09.2016 um 23:52 schrieb Sergei Franco:

I am looking at correct way to disable the "feature" of emergency mode
when systemd encounters missing block device entires in fstab.

For example:

the following entry is in /etc/fstab:
UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data   xfs
defaults0   0

If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been detached
and machine rebooted it stops booting with Emergency mode, even though
the /data is not crucial for boot


RTFM - when you don't say "nofail" it's ecpected to be crucial

your entry says it's crucial

http://unix.stackexchange.com/questions/53456/what-is-the-difference-between-nobootwait-and-nofail-in-fstab


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

2016-09-25 Thread Sergei Franco
Hi,

I am looking at correct way to disable the "feature" of emergency mode when
systemd encounters missing block device entires in fstab.

For example:

the following entry is in /etc/fstab:
UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data   xfs
defaults0   0

If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been detached and
machine rebooted it stops booting with Emergency mode, even though the
/data is not crucial for boot.

In past (eg. with upstart) it would simply generate a warning and continue
to boot.

The emergency mode assumes console access, which requires physical access,
which is quiet difficult if the machine is remote.

I believe the boot should be best effort, give warning and continue to
boot, giving at least partial working system.

Actually further thinking about it, this behaviour is bad even for desktop
scenario.

The correct behaviour should be following: drop in emergency mode only when
crucial to boot files are not available otherwise warn about missing drives
and continue to boot.

Regards.

Sergei.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel