Re: [systemd-devel] systemd mount point disappearing on underlying device loss?

[Andrei Borzenkov]

01.04.2017 00:05, Suresh Rajagopalan пишет:
> In Centos7/systemd, a mount point goes away automatically if the
underlying
> device is gone.
>
> In Centos6/Rhel6 (ie before systemd) and before, losing a underlying
device
> would yield Input/Output error on accessing the mount point, and the mount
> point still remains in the system.
>
> Is there any way to reinstating the old behavior in Centos7/systemd?
>

As far as I can tell, current systemd should behave as you want since
commit 9d06297. If you want this commit to be backported, you need to
contact your distribution.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd mount point disappearing on underlying device loss?

[Suresh Rajagopalan]

In Centos7/systemd, a mount point goes away automatically if the underlying
device is gone.

In Centos6/Rhel6 (ie before systemd) and before, losing a underlying device
would yield Input/Output error on accessing the mount point, and the mount
point still remains in the system.

Is there any way to reinstating the old behavior in Centos7/systemd?

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

Re: [systemd-devel] Renaming interfaces with systemd.link

[Ian Pilcher]

On 03/30/2017 10:15 AM, Lennart Poettering wrote:

My educated guess is that your .link file was ignored due to the
existance of /usr/lib/systemd/network/99-default.link. Make sure to
prefix your .link file with some number < 99 to ensure it takes
precedence.


I think I've asked this before, but is there some reason that
99-default.link can't be renamed to -default.link or something else
that will sort with a lower precedence?

It's pretty natural to want to create files with names like eno1.link,
enp2s0f0.link, etc.  I can't help thinking that a lot of time gets
wasted by people trying to figure out why .link files with this sort of
name don't work.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


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

Re: [systemd-devel] systemd reboot problem

[Jérémy Rosen]

Note that if you are calling from C code, you might want to call it 
through the Dbus API, rather than the "system" system call.


As for debugging what blocks the shutdown, here are a few clues

* does "systemctl reboot -f" stop the system correctly ?
   if yes, one of your daemons is blocking the shutdown, check all the 
printed logs for a "Stopping " with no corresponding "Stoped XXX"

  try stopping manually that service and debug what's going on with it
* does "systemctl reboot -f -f" stop shut down the system (this will not 
unmount correctly the filesystems and is only for debugging purpose)
  if that does not stop the system, your problem is at the 
kernel/hardware level. More specifically, your kernel does not know how 
to turn the power off on your system.


Jérémy

On 30/03/2017 10:47, Lennart Poettering wrote:

On Tue, 07.03.17 03:15, lin webber (webber...@outlook.com) wrote:


I use “system("reboot")” in my C program and system does not shutdown.I think 
that systemd is waiting for some services to shutdown which can't shutdown immediately.
But I don't want to wait for those services to shutdown.How can I shutdown my 
system immediately in my C program.which API should I call?
Thank you for reply.

There are several ways to reboot your system:

1) use the raw reboot() syscall. In this case file systems might end
up being dirty, and some more complex daemons might not like it
either.

2) Use "systemctl reboot -ff", which is pretty much the same as #1,
but accessible from the shell.

3) Use "systemctl reboot -f", which is a slightly friendlier version
than the above. In this mode, systemd won't bother with stopping
services correctly (instead it will just SIGTERM them all and
SIGKILL what is left then). However it will still place all file
systems in a clean state before issuing reboot().

4) Use "systemctl reboot", which is the friendliest version and
correctly shuts down all services, i.e. is equivalent to plain
"reboot" the way you already tried.


Unless you have a completely stateless system with all file systems
either read-only or formatted on each boot #3 is the vastly better
option than #1/#2.

Lennart



--
Logo 

20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr    
*Jérémy ROSEN*
Architecte technique
Email : jeremy.ro...@smile.fr 
Tel : +33141402967

Facebook  Google%2B 
 LinkedIn 
 Twitter 




bandeaux_mail 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can a systemd --user instance rely on After= of systemd --system instance?

[Lennart Poettering]

On Sat, 04.03.17 22:07, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 04.03.2017 13:49, Peter Hoeg пишет:
> > Hi,
> > 
> >> If I have a user service which needs to have the system database server
> >> available: How do I construct a proper depend?
> > 
> > As Lennart was pointing out, the user and system instances do not know
> > anything about each other, so you cannot.
> > 
> 
> "You cannot because it is currently unimplemented", "you cannot because
> we do not care but feel free to implement" or "you cannot because we
> will never even consider it"?

Quite frankly, I pretty much opposed to adding that...

Socket activation (as suggested) is the much simplre and more robust
way, since it makes it unnecessary to define explicit deps altogether.

