Package: systemd
Version: 215-17
Severity: normal
Hi,
I have a custom config in /etc/sysctl.d/, but systemd
does not seem to apply it at boot:
[ ~ ] $ sudo sysctl -a | grep sack
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
It says that the service run fine though:
[ ~ ] $ systemctl status
Control: found -1 215-13
Am 27.04.2015 um 21:14 schrieb Michael Biebl:
Control: tags -1 confirmed
Control: retitle -1 tmp.mount activated accidentally via bind mount
Am 27.04.2015 um 20:30 schrieb Andreas Metzler:
On 2015-04-27 Michael Biebl bi...@debian.org wrote:
Who is creating those
Processing control commands:
found -1 215-13
Bug #783509 [systemd] tmp.mount activated accidentally via bind mount
Marked as found in versions systemd/215-13.
--
783509: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783509
Debian Bug Tracking System
Contact ow...@bugs.debian.org with
(cont.)
as suspected adding After=network.target in
/lib/systemd/system/systemd-sysctl.service
actually helps
Tomasz
signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
And in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780956
the dev showed that udev already has proper hooks for resume events.
So these may be proper mechanisms for packages to ship with a
resume hook. And the last one is already tried and proven by
laptop-mode-tools.
Looking
Processing control commands:
forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=88401
Bug #779606 [systemd] daemon-reexec or daemon-reload starts
plymouth-start.service
Set Bug forwarded-to-address to
'https://bugs.freedesktop.org/show_bug.cgi?id=88401'.
fixed -1 219-6
Bug #779606
Am Mon, 27 Apr 2015 14:26:46 +0200
schrieb Ralf Jung p...@ralfj.de:
I should add that there already is a bug open against udev for this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779412
That links to a systemd bug, not a udev bug about async supend/resume,
as I had expected from your
Am 27.04.2015 um 10:48 schrieb Tomasz Buchert:
(cont.)
as suspected adding After=network.target in
/lib/systemd/system/systemd-sysctl.service
actually helps
It seems more likely, that /etc/init.d/networking changes the sysctl
knobs when it starts.
Can you investigate, if this is the case?
Your message dated Mon, 27 Apr 2015 14:20:35 +0200
with message-id 20150427122035.gb15...@buchert.pl
and subject line Re: Bug#783462: systemd-sysctl does not apply config at boot
has caused the Debian Bug report #783462,
regarding systemd-sysctl does not apply config at boot
to be marked as done.
Hi,
I should add that there already is a bug open against udev for this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779412
That links to a systemd bug, not a udev bug about async supend/resume,
as I had expected from your messages. Did I misunderstood you?
udev is part of systemd,
reassign 779412 src:systemd
Am Mon, 27 Apr 2015 15:03:23 +0200
schrieb Ralf Jung p...@ralfj.de:
udev is part of systemd, so I expected this to be about udev. The
problem surfaces not just if systemd is used as init. You are right
though that it is attached to the systemd binary package (and
Michael Biebl [2015-04-27 15:08 +0200]:
Hm, but this patch was reverted again in
be847e82cf95bf8eb589778df2aa2b3d1d7ae99e
so it's likely that the final v220 won't have a fix for that.
Allegedly this commit replaces it:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=f78f265f405a6
At
Am 27.04.2015 um 21:56 schrieb Michael Biebl:
Ok, I can confirm that adding such a bind mount to /tmp activates
tmp.mount, even if tmp.mount has been disabled. Retitling the bug report
accordingly.
I can also confirm, that this is a regression from -12 to -13 by
installing those two
On 26/04/15 13:12, Dmitry Katsubo wrote:
Indeed other files could be opened from /var, but in single mode that
is very limited. The only service that lock it is NFS mount (rpcbind).
And I can always stop these services, thus allowing me to unmount
/var. But that is not the case with process
Package: systemd
Version: 215-17
Severity: normal
Hello,
I am not sure for how long but I guess less than two months (jessie),
systemd has started purging my /tmp on every reboot, although I have
these settings:
/etc/default/rcS:
TMPTIME=2
which seems to have been migrated to
Am 27.04.2015 um 18:15 schrieb Andreas Metzler:
Package: systemd
Version: 215-17
Severity: normal
Hello,
I am not sure for how long but I guess less than two months (jessie),
systemd has started purging my /tmp on every reboot, although I have
these settings:
/etc/default/rcS:
FYI: The status of the systemd-ui source package
in Debian's testing distribution has changed.
Previous version: 3-2
Current version: 3-3
--
This email is automatically generated once a day. As the installation of
new packages into testing happens multiple times a day you will receive
FYI: The status of the libsystemd-dummy source package
in Debian's testing distribution has changed.
Previous version: 208-2
Current version: (not in testing)
Hint: (no removal hint found)
The script that generates this mail tries to extract removal
reasons from comments in the britney
On 2015-04-27 Michael Biebl bi...@debian.org wrote:
Am 27.04.2015 um 18:15 schrieb Andreas Metzler:
Package: systemd
Version: 215-17
Severity: normal
I am not sure for how long but I guess less than two months (jessie),
systemd has started purging my /tmp on every reboot, although I
Am 27.04.2015 um 19:15 schrieb Andreas Metzler:
On 2015-04-27 Michael Biebl bi...@debian.org wrote:
Am 27.04.2015 um 18:15 schrieb Andreas Metzler:
Package: systemd
Version: 215-17
Severity: normal
I am not sure for how long but I guess less than two months (jessie),
systemd has started
Am 27.04.2015 um 19:15 schrieb Andreas Metzler:
Looking at the respective changelog, only the fix for 779902 (/tmp
can be mounted as tmpfs against user's will) seems to be
tmpfs-related.
That change is actually making it less likely that tmp.mount is
activated accidentally, by not making
On 2015-04-27 Michael Biebl bi...@debian.org wrote:
Am 27.04.2015 um 19:15 schrieb Andreas Metzler:
On 2015-04-27 Michael Biebl bi...@debian.org wrote:
[...]
Or maybe, have you tmpfs-on-tmp enabled?
thanks for the help, that is exactly what seems to have happened:
[...]
ametzler@argenau:~$
Am 27.04.2015 um 20:30 schrieb Andreas Metzler:
On 2015-04-27 Michael Biebl bi...@debian.org wrote:
So you're saying, with 215-12, tmp.mount was not automatically mounted?
Yes, unless the logfile has suddenly increased in verbosity ATM. The
Mounting Temporary Directory... message started
Control: tags -1 confirmed
Control: retitle -1 tmp.mount activated accidentally via bind mount
Am 27.04.2015 um 20:30 schrieb Andreas Metzler:
On 2015-04-27 Michael Biebl bi...@debian.org wrote:
Who is creating those mounts? Maybe they didn't exist when you have -12
installed? How are they
Processing control commands:
tags -1 confirmed
Bug #783509 [systemd] systemd: /tmp purged on every reboot
Added tag(s) confirmed.
retitle -1 tmp.mount activated accidentally via bind mount
Bug #783509 [systemd] systemd: /tmp purged on every reboot
Changed Bug title to 'tmp.mount activated
25 matches
Mail list logo
