[systemd-devel] help: unmounting iscsi xfs filesystem without using netdev in /etc/fstab

2019-08-26 Thread Tony Rodriguez
Managed to detect/mount iscsi devices without using _netdev keyword in 
/etc/fstab.  Made changes within src/fstab-generator/ftstab-generator.c 
and it seems to work.  The only problem is during shutdown/reboot, my 
iscsi xfs filesystem does not unmount cleanly before the network/iscs 
service/system is shutdown.  When this happens I receive a xfs 
error/warning.


However this doesn't happen when _netdev is specified in /etc/fstab for 
my iscsi device.  Seems _netdev handles management of mounts/unmounts 
before killing things off.  How exactly does _netdev manage unmounting 
filesystems during a shutdown/reboot?   I would like to invoke that same 
netdev unmount code/logic myself from within systemd source but without 
using the _netdev keyword. Unfortunately it is a requirement to not use 
_netdev within /etc/fstab for iscsi.  Seems _netdev takes a long time to 
timeout and continue when unable to mount.


Checked src/core/mount.c and src/core/unmount.c but not sure what to do 
to duplicate how _netdev manages unmounting before the system is 
shutdown or rebooted.  Do I need a special before and after keyword in 
/etc/fstab so my xfs filesystems is unmounted before shutting down the 
iscsi service/network/system?  If so, will such keywords also propagate 
to /run/systemd/generator/remote-fs-target.requires?



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

Re: [systemd-devel] shutdown: how to tell systemd to stop a service before killing other processes

2019-08-26 Thread Ramanjulu Bellala
Can you please resolve it from your  end actually I don't no exactly where
the loop hole.

Thanks and Regards
Ram

On Mon, 26 Aug 2019, 19:54 Hans-Dieter Doll, 
wrote:

> > typically that issue is a sign of bad design and just worked by luck
> > with a simple init system lacking of concepts for service states
> well, the design is from last century :-)
>
> > you should split your stuff into multiple systemd units and pack them
> > into a target instead wrap a dozen of more or less independent things
> > in a single unit
>
> The programs in question are interaktive programs (like an editor),
> which are called by different users several times in parallel with
> parameters they want.
> (The programs attach to the supervisor process via shared memory)
>
> I'm new to systemd, but I don't think I can write units for this.
>
> But if systemd kills these processes first with a SIGTERM and only
> after some time with SIGKILL, I could catch SIGTERM and can orderly
> terminate the processes. This would solve our problem.
>
> I assume systemd does it this way, right?
>
> ___
> 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] shutdown: how to tell systemd to stop a service before killing other processes

2019-08-26 Thread Hans-Dieter Doll
> typically that issue is a sign of bad design and just worked by luck
> with a simple init system lacking of concepts for service states
well, the design is from last century :-)

> you should split your stuff into multiple systemd units and pack them
> into a target instead wrap a dozen of more or less independent things
> in a single unit

The programs in question are interaktive programs (like an editor),
which are called by different users several times in parallel with
parameters they want.
(The programs attach to the supervisor process via shared memory)

I'm new to systemd, but I don't think I can write units for this.

But if systemd kills these processes first with a SIGTERM and only
after some time with SIGKILL, I could catch SIGTERM and can orderly
terminate the processes. This would solve our problem.

I assume systemd does it this way, right?



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] Antw: Re: Antw: systemd prerelease 243-rc2

2019-08-26 Thread František Šumšal
On 8/26/19 9:43 AM, Ulrich Windl wrote:
 Mantas Mikulenas  schrieb am 23.08.2019 um 05:55 in
> Nachricht
> :
>> On Thu, Aug 22, 2019, 16:38 Ulrich Windl
> 
>> wrote:
>>
>> systemd tag bot  schrieb am
>>> 22.08.2019
>>> um
>>> 13:56 in Nachricht <20190822115637.1.05c510c92b339...@refi64.com>:
 A new systemd ☠️ pre-release ☠️ has just been tagged. Please download
>>> the
 tarball here:
>>>
>>>
 * On 64 bit systems, the "kernel.pid_max" sysctl is now bumped
> to
   4194304 by default, i.e. the full 22bit range the kernel