> This means you need to set absurdly large TimeoutStart because you have
> no idea when other service appears, so every time you attempt to start
> service you will need to wait absurdly large time before proceeding with
> error handling. Proper service dependency won't even attempt to start
> dependent service until dependencies are known to run.

This is a misunderstanding how socket activation works.

> systemd already propagates some unit types (devices, mounts and swaps)
> from system to user instance. Are there any fundamental problems that
> prevent doing it for other types?

That's not really the case. All systemd instances track the kernel
state, that's all. The user instance of systemd does not communicate
with the system instance at all really, and I kinda like that.

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] udev - ignore/hide persistent storage

[Lennart Poettering]

On Fri, 31.03.17 11:30, lejeczek (pelj...@yahoo.co.uk) wrote:

> > > sorry guys to bother you, but
> > >   I'll see myself going slowly mad next week, for I've been reading and
> > > tryingand trying..
> > > 
> > > and I fail to tell udev to ignore a device and not to create symlinks.
> > > I need someone to 100% confirm this should work in v.219.
> > > The way Ithink(or hope) it should work islike:
> > > 
> > > ENV{ID_SERIAL}=="c50033d225e1", ENV{UDISKS_IGNORE}="1"
> > udisks is not involved with creating device symlinks, that's all done
> > by udev itself.
> > 
> > To disable the persistent symlinks it shuld be sufficient to set the
> > UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG udev property early enough
> > in the rules, this then has the effect that
> > 60-persistent-storage.rules is skipped.
>
> apologies, there is quite a few webpages talking explicitly about udisk,
> take just that ENV I mentioned alone, plenty of docs suggesting above, so I
> thought..
> Is it just fedora/rhel do without udisk or those docs/posts with udisk are
> obsolete all together?
> thanks.

udisks is responsible for mounting file systems, but it isn't
responsible for creating device node symlinks

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] udev - ignore/hide persistent storage

[lejeczek]

On 31/03/17 08:00, Lennart Poettering wrote:

On Thu, 30.03.17 21:40, lejeczek (pelj...@yahoo.co.uk) wrote:


sorry guys to bother you, but
  I'll see myself going slowly mad next week, for I've been reading and
tryingand trying..

and I fail to tell udev to ignore a device and not to create symlinks.
I need someone to 100% confirm this should work in v.219.
The way Ithink(or hope) it should work islike:

ENV{ID_SERIAL}=="c50033d225e1", ENV{UDISKS_IGNORE}="1"

udisks is not involved with creating device symlinks, that's all done
by udev itself.

To disable the persistent symlinks it shuld be sufficient to set the
UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG udev property early enough
in the rules, this then has the effect that
60-persistent-storage.rules is skipped.

Lennart

apologies, there is quite a few webpages talking explicitly 
about udisk, take just that ENV I mentioned alone, plenty of 
docs suggesting above, so I thought..
Is it just fedora/rhel do without udisk or those docs/posts 
with udisk are obsolete all together?

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

Re: [systemd-devel] mount-on-demand for backups; hooks for indicating success/failure

[Lennart Poettering]

On Thu, 09.03.17 15:53, Jonathan Dowland (jon+systemd-de...@alcopop.org) wrote:

> Hey,
> 
> I have some backup services which depend on mounts. I want those
> filesystems unmounted when the backup jobs are not running. This is
> easily achieved with StopWhenUnneeded.
> 
> I also want to trigger the backup jobs to start when I attach my
> external HDD. This is reasonably simple by adding WantedBy=
> to the backup service (*not* the mount unit, or it will never be
> auto-unmounted).
> 
> So far so good!
> 
> However, this is a headless box and I want to blink an LED when certain
> jobs are running, finish or fail. So I need to execute commands in
> certain situations. Job failure is easy, I can use OnFailure= and set up
> a oneshot service. Job started isn't too bad, I add a ExecStart=-
> to my backup service before the real one.
> 
> Signalling "device is safe to remove" I have not figured out.
> Using a chain of blah.device -> blah.mount -> backup-blah.service units,
> "safe to remove" LED should only happen after the mount has completed
> unmounting, successfully. Is there an existing "hook" or place that I
> could put that in this situation?

On recent systemd versions you can plug in a script in ExecStop= of
your backup service, and check the $SERVICE_RESULT env var which tells
you the success state of the service, which you can then use to set
any LEDs you like.

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] udev - ignore/hide persistent storage

[Lennart Poettering]

On Thu, 30.03.17 21:40, lejeczek (pelj...@yahoo.co.uk) wrote:

> sorry guys to bother you, but
>  I'll see myself going slowly mad next week, for I've been reading and
> tryingand trying..
> 
> and I fail to tell udev to ignore a device and not to create symlinks.
> I need someone to 100% confirm this should work in v.219.
> The way Ithink(or hope) it should work islike:
> 
> ENV{ID_SERIAL}=="c50033d225e1", ENV{UDISKS_IGNORE}="1"

udisks is not involved with creating device symlinks, that's all done
by udev itself.

To disable the persistent symlinks it shuld be sufficient to set the
UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG udev property early enough
in the rules, this then has the effect that
60-persistent-storage.rules is skipped.

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] nspawn: how to allow containers to connect to a specific host's port and prevent all the rest ?

[Lennart Poettering]

On Tue, 07.03.17 10:02, Fabien Meghazi (f...@odoo.com) wrote:

> Hello everyone,
> 
> I would like to constraint the network in the containers I spawn using
> nspawn.
> What I'd like to achieve is the following:
> 
> - prevent the containers to use the network interfaces of the host
> - make one exception and allow the containers to connect (tcp) to a
> specific port bound on the host's loopback device
> 
> The option --private-network allows me to achieve the first goal, once I
> use this option the container is "network isolated".
> 
> Then, reading the man page, I though that using --port would allow the
> container to connect to a host specific port so here's what I've been
> trying so far:
> 
> On the host I run netcat so I can check connections on the guest:
> 
> root@host # netcat -l -p 1234
> 
> >From the host, I can telnet to localhost 1234 without problem.
> Then I run the container like this:
> 
> root@host #  systemd-nspawn -M test --private-network --port 1234
> 
> But from the container I can't connect back to the host
> 
> root@test # telnet localhost 1234
> Trying ::1...
> Trying 127.0.0.1...
> telnet: Unable to connect to remote host: Connection refused
> 
> 
> So I guess I've been using the --port option in an inappropriate way
> thinking it would map a host port to the container loopback
> interface.

The --port option works the other way round: it permits connecting to
a host port which then ends up on the container's virtual network
interface.

> I checked the other networking options but I could not find something
> suitable for my use case.
> Any idea about how I could allow the container to connect to a specific
> port on the host but forbid all the rest ?

--private-network will create a virtual network between host and the
container, and it will assign IP addresses automatically to it. You
can use normal firewalling (i.e iptables) to restrict what may be sent
in and out of the container.

for example, on the host you could add a DROP rule that prohibits all
incoming traffic from the network interface pointing to the container
(that name of that is stable and generated from the container name,
"machinectl status " will show you what it is), except for
that on the specific port.

If your container is set up properly, and has nss-myhostname enabled
you can reach the host's address always under the name "gateway" if
you want to connect to it.

Long story short: it's like in normal IP networking, nspawn will
provide you a virtual network and you can use the same tools as you
would with physical devices.

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] Temporarily stopping a service while oneshot is running

[Lennart Poettering]

On Thu, 30.03.17 21:42, Kai Krakow (hurikha...@gmail.com) wrote:

> Am Thu, 30 Mar 2017 16:13:25 +0200
> schrieb Lennart Poettering :
> 
> > On Tue, 21.03.17 07:47, Ian Pilcher (arequip...@gmail.com) wrote:
> > 
> > > I have a oneshot service (run from a timer) that updates the TLS
> > > certificates in my mod_nss database.  Because NSS doesn't support
> > > concurrent access to the database, I need to temporarily shut down
> > > Apache while the certificate update service is running.
> > > 
> > > Currently, I'm using the following entries in my .service file to
> > > accomplish this:
> > > 
> > >   [Unit]
> > >   Description=Update TLS certificates in mod_nss database
> > >   # Restart Apache, even if this service fails for some reason
> > >   OnFailure=httpd.service
> > > 
> > >   [Service]
> > >   Type=oneshot
> > >   # Shut down Apache to avoid concurrent access to the mod_nss
> > > database ExecStartPre=/usr/bin/systemctl stop httpd.service
> > >   ExecStart=/usr/local/bin/update-nss-certs
> > >   ExecStartPost=/usr/bin/systemctl start httpd.service
> > > 
> > > Is this the best way to do this?  (I can't escape the feeling that
> > > there ought to be a more idiomatic way of accomplishing this.)  
> > 
> > Yes, this appears to be the best, and simplest way to do this to me.
> 
> Isn't there a chance that this introduces races when triggered while a
> bigger transaction is being executed by systemd? It always feels wrong
> to trigger actions that may affect the transaction that is currently
> being executed...

Races I don't see. systemd will merge multiple ongoing
transactions. As long as you only have "positive" transactions merging
is always predictable. But if you mix "positive" with "negative"
transactions (i.e. start jobs and stop jobs for the same units), then
of course the transaction scheduled last wins. If you have those then
of course it might not always be clear what will be in effect in the
end...

Lennart

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