Re: [systemd-devel] How to get systemd to leave a USB serial console session alone when hadware is pulled?
On Wed, May 22, 2013 at 8:12 AM, Kaz Kylheku wrote: > > On Wed, 22 May 2013 06:55:56 +0400, Andrey Borzenkov > wrote: >> В Tue, 21 May 2013 15:17:23 -0700 Kaz Kylheku пишет: >>> The workaround is, at that point, to unplug the device >>> and plug it back in. This will trigger a udev event (with >>> the "reinserted" attribute equal to "0": since no TTY session is >>> being recovered: nothing has the TTY open). The custom udev >>> rule fires, and systemd serves up an agetty. >>> >> >> Do you use getty@.service template that is distributed with systemd? If >> not, could you show full service definition? > > Yes, I just modified getty@.service. All I did to it is: > > --- a/units/getty@.service.m4 > +++ b/units/getty@.service.m4 > @@ -37,10 +37,10 @@ Restart=always > RestartSec=0 > UtmpIdentifier=%I > TTYPath=/dev/%I > -TTYReset=yes > -TTYVHangup=yes > -TTYVTDisallocate=yes > -KillMode=process > +TTYReset=no > +TTYVHangup=no > +TTYVTDisallocate=no > +KillMode=none > > # Unset locale for the console getty since the console has problems > # displaying some internationalized messages. > Try removing BindTo. In your case you do not really want to make service dependent on existence of device, only first time launching of it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files
]] Oleksii Shevchuk > > > For security reasons. It will be better if user will not have access to > > > own cores by default (situation is the same with journal backend in > > > upstream now). > > > Why? > > When apps like gpg/lastpass/whatelse-with-passwords crashes, then user > probably > will not be very happy to have all that data accessible as is. They should either be sgid some group and then setgid to the user's group or just use prctl(PR_SET_DUMPABLE, 0). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: Predictable Network Interface Names
On 01/08/2013 12:27 PM, Lennart Poettering wrote: > On Tue, 08.01.13 12:19, Ian Pilcher (arequip...@gmail.com) wrote: >> Will there still be a way to turn this off from the kernel command line? >> (I don't see anything on the wiki page.) > > biosdevname had this, and we have been thinking of adding this for this > too, but so far it doesn't exist. I have now added this to the TODO list > so that we don't forget. > Did this ever get implemented? Fedora 19 has predictable interface names turned on, and I'm really not looking forward to having to clean up the anaconda-created ifcfg- file(s) every time I do a new install from now on. I've Googled, but come up empty on any command-line options that affect this feature. Thanks! -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get systemd to leave a USB serial console session alone when hadware is pulled?
On Wed, 22 May 2013 06:55:56 +0400, Andrey Borzenkov
wrote:
> В Tue, 21 May 2013 15:17:23 -0700 Kaz Kylheku пишет:
>> The workaround is, at that point, to unplug the device
>> and plug it back in. This will trigger a udev event (with
>> the "reinserted" attribute equal to "0": since no TTY session is
>> being recovered: nothing has the TTY open). The custom udev
>> rule fires, and systemd serves up an agetty.
>>
>
> Do you use getty@.service template that is distributed with systemd? If
> not, could you show full service definition?
Yes, I just modified getty@.service. All I did to it is:
--- a/units/getty@.service.m4
+++ b/units/getty@.service.m4
@@ -37,10 +37,10 @@ Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
-TTYReset=yes
-TTYVHangup=yes
-TTYVTDisallocate=yes
-KillMode=process
+TTYReset=no
+TTYVHangup=no
+TTYVTDisallocate=no
+KillMode=none
# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Basically systemd has to note that the device has been
re-inserted (track its state), but not take any action;
just know that the device is in and re-launch agetty when that
session dies.
Now if I add a line to the udev rules like:
SUBSYSTEM=="tty", KERNEL=="ttyUSB[0-9]", ATTRS{is_console}=="1",
ATTRS{reinserted}=="1", TAG+="systemd"
Without: ENV{SYSTEMD_WANTS}+="getty@%k.service"
(Note the ATTRS{reinserted)=="1" so that this fires in the
appropriate case, when a removal and reinsertion takes place
during an open TTY session).
What happens is that systemd launches a new agetty upon reinsertion,
which runs parallel with the shell session; they compete for input.
There is some default action for that device so that if you don't
specify a SYSTEMD_WANTS, it "wants" something anyway.
Maybe it is possible to set SYSTEMD_WANTS to some kind of noop, so
systemd
wants nothing. I will search/experiment in that vein.
Thanks again.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get systemd to leave a USB serial console session alone when hadware is pulled?
В Tue, 21 May 2013 15:17:23 -0700
Kaz Kylheku пишет:
>
> On Thu, 16 May 2013 19:58:35 +0400, Andrey Borzenkov
> wrote:
> > В Wed, 15 May 2013 21:19:38 -0700
> > Kaz Kylheku пишет:
> >
> >>
> >> Can you at least tell me how to get agetty to start on a system
> >> that does not have my patch, when a USB-Serial converter is
> >> inserted which is marked as a console?
> >>
> >
> > The usual stanza is to use in your udev rules
> >
> > TAG+="systemd", ENV{SYSTEMD_WANTS}+="getty@ttyUSB0.service"
> >
> > You probably can also check whether device is marked as console
> > (whatever it means) in the same rule.
> >
> > TAG is likely to be already present for serial devices.
>
> Hi Andrey,
>
> Thank you very much for this hint in the right direction,
> it was helfpul. I have made a lot of progress with this,
> including additional kernel work, and only one more issue
> remains (to my knowledge so far, pending more testing).
> In all other respects, it works ideally, as I envisioned
> it.
>
> One thing which was causing a problem that I had the USB
> serial console declared on the kernel command line as the
> rightmost console entry. If it is the rightmost console, then
> it gets special treatment from systemd (which is entirely
> justified, since the rightmost console device which is present
> also gets special treament from the system: for instance
> the /dev/console tty device always binds to the rightmost
> console that is up.) In this case, if we have an additional
> udev rule to do the getty service, it conflicts with built in
> systemd behavior. The solution is not to have the USB serial
> as the rightmost console (which means it cannot be the only
> console: but that makes sense: we should not have a device that
> can be removed as the only console!)
>
> Now then, I have added two sysfs attributes to USB serial
> devices which make it easier to write accurate udev rules.
>
> My udev rule looks like this:
>
> SUBSYSTEM=="tty", KERNEL=="ttyUSB[0-9]", ATTRS{is_console}=="1",
> ATTRS{reinserted}=="0", TAG+="systemd",
> ENV{SYSTEMD_WANTS}+="getty@%k.service"
>
> We only launch agetty when a ttyUSB device appears which is
> a console, and is not a re-insertion.
>
> The "reinserted" property is only set when the device is
> reinserted and a TTY session is recovered. If there is
> completely a fresh start, then this property goes back
> to zero.
>
> The agetty killing behavior is prevented by setting
> KillMode = none in the getty service, so when the device
> is pulled and re-inserted, the shell session is intact.
>
> ***
>
> So now only one issue remains. If I have s shell session
> open and during that session I pull the tty serial device
> and plug it back in, and then log out of that session,
> systemd does not serve up agetty. The shell logs out and
> then the console goes unresponsive with no program monitoring
> it.
>
> The workaround is, at that point, to unplug the device
> and plug it back in. This will trigger a udev event (with
> the "reinserted" attribute equal to "0": since no TTY session is
> being recovered: nothing has the TTY open). The custom udev
> rule fires, and systemd serves up an agetty.
>
Do you use getty@.service template that is distributed with systemd? If
not, could you show full service definition?
BTW it should probably be getty-serial (not that it matters for this
problem).
> systemd seems to be reacting to the device removal event,
> and basically goes into a state in which it thinks the device is
> gone, which is correct. Moreover, since KillMode = none
> is in effect, it does not turf the associated session. However,
> it does not notice that the device is reinserted.
> When that session exits spontaneously due to a logout,
> systemd still thinks the device is not there any more,
> and so does not re-start the agetty.
>
> I suspect that this cannot be "configured away", but will
> require a patch to systemd. Though it's only a minor issue now.
> The users can just be trained to do a pull and re-insert as
> a workaround when a login prompt does not appear.
>
> Compared to the great convenience of how everything works now,
> it's nothing.
>
> Thanks again for the tip ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get systemd to leave a USB serial console session alone when hadware is pulled?
On Thu, 16 May 2013 19:58:35 +0400, Andrey Borzenkov
wrote:
> В Wed, 15 May 2013 21:19:38 -0700
> Kaz Kylheku пишет:
>
>>
>> Can you at least tell me how to get agetty to start on a system
>> that does not have my patch, when a USB-Serial converter is
>> inserted which is marked as a console?
>>
>
> The usual stanza is to use in your udev rules
>
> TAG+="systemd", ENV{SYSTEMD_WANTS}+="getty@ttyUSB0.service"
>
> You probably can also check whether device is marked as console
> (whatever it means) in the same rule.
>
> TAG is likely to be already present for serial devices.
Hi Andrey,
Thank you very much for this hint in the right direction,
it was helfpul. I have made a lot of progress with this,
including additional kernel work, and only one more issue
remains (to my knowledge so far, pending more testing).
In all other respects, it works ideally, as I envisioned
it.
One thing which was causing a problem that I had the USB
serial console declared on the kernel command line as the
rightmost console entry. If it is the rightmost console, then
it gets special treatment from systemd (which is entirely
justified, since the rightmost console device which is present
also gets special treament from the system: for instance
the /dev/console tty device always binds to the rightmost
console that is up.) In this case, if we have an additional
udev rule to do the getty service, it conflicts with built in
systemd behavior. The solution is not to have the USB serial
as the rightmost console (which means it cannot be the only
console: but that makes sense: we should not have a device that
can be removed as the only console!)
Now then, I have added two sysfs attributes to USB serial
devices which make it easier to write accurate udev rules.
My udev rule looks like this:
SUBSYSTEM=="tty", KERNEL=="ttyUSB[0-9]", ATTRS{is_console}=="1",
ATTRS{reinserted}=="0", TAG+="systemd",
ENV{SYSTEMD_WANTS}+="getty@%k.service"
We only launch agetty when a ttyUSB device appears which is
a console, and is not a re-insertion.
The "reinserted" property is only set when the device is
reinserted and a TTY session is recovered. If there is
completely a fresh start, then this property goes back
to zero.
The agetty killing behavior is prevented by setting
KillMode = none in the getty service, so when the device
is pulled and re-inserted, the shell session is intact.
***
So now only one issue remains. If I have s shell session
open and during that session I pull the tty serial device
and plug it back in, and then log out of that session,
systemd does not serve up agetty. The shell logs out and
then the console goes unresponsive with no program monitoring
it.
The workaround is, at that point, to unplug the device
and plug it back in. This will trigger a udev event (with
the "reinserted" attribute equal to "0": since no TTY session is
being recovered: nothing has the TTY open). The custom udev
rule fires, and systemd serves up an agetty.
systemd seems to be reacting to the device removal event,
and basically goes into a state in which it thinks the device is
gone, which is correct. Moreover, since KillMode = none
is in effect, it does not turf the associated session. However,
it does not notice that the device is reinserted.
When that session exits spontaneously due to a logout,
systemd still thinks the device is not there any more,
and so does not re-start the agetty.
I suspect that this cannot be "configured away", but will
require a patch to systemd. Though it's only a minor issue now.
The users can just be trained to do a pull and re-insert as
a workaround when a login prompt does not appear.
Compared to the great convenience of how everything works now,
it's nothing.
Thanks again for the tip ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System units packaging and rpmlint
Le lundi 20 mai 2013 à 19:58 -0700, T.C. Hollingsworth a écrit :
> On Sat, May 18, 2013 at 2:44 PM, Michael Scherer wrote:
> > So I planned to warn if the unit are directly in /lib, but I know there
> > is some distribution that didn't choose this path yet. So when /usr is
> > not merged, what is the canonical location ( ie, for Opensuse, Mandriva,
> > since they are both rpm based ) ?
>
> Shouldn't rpmlint just make sure the spec uses "%{_unitdir}"? Nothing
> except the systemd package should hardcode this directory.
Parsing spec is not something I will attempt
It cannot been done in a robust way ( or at least, wasn't last time I
looked ).
> (Or if the check has to be on the binary RPM side, just `rpm --eval
> '%_unitdir'` for the right location?)
I already do that, but I look in that directory to see if there is a
file for systemd ( I was using *.service, but since dbus use the same
suffix ). So by definition, i cannot detect out of that directory file
to warn about them ( unless for well know error like in /etc ).
--
Michael Scherer
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Identical mount resulting in different options
Hello! I am on an Arch Linux machine. Kernel is 3.9.3 x86_64, systemd 204. I have two identical hard drives. Both have a gparted created GPT table and a CLI created ext4 filesystem with no options other than -L (label). Archiv_1 was created like two weeks before Archiv_2 (which was created right now). I don't know about the exact kernel version or Archiv_1. Both are set in fstab with identical fstab options: LABEL=Archiv_1 /mnt/Archiv_1 ext4defaults LABEL=Archiv_2 /mnt/Archiv_2 ext4defaults yet they are actually mounted using a different option: /dev/sde1 on /mnt/Archiv_1 type ext4 (rw,relatime) /dev/sdd1 on /mnt/Archiv_2 type ext4 (rw,relatime,data=ordered) Default mount options from tune2fs are identical: root@horus /mnt/Archiv_2 # tune2fs -l /dev/sde1 | grep "mount options" Default mount options:user_xattr acl root@horus /mnt/Archiv_2 # tune2fs -l /dev/sdd1 | grep "mount options" Default mount options:user_xattr acl so is the mount file in run/systemd/generator/ But somehow systemd uses different options: root@horus ~ # systemctl show mnt-Archiv_1.mount > A1 root@horus ~ # systemctl show mnt-Archiv_2.mount > A2 root@horus ~ # diff -y A1 A2 [...] Where=/mnt/Archiv_1 | Where=/mnt/Archiv_2 What=/dev/sde1| What=/dev/sdd1 Options=rw,relatime,rw| Options=rw,relatime,rw,data=ordered [...] Why is that? Thanks! Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files
> > For security reasons. It will be better if user will not have access to > > own cores by default (situation is the same with journal backend in > > upstream now). > Why? When apps like gpg/lastpass/whatelse-with-passwords crashes, then user probably will not be very happy to have all that data accessible as is. Distros like ubuntu even disable ptrace by default for non-root users > But at the moment, I guess what you have is not too bad because we at > least will honor quota for non-root users; my main concern was filling > up even the ext4 reserved space for example. Probably it isn't, because core fds created with root:systemd-journald, like journal files ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files
On Tue, 2013-05-21 at 17:05 +0300, Oleksii Shevchuk wrote: > For security reasons. It will be better if user will not have access to > own cores by default (situation is the same with journal backend in > upstream now). Why? > Yeah, I'll add some, if idea with temporary files will be accepted in > general. I hope so =) > Cores rotation mechainsm or just avoiding to write new cores? Probably configurable to either. A nice default would be to, on space pressure, keep only the latest crash per executable. But at the moment, I guess what you have is not too bad because we at least will honor quota for non-root users; my main concern was filling up even the ext4 reserved space for example. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add command default-target
On Fri, May 17, 2013 at 03:14:15PM +0200, Vaclav Pavlin wrote:
> From: Václav Pavlín
>
> systemctl default-target NAME will set the default target.
> If the NAME is not specified, the default target is printed out.
Hi,
this departs from current command structure in systemctl, where
there are always separate "status" and "modification" verbs:
start / status
set-cgroup-attr / get-cgroup-attr
set-cgroup / unset-cgroup
enable / is-enabled
set-environment / show-environment
Partially this is because there are multiple ways to display, and
multiple ways to set/unset, so it would be harder to fit whole functionality
under one verb. In case of 'default-target' there's less ambiguity.
Nevertheless, I think systemctl is already quite complicated and
consistency is very important. 'set-default' and 'get-default' seem
like a better fit. Also, there's already 'default', and if 'default-target'
was added, it would be unobvious what is the difference between them
without reading documentation.
> ---
> man/systemctl.xml | 11 ++
> shell-completion/bash/systemctl | 4 ++
> src/core/dbus-manager.c | 15 +++-
> src/shared/install.c| 82
> +
> src/shared/install.h| 2 +
> src/systemctl/systemctl.c | 39 +++-
> 6 files changed, 142 insertions(+), 11 deletions(-)
>
> diff --git a/man/systemctl.xml b/man/systemctl.xml
> index 0afb0cc..459444b 100644
> --- a/man/systemctl.xml
> +++ b/man/systemctl.xml
> @@ -998,6 +998,17 @@ kobject-uevent 1 systemd-udevd-kernel.socket
> systemd-udevd.service
>
>
>
> +default-target
> [NAME]
> +
> +
> + Set/get the default target to boot into. If
> + the name is specified the default.target is linked
> + to the unit file. If the command is used without the name,
> + current default.target is printed.
> +
> +
> +
> +
> load
> NAME...
>
>
> diff --git a/shell-completion/bash/systemctl b/shell-completion/bash/systemctl
> index 191b8d1..ff59dbc 100644
> --- a/shell-completion/bash/systemctl
> +++ b/shell-completion/bash/systemctl
> @@ -137,6 +137,7 @@ _systemctl () {
> show-environment suspend'
> [NAME]='snapshot load'
> [FILE]='link'
> + [TARGETS]='default-target'
> )
>
> for ((i=0; $i <= $COMP_CWORD; i++)); do
> @@ -210,6 +211,9 @@ _systemctl () {
> elif __contains_word "$verb" ${VERBS[FILE]}; then
> comps=$( compgen -A file -- "$cur" )
> compopt -o filenames
> +elif __contains_word "$verb" ${VERBS[TARGETS]}; then
> +comps=$( __systemctl $mode list-unit-files --type target
> --full --all \
> +| { while read -r a b; do echo " $a"; done; } )
> fi
>
> COMPREPLY=( $(compgen -W '$comps' -- "$cur") )
> diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
> index 56b02a1..22449c5 100644
> --- a/src/core/dbus-manager.c
> +++ b/src/core/dbus-manager.c
> @@ -227,6 +227,13 @@
> " \n" \
> " \n" \
> " \n" \
> +" \n" \
> +" \n" \
> +" \n" \
> +" \n" \
> +" \n" \
> +" \n" \
> +" \n" \
> " \n"
>
> #define BUS_MANAGER_INTERFACE_SIGNALS \
> @@ -1728,7 +1735,9 @@ static DBusHandlerResult
> bus_manager_message_handler(DBusConnection *connection,
> dbus_message_is_method_call(message,
> "org.freedesktop.systemd1.Manager", "ReenableUnitFiles") ||
> dbus_message_is_method_call(message,
> "org.freedesktop.systemd1.Manager", "LinkUnitFiles") ||
> dbus_message_is_method_call(message,
> "org.freedesktop.systemd1.Manager", "PresetUnitFiles") ||
> - dbus_message_is_method_call(message,
> "org.freedesktop.systemd1.Manager", "MaskUnitFiles")) {
> + dbus_message_is_method_call(message,
> "org.freedesktop.systemd1.Manager", "MaskUnitFiles") ||
> + dbus_message_is_method_call(message,
> "org.freedesktop.systemd1.Manager", "SetDefaultTarget") ||
> + dbus_message_is_method_call(message,
> "org.freedesktop.systemd1.Manager", "GetDefaultTarget")) {
>
> char **l = NULL;
> DBusMessageIter iter;
> @@ -1771,6 +1780,10 @@ static DBusHandlerResult
> bus_manager_message_handler(DBusConnection *connection,
> carries_install_info = r;
> } else if (streq(member, "MaskUnitFiles"))
> r = unit_file_mask(scope, runtime, NULL, l, force,
Re: [systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files
> Ideally for this case it'd be a pipe; that way we avoid writing a > potentially large file to disk only to write a smaller version again. I thought about that. With cores there is no way to do transparent piping with postproc. All tools mmap cores, so in real world they will be dumped anyway.. We dump core before preprocessing to tmpfs, btw. > Maybe it would make sense to just use the process owner > by default? Why does preprocessing happen before dropping creds? For security reasons. It will be better if user will not have access to own cores by default (situation is the same with journal backend in upstream now). > Why does preprocessing happen before dropping creds Processing done in separate process with dropped creds > In general you have a lack of error logging...it'd be nice to at least > log if the preprocess command fails (or coredumps!), because the kernel > won't coredump anything with an rlimit of 1 which systemd-coredump and > any process it spawns will have. Yeah, I'll add some, if idea with temporary files will be accepted in general. > Anyways, in the big picture there's one feature we should probably have > before landing this, which is some sort of free-space detection like > journald has. Cores rotation mechainsm or just avoiding to write new cores? > At least if the system administrator has set up quotas, we should > probably ensure the files are charged against the dumping user's quota. > At the moment we're charging them to "nobody", right? At the moment cores dumped and processed at tmpfs with nobody, then copied from user creds to journal and with systemd-journal creds to fs. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemctl is-enabled work for templated units
On Tue, 2013-05-21 at 15:30 +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Sun, May 19, 2013 at 03:45:48PM +0200, Michael Tremer wrote: > > Hello guys, > > > > in this mail, you will find a patch which resolves the problem, that > > 'systemctl is-enabled' does not work for templated units. > Applied! Thanks. > > See also https://bugs.freedesktop.org/show_bug.cgi?id=55318 for > > reference. > > > > Without this patch, systemctl is-enabled something@abc.service > > returned "No such file or directory", because it was checked > > if /usr/lib/systemd/system/something@abc.service, etc. existed, > > which is obviously not the case. > Actually, we can mask instance units, so "obviously" is not true. > And we can also "concretize" instance units by adding a normal > unit file for the instance. I tweaked your patch to just > ignore ENOENT for instance units, but perform the checks. Okay. > > > If systemctl is-enabled is called for templated units, this > > check should be omitted and it should be searched for symlinks > > in the /etc paths right away. > Actually links can appear not just in /etc, so this part of the > description is misleading. I just wrote /etc to keep the message short. It should have been more precise, indeed. Thanks anyway for looking into that and amending the patch. -Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] man: Document missing options
On Fri, May 17, 2013 at 03:38:13PM +0200, Jan Janssen wrote: > --- > man/hostnamectl.xml| 8 > man/journalctl.xml | 10 ++ > man/localectl.xml | 8 > man/timedatectl.xml| 8 > src/hostname/hostnamectl.c | 1 + > src/journal/coredumpctl.c | 1 + > src/locale/localectl.c | 1 + > src/timedate/timedatectl.c | 1 + > 8 files changed, 38 insertions(+) Applied 2/2, 1/2 is still in the queue. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemctl is-enabled work for templated units
On Sun, May 19, 2013 at 03:45:48PM +0200, Michael Tremer wrote: > Hello guys, > > in this mail, you will find a patch which resolves the problem, that > 'systemctl is-enabled' does not work for templated units. Applied! > See also https://bugs.freedesktop.org/show_bug.cgi?id=55318 for > reference. > > Without this patch, systemctl is-enabled something@abc.service > returned "No such file or directory", because it was checked > if /usr/lib/systemd/system/something@abc.service, etc. existed, > which is obviously not the case. Actually, we can mask instance units, so "obviously" is not true. And we can also "concretize" instance units by adding a normal unit file for the instance. I tweaked your patch to just ignore ENOENT for instance units, but perform the checks. > If systemctl is-enabled is called for templated units, this > check should be omitted and it should be searched for symlinks > in the /etc paths right away. Actually links can appear not just in /etc, so this part of the description is misleading. > I would like to request that this is merged to the systemd git tree. This is implied :) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] service: kill processes with SIGKILL on watchdog failure
On Sun, May 19, 2013 at 12:10:55PM +0200, Michael Olbrich wrote: > Just calling service_enter_dead() does not kill any processes. > As a result, the old process may still be running when the new one is > started. > After a watchdog failure the service is in an undefined state. > Using the normal shutdown mechanism makes no sense. Instead all processes > are just killed and the service can try to restart. Applied. (I thought for a while whether we should allow normal shutdown for watchdog-failed services. Sometimes that could be useful, but for the majority of cases just killing the process is probably the right option.) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: honor "--no-legend" in 'list-sockets'
On Mon, May 20, 2013 at 11:20:15AM +0300, Mantas Mikulėnas wrote: > --- > src/systemctl/systemctl.c | 22 +- > 1 file changed, 13 insertions(+), 9 deletions(-) Applied! Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files
On Tue, 2013-05-14 at 19:09 +0300, Oleksii Shevchuk wrote: > Introduce configuration file: /etc/systemd/coredump.conf with > configurable core dumps backend storages (journal/file/both/none), > per storage size limits and preprocessing. Who would want "both" and why? Oh, though maybe you answer this here: >PreprocessFile=gzip -9 <%i>%o Ideally for this case it'd be a pipe; that way we avoid writing a potentially large file to disk only to write a smaller version again. >PreprocessJournal=gdb -nw --batch --quiet --silent --ex 'thread \ >apply all bt' --core %i %e > %o I can see this being quite cool. Would require having both gdb and debug symbols on the target system, but a lot of systems have that. Though maybe instead of this, we allow people to write systemd units that match core files. > 4. Copying "optimizations" removed for now. Now core always stored >to temporary folder, then optionaly preprocessed to temporary >files, then temporary files copied to storage. Ok; we can add this later. + If unspecified systemd-coredump will drop privileges to nobody user + to store core to temporary folder and process it. When value is unset, systemd-coredump + will drop privileges to process owner uid/gid. Does the systemd config system really have a distinction between "unspecified" and "unset"? It looks to me we're always using "nobody". But "git grep nobody" says that nothing else in systemd is using the "nobody" user. Maybe it would make sense to just use the process owner by default? Why does preprocessing happen before dropping creds? +memcpy(m, memory, memory_size); +munmap(m, memory_size); +close(fd); Should check for errors here, and log if they fail. +if (system(preprocess_journal)) +unlink(journal_tmp_filename); In general you have a lack of error logging...it'd be nice to at least log if the preprocess command fails (or coredumps!), because the kernel won't coredump anything with an rlimit of 1 which systemd-coredump and any process it spawns will have. Anyways, in the big picture there's one feature we should probably have before landing this, which is some sort of free-space detection like journald has. At the moment if this patch lands a repeatedly crashing process could just fill up the disk quickly. At least if the system administrator has set up quotas, we should probably ensure the files are charged against the dumping user's quota. At the moment we're charging them to "nobody", right? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shell / systemd config files
'Twas brillig, and Andrey Borzenkov at 21/05/13 11:26 did gyre and gimble: > On Tue, May 21, 2013 at 1:11 PM, Colin Guthrie wrote: >> 'Twas brillig, and James Buren at 20/05/13 18:28 did gyre and gimble: >>> Files such as /etc/machine-info have an incompatibility with systemd in >>> regards to how >>> it writes and/or parses them. Take the following sample: >>> >>> PRETTY_HOSTNAME="\'\"\$\`\\" >>> >>> Systemd will translate this to: '"$`\ >>> However, the shells bash and dash will translate this to: \'"$`\ >>> >>> So, it appears to be that systemd is escaping single quotes when the shells >>> themselves >>> do not honor it for single quotes here. Thoughts for a solution? I ask >>> because I have to >>> write some systemd config files for a distro installer, and cannot use >>> hostnamectl yet. >> >> AFAIUI, it's not meant to be 100% shell compatible anyway, > > According to man machine-info, it is. > > >< > The basic file format of machine-info is a newline-separated list of > environment-like shell-compatible variable assignments. It is possible > to source the configuration from shell scripts > >< Mea culpa! I guess this information slightly conflicts with the various other places where environment-like stuff is done (e.g. when processing the EnvironmentFile= stuff where there are certain things that are not quite the same as shell (e.g. continuation support IIRC the discussion about that not t long ago). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shell / systemd config files
On Tue, May 21, 2013 at 1:11 PM, Colin Guthrie wrote: > 'Twas brillig, and James Buren at 20/05/13 18:28 did gyre and gimble: >> Files such as /etc/machine-info have an incompatibility with systemd in >> regards to how >> it writes and/or parses them. Take the following sample: >> >> PRETTY_HOSTNAME="\'\"\$\`\\" >> >> Systemd will translate this to: '"$`\ >> However, the shells bash and dash will translate this to: \'"$`\ >> >> So, it appears to be that systemd is escaping single quotes when the shells >> themselves >> do not honor it for single quotes here. Thoughts for a solution? I ask >> because I have to >> write some systemd config files for a distro installer, and cannot use >> hostnamectl yet. > > AFAIUI, it's not meant to be 100% shell compatible anyway, According to man machine-info, it is. >< The basic file format of machine-info is a newline-separated list of environment-like shell-compatible variable assignments. It is possible to source the configuration from shell scripts >< ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] shell / systemd config files
'Twas brillig, and James Buren at 20/05/13 18:28 did gyre and gimble: > Files such as /etc/machine-info have an incompatibility with systemd in > regards to how > it writes and/or parses them. Take the following sample: > > PRETTY_HOSTNAME="\'\"\$\`\\" > > Systemd will translate this to: '"$`\ > However, the shells bash and dash will translate this to: \'"$`\ > > So, it appears to be that systemd is escaping single quotes when the shells > themselves > do not honor it for single quotes here. Thoughts for a solution? I ask > because I have to > write some systemd config files for a distro installer, and cannot use > hostnamectl yet. AFAIUI, it's not meant to be 100% shell compatible anyway, so I suspect the currently behaviour is as intended and will remain. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System units packaging and rpmlint
Le lundi 20 mai 2013 à 19:58 -0700, T.C. Hollingsworth a écrit :
> On Sat, May 18, 2013 at 2:44 PM, Michael Scherer wrote:
> > So I planned to warn if the unit are directly in /lib, but I know there
> > is some distribution that didn't choose this path yet. So when /usr is
> > not merged, what is the canonical location ( ie, for Opensuse, Mandriva,
> > since they are both rpm based ) ?
>
> Shouldn't rpmlint just make sure the spec uses "%{_unitdir}"? Nothing
> except the systemd package should hardcode this directory.
>
> (Or if the check has to be on the binary RPM side, just `rpm --eval
> '%_unitdir'` for the right location?)
Yes, I agree with this suggestion. This way, even if a new rpmlint
release was used on a "old" openSUSE (where /lib/systemd/system was
used), it would still work.
--
Frederic Crozat
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