>>> allows,
 up
   from the old 16bit range. This should improve security and
   robustness, as PID collisions are made less likely (though
>>>
>>> I doubt it's increasing robustness for any existing application as
>>> pid_traditionally was 16 bit. I don't know if some applications try to
>>> sprintf() a pid into a char[6], but if they do, it might cause an
>>> application
>>> failure...
>>>
>>
>>
>> I've been using this value for at least 5 years, and did expect many issues
>> at first, but so far haven't encountered any at all.
>>
>> (I do kind of suspect that if there are any programs affected by this and
>> without source code available, they would be so old that they wouldn't
>> really run on a bleeding-edge distro anyway...)
> 
> Having read some C questions in stackoverflow yesterday, I'm afraid there are
> quite a lot of programmers out there writing code you couldn't even imagine in
> your most terrible nightmares ;-)
> So distribution code may be safe, but some in-house stuff or even "commercial"
> stuff may be horrible:
> (Not to long ago I had a problem that some commercial application only started
> up if the text terminal was wider than 80 characters. Why? The C program 
> called
> "ps" internally, and that in turn truncated output lines depending on the 
> value
> of COLUMNS environment...)
> 
> I think you really don't know what the most terrible imaginable programmer can
> write... ;-)
> 
> Or maybe the infamous Ariane V failure: They reused software they had tested
> before, but the hardware was different ;-)

Frankly, if such software exists and is used somewhere, it should definitely get
fixed or obsoleted. Following your mindset of keeping backward compatibility
even with broken or not future-proof software, we should also revert all changes
regarding the unix timestamp and year 2038 (in general), because changing
the datatype size from 32bit to 64bit _might_ break someone's code.

By the time this change gets to your enterprise distro, it should be pretty well
tested by various distributions close to the upstream. And even if that's not 
enough,
you an simply override the value back when you package systemd for downstream. 
From
what I can tell from various reports from our customers in RHEL, bumping
kernel.pid_max to the full 22bit range will be more than a welcome change.

-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



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

[systemd-devel] Antw: Re: Antw: systemd prerelease 243-rc2

2019-08-26 Thread Ulrich Windl
>>> Mantas Mikulenas  schrieb am 23.08.2019 um 05:55 in
Nachricht
:
> On Thu, Aug 22, 2019, 16:38 Ulrich Windl

> wrote:
> 
>> >>> systemd tag bot  schrieb am
>> 22.08.2019
>> um
>> 13:56 in Nachricht <20190822115637.1.05c510c92b339...@refi64.com>:
>> > A new systemd ☠️ pre-release ☠️ has just been tagged. Please download
>> the
>> > tarball here:
>>
>>
>> > * On 64 bit systems, the "kernel.pid_max" sysctl is now bumped
to
>> >   4194304 by default, i.e. the full 22bit range the kernel
>> allows,
>> > up
>> >   from the old 16bit range. This should improve security and
>> >   robustness, as PID collisions are made less likely (though
>>
>> I doubt it's increasing robustness for any existing application as
>> pid_traditionally was 16 bit. I don't know if some applications try to
>> sprintf() a pid into a char[6], but if they do, it might cause an
>> application
>> failure...
>>
> 
> 
> I've been using this value for at least 5 years, and did expect many issues
> at first, but so far haven't encountered any at all.
> 
> (I do kind of suspect that if there are any programs affected by this and
> without source code available, they would be so old that they wouldn't
> really run on a bleeding-edge distro anyway...)

Having read some C questions in stackoverflow yesterday, I'm afraid there are
quite a lot of programmers out there writing code you couldn't even imagine in
your most terrible nightmares ;-)
So distribution code may be safe, but some in-house stuff or even "commercial"
stuff may be horrible:
(Not to long ago I had a problem that some commercial application only started
up if the text terminal was wider than 80 characters. Why? The C program called
"ps" internally, and that in turn truncated output lines depending on the value
of COLUMNS environment...)

I think you really don't know what the most terrible imaginable programmer can
write... ;-)

Or maybe the infamous Ariane V failure: They reused software they had tested
before, but the hardware was different ;-)

Regards,
Ulrich


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

Re: [systemd-devel] Antw: Re: Antw: systemd prerelease 243-rc2

2019-08-26 Thread Reindl Harald


Am 26.08.19 um 09:14 schrieb Ulrich Windl:
>>> I doubt it's increasing robustness for any existing application as
>>> pid_traditionally was 16 bit. I don't know if some applications try to
>>> sprintf() a pid into a char[6], but if they do, it might cause an 
>> application
>>> failure...
>>
>>   What kind of tradition would that be?  Could you please point the
>> specific standard and implentation?  Everywhere I look pid_t is
>> "signed integer type" which is implemented as 32 bits.
> 
> pid_t is quite new, also. In System V a pid_t was simply an int, but no PID
> ever exceeded 2^15.
> That observation could have lead programmers to some false expectations.
> Also Using pid_t does not help you to get the correct sprintf buffer size
> unless you look how pid_t is actually defined, which -- in turn -- may be
> platform-dependent.

frankly can you stop making a fuss about such a simple default change
whcih was done here long ago in sysctl.conf on 50 systems from desktops
to all sort of servers with not a single issue?

yeah, programmers could have made wrong expectations, then they need to
fix them, you don't get this change on your SLES for years and in the
meantime all Fedora users will help clean it up

the only issue i remember was some cli tool which didn't get rioght it's
column display and was already fixed

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

[systemd-devel] Antw: Re: Antw: systemd prerelease 243-rc2

2019-08-26 Thread Ulrich Windl
>>> Tomasz Torcz  schrieb am 22.08.2019 um 19:28 in
Nachricht
<20190822172855.ga159...@mother.pipebreaker.pl>:
> On Thu, Aug 22, 2019 at 03:38:05PM +0200, Ulrich Windl wrote:
>> >>> systemd tag bot  schrieb am
22.08.2019
>> um
>> 13:56 in Nachricht <20190822115637.1.05c510c92b339...@refi64.com>:
>> > A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the

>> > tarball here:
>> 
>> 
>> > * On 64 bit systems, the "kernel.pid_max" sysctl is now bumped
to
>> >   4194304 by default, i.e. the full 22bit range the kernel
allows, 
>> > up
>> >   from the old 16bit range. This should improve security and
>> >   robustness, as PID collisions are made less likely (though 
>> 
>> I doubt it's increasing robustness for any existing application as
>> pid_traditionally was 16 bit. I don't know if some applications try to
>> sprintf() a pid into a char[6], but if they do, it might cause an 
> application
>> failure...
> 
>   What kind of tradition would that be?  Could you please point the
> specific standard and implentation?  Everywhere I look pid_t is
> "signed integer type" which is implemented as 32 bits.

pid_t is quite new, also. In System V a pid_t was simply an int, but no PID
ever exceeded 2^15.
That observation could have lead programmers to some false expectations.
Also Using pid_t does not help you to get the correct sprintf buffer size
unless you look how pid_t is actually defined, which -- in turn -- may be
platform-dependent.

Regards,
Ulrich
P.S. From my pearls of UNIX manuals:
---
NAME

getpid – get process identification

SYNOPSIS
getpid( )
DESCRIPTION
Getpid returns the process ID of the current process. Most often it is used to
generate uniquely-named temporary files.
SEE ALSO
mktemp(3)
ASSEMBLER
(getpid = 20.) sys getpid (pid in r0)
---

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

Re: [systemd-devel] Antw: Re: Antw: systemd prerelease 243-rc2

2019-08-26 Thread Reindl Harald


Am 26.08.19 um 08:38 schrieb Ulrich Windl:
 Lennart Poettering  schrieb am 22.08.2019 um 16:19 
 in
> Nachricht <20190822141902.GA585@gardel-login>:
> 
> [...]
>> Ahum, this change is a single line added to a default sysct.d/ file we
>> ship. I mean, you may have your opinions, but this line is not applied
>> in PID 1 at all, it doesn't touch the "init process" at all...
> 
> Agreed, it doesn't change the init process (from a program flow point of 
> view), but it affects all processes started from and after init.

you can easily optout from the shipped sysctl-snippets symlink them to
/dev/null in /etc/sysctl.d and the topic is done as a did 5 years ago

other than sysvinit systemd has a consistent scheme for overrides

[root@srv-rhsoft:~]$ ls /etc/sysctl.d/
insgesamt 0
lrwxrwxrwx 1 root root  9 2014-06-08 20:19 00-system.conf -> /dev/null
lrwxrwxrwx 1 root root  9 2019-02-26 07:36 10-default-yama-scope.conf ->
/dev/null
lrwxrwxrwx 1 root root  9 2019-02-26 07:36 50-coredump.conf -> /dev/null
lrwxrwxrwx 1 root root  9 2014-06-08 20:19 50-default.conf -> /dev/null
lrwxrwxrwx 1 root root  9 2019-02-26 07:36 50-libkcapi-optmem_max.conf
-> /dev/null
lrwxrwxrwx 1 root root 14 2019-07-21 11:24 99-sysctl.conf -> ../sysctl.conf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Antw: systemd prerelease 243-rc2

2019-08-26 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 22.08.2019 um 16:19 
>>> in
Nachricht <20190822141902.GA585@gardel-login>:

[...]
> Ahum, this change is a single line added to a default sysct.d/ file we
> ship. I mean, you may have your opinions, but this line is not applied
> in PID 1 at all, it doesn't touch the "init process" at all...

Agreed, it doesn't change the init process (from a program flow point of view), 
but it affects all processes started from and after init.

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin




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