Re: [systemd-devel] Springboot and systemd, clean shutdown

[Cristian Rodríguez]

On Wed, Oct 2, 2024 at 3:58 PM Etienne Doms  wrote:

> Hi,
>
>
> https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#ExecStop=
>
> "Note that it is usually not sufficient to specify a command for this
> setting that only asks the service to terminate (for example, by
> sending some form of termination signal to it), but does not wait for
> it to do so. Since the remaining processes of the services are killed
> according to KillMode= and KillSignal= or RestartKillSignal= as
> described above immediately after the command exited, this may not
> result in a clean stop."
>
> Maybe.just maybe this behaviour can be revised somewhat now pidfds
exist..we can know for sure what's the pidfd of the main process systemd
started,
pidfds can be pooled and pid reuse is not possible with them..

Re: [systemd-devel] hint to know the state of the service using function

[Cristian Rodríguez]

On Fri, Aug 23, 2024 at 11:51 AM Rajmohan. R  wrote:

> Hi,
> Below is the change related to logging of the units (service) while
> changing the state [in]active_[exit/enter].
>
> I did not get any hint from source code, to know the state change using
> function, without querying the target system through CLI.
> Could someone from the forum help in providing a hint on how to get the
> state of the services without querying through CLI.
>
> Instead of below changes, is there any alternative modification i can do
> to know the state of the service.
>
> diff --git a/src/core/unit.c b/src/core/unit.c
> index c406bb7ab2..e6ad9b3fbf 100644
> --- a/src/core/unit.c
> +++ b/src/core/unit.c
> @@ -2497,15 +2497,31 @@ void unit_notify(Unit *u, UnitActiveState os,
> UnitActiveState ns, UnitNotifyFlag
>  if (!MANAGER_IS_RELOADING(m)) {
>  dual_timestamp_get(&u->state_change_timestamp);
>
> -if (UNIT_IS_INACTIVE_OR_FAILED(os) &&
> !UNIT_IS_INACTIVE_OR_FAILED(ns))
> +if (UNIT_IS_INACTIVE_OR_FAILED(os) &&
> !UNIT_IS_INACTIVE_OR_FAILED(ns)) {
>  u->inactive_exit_timestamp =
> u->state_change_timestamp;
> -else if (!UNIT_IS_INACTIVE_OR_FAILED(os) &&
> UNIT_IS_INACTIVE_OR_FAILED(ns))
> +log_warning("sd: u=%s, inactive_exit="USEC_FMT,
> +u->id,
> u->inactive_exit_timestamp.monotonic);
>
>
A patch that does this may be acceptable if you file a PR and use the debug
level.. using the warning level for this does not fly..

Re: [systemd-devel] Starting the sshd service on a 'non-bash' system

[Cristian Rodríguez]

On Thu, Aug 1, 2024 at 8:41 AM Mark Corbin  wrote:

> Hello
>
> I was wondering whether anybody has any experience of running the sshd
> service successfully on a system with a 'non-bash' shell?
>

mark, this is a systemd list, people here may know about openssh but  it is
not the right place to ask.



> I can't see anything obvious in either the systemd source that suggests a
> dependency on bash.
>
>
>
IF systemd wants bash, it would explicitly call /bin/bash or have scripts
with the proper shebang. otherwise a posix compatible shell should work.
Shells that are widely tested as default are bash and dash, stick to one of
those.

Re: [systemd-devel] Is /run/systemd/journal/stdout setup protocol stable?

[Cristian Rodríguez]

Unless the documentation explicitly marks something as stable or as an
ABI detail you can rely on the answer is NO.

On Fri, Jul 19, 2024 at 4:13 AM Carl Lei  wrote:

> Hi all,
>
> Short version of my question is, my program connects to
> /run/systemd/journal/stdout and dup2 to stderr; this socket needs that
> 7-line preamble to actually work.  But this seems a hidden internal
> thing, so I wonder will this be kept stable?
>

Unless it is listed here https://systemd.io/PORTABILITY_AND_STABILITY/ The
answer is no.

Re: [systemd-devel] "primary" Condition for drbd?

[Cristian Rodríguez]

On Tue, Jun 11, 2024 at 5:13 AM Harald Dunkel  wrote:
>
> Hi folks,
>
> would it be possible to add a Condition to check if a drbd
> resource ( a virtual block device with replication via network,
> see https://linbit.com/drbd/) is primary? I checked
>
> /sys/devices/virtual/block/drbd1
>
> for example, but I haven't found a way to distinguish primary
> from secondary block devices yet. Apparently there is no directory
> element showing up only for primary mode.


Did you ask the DRBD developers on what to check for AND if you are
really asking the right question to begin with?
Otherwise such a way to "distinguish primary from secondary" would
have been clearly described on some doc.

Re: [systemd-devel] Runtime symlinks replaced by hard files, systemctl enable no longer works

[Cristian Rodríguez]

On Tue, Jun 4, 2024 at 5:03 PM Joey Dodson  wrote:
>
> Hello list!
>
>
>
> Thanks in advance for any help or thoughts!
>
>
>
> Background:
>
>
>
> I have a system where many ‘/etc/systemd/system’ symlink paths got replaced 
> by files. Therefore, ‘systemctl enable’ no longer works for a majority of 
> services. Though somehow there are some services that appear to not have been 
> affected. This happened for everything in  
> ‘/etc/systemd/system/multi-user.target.wants’ and it seems all/many of the 
> ‘*.target.wants’ directories.
>
>
>
> If I delete the hard files, then I can use ‘systemctl enable’ for that 
> service, but it’s not so simple. Many services have dependencies and aliases 
> and it will throw the following error message:
>
>
>
> ‘Failed to execute operation: Invalid argument’
>
>
>
> And it may create the symlink for the main unit file, but the dependencies 
> and aliases have still failed. Therefore it’s going to leave the system in a 
> broken state unless I can get everything.
>
>
>
> Further context:
>
>
> Last time the server was rebooted, it was unable to boot into any kernel, 
> including our rescue kernel. Only emergency mode was possible through editing 
> the grub boot options. Somehow the default target was no longer set to 
> ‘multi-user.target’, but we have no logical explanation for how that could 
> have happened.
>
>
>
>
>
> Questions:
>
> Has anyone seen something like this before? How could this have happened? We 
> suspected rsync/scp from another machine, but since there are some symlinks 
> unaffected I think that’s less likely. Is there any mechanism of systemd that 
> could have caused it?
> Systemd has commands to list where the original unit files are located, but I 
> need the opposite. Is it possible to list the paths where symlinks will go 
> when using ‘systemctl enable’? The error message above is not descriptive and 
> according to search results, it could indicate that a service is masked, a 
> unit file has extra spaces, symlinks can’t be created or any number of 
> things. Without knowing the path for symlinks, I don't know which files to 
> delete to get it working again.
> I saw there is a ‘-force’ option for ‘systemctl enable’, but it seems that it 
> will only overwrite symlinks, not hard files. Is there another way to 
> overwrite files in the intended symlink path?
> Is there anything I’m missing here? I’ve never seen this before today and am 
> pretty stuck with how this could have happened and how to resolve it in a 
> thorough/holistic way.
>


Well..the symlinks where restored from an archive that did not support
symlinks?   assuming you want all those services enabled again you
could write a shell script that replaces hard files to symlinks..
It will happen again if you do not determine where that came from
though. whatever did that needs a blowtorch.

Re: [systemd-devel] L2TP NetDev not starting

[Cristian Rodríguez]

On Wed, May 8, 2024 at 9:12 PM Tr4sK  wrote:
>
> Hi,
> I'm trying to get my head around to connect my debian box to a mikrotik
> router.

Mikrotik devices support Wireguard these days.
It will outperform pretty much everything you want to use like 3x or something.
Just probably don't want this at all.
>
> I tried to keep it simple and made it work with the ip l2tp commands.
> But, with the same parameter in a .netdev file it does not appear.
>
> To be clear, it's not a mikrotik issue.
>
> I gathered informations about it here:
> https://paste.sh/fiKH_IFO#g9yTHCsiJYj-bccB3l3HP8uo
>
> I upgraded systemd to the last version available in backport:
>
> systemd/stable-backports,now 254.5-1~bpo12+3 amd64  [installé]
> systemd/stable 252.22-1~deb12u1 amd64
>
> Did anyone made it work ?
>
> Cheers.

Re: [systemd-devel] soft-reboot and surviving it

[Cristian Rodríguez]

On Fri, Apr 19, 2024 at 6:17 AM Thorsten Kukuk  wrote:
>
> On Fri, Apr 19, 2024 at 11:48 AM Luca Boccassi  
> wrote:
>
> > However, logging should work out of the box as long as the journal is
> > used, what problem are you seeing exactly?
>
> Starting around the shutdown and new start of systemd-journald during
> soft-reboot, all writes to stderr will result in an error (or create
> SIGPIPE if this is not disabled).

ugh. That's bad.. Did you identify what component does not set MSG_NOSIGNAL ?
afaik nothing should ever be closing a running program's stderr and
anything that happens after is undefined .
Posix says one may only close it after the last atexit() handler is run.

Re: [systemd-devel] enable systemd-resolved in early boot (dracut)

[Cristian Rodríguez]

On Tue, Mar 19, 2024 at 7:44 AM Aleksandar Kostadinov
 wrote:
>
> Hello,
>
> I want to enable systemd-resolved in early boot so that `clevis` can
> resolve `tang` address by mdns. This will simplify local network
> configuration by not relying on static IP addresses.
>
> But it seems that is not enabled by default.
>
> Is there a way to tell dracut to also include and start
> `systemd-resolved` as part of early boot network start?
>
> Thank you.

Please ask in the dracut lists how, systemd does not ship dracut
modules..now it should be pretty straightforward if there is already a
way to do early network.

Re: [systemd-devel] Systems-resolved: Calling gethostbyaddr on non-local/non-private causes connection attempt

[Cristian Rodríguez]

On Fri, Feb 23, 2024 at 4:37 PM anthony_ful...@trendmicro.com
 wrote:
>
> I tried this on a fresh installation of Fedora Workstation 39. I installed 
> wireshark and set the filter to `tcp.port == 5355` then ran the python script 
> again with an ip of `123.123.123.123` and I see an outbound connection 
> attempt to IP 123.123.123.123 on port 5355.

Sorry, I had LLMNR disabled..even MS says we should use MDNS instead.

Indeed
python3 -c 'import socket; socket.gethostbyaddr("123.123.123.123")'

results in an LLMR lookup.. apparently only if dns fails.

if this is not correct according to the spec, file a bug report.

Re: [systemd-devel] Systems-resolved: Calling gethostbyaddr on non-local/non-private causes connection attempt

[Cristian Rodríguez]

On Thu, Feb 22, 2024 at 8:13 PM anthony_ful...@trendmicro.com
 wrote:


I tried again now with packet capture software and no such behaviour
was found. ..what you have in the hosts line of nsswitch.conf ?

Re: [systemd-devel] Systems-resolved: Calling gethostbyaddr on non-local/non-private causes connection attempt

[Cristian Rodríguez]

On Thu, Feb 22, 2024 at 2:09 PM anthony_ful...@trendmicro.com
 wrote:

>
> Port 5355 is used for LLMNR and RFC-4795 [4], states in the abstract that 
> “LLMNR only operates on the local link” so I think the current behavior of 
> contacting hosts on port 5355 is incorrect, especially if that host IP is not 
> link-local and not in the private IP range.

I cannot reproduce your issue.. are you using the nss module "resolve" peraphs ?

Re: [systemd-devel] Permissions problems with systemd-networkd and others.

[Cristian Rodríguez]

On Wed, Feb 7, 2024 at 5:42 PM Murrell, Robert A. 
wrote:

> I finally got everything working.  Here is what I did to fix the problem:
>
>
>
> adduser systemd-network root
>
> adduser systemd-resolve root
>
> adduser bind root
>
> find /etc -type d -exec chmod 755 {} +
>

No!.. Now you are breaking the security model.. step by step´towards the
cliff..

users need to be created correctly, a well-known way is by using
systemd-sysusers.

Re: [systemd-devel] timedatectl causing system reset

[Cristian Rodríguez]

On Mon, Feb 12, 2024 at 12:17 PM ashok athukuri  wrote:
>
> Hello,
>
> In my Linux box, Initially both services "systemd-timedated.service"  and 
> "systemd-timesyncd.service" are inactive
> When I executed command:
> #timedatectl set-ntp true
> Failed to set ntp: Connection timed out
>
> But I see both service are started sequentially in the above order, wonder 
> why its causing timeout.
> Wonder why sometimes it is causing a system reset ?
>
> I also can't see logs using #journalctl -fu systemd-timedated.service
>
> Do I need to start "systemd-timedated.service" instead of inactive service ?
>
> Thanks for the help.
>
> Thanks,
> Ashok


So..you system reboots on that action ? or what do you mean with system reset ?
No, you don't need to start systemd-timedated.service, it starts by
itself when needed that error:

"Failed to set ntp: Connection timed out"

happens when timedatectl failed to talk to timedated for a pretty long
time..suggesting there is something horrible wrong with your system.

Re: networkd: bridge is configured before interfaces are enslaved

[Cristian Rodríguez]

On Thu, Dec 21, 2023 at 8:08 AM Jordi Auge <
jordi.a...@technica-engineering.de> wrote:

>
> So, what would be the correct behaviour here?
>
> So it claims to behave like the standard bridge but doesn't.. looks like a
bug on your switch device driver.

Re: [systemd-devel] Configure netdev RPS using systemd-networkd

[Cristian Rodríguez]

On Mon, Dec 4, 2023 at 5:01 AM Renjaya Raga Zenta 
wrote:

> Hi,
>
> We want to implement our networking using systemd-networkd. We think
> systemd is stable enough right now, so we want to try more "systemd-only"
> solution.
>
> In our environment, we use RPS (Receive Packet Steering) for load balancing
> and scaling. It's a kernel feature implemented a long time ago. You could
> visit the documentation at
> https://www.kernel.org/doc/html/latest/networking/scaling.html.
>
> Currently, we manually do this after network interface is configured:
>
> echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
>
> where f is bitmap mask , it means to utilize 4 cpus.
>
> Will this use case be implemented in systemd-networkd? Or should we use a
> third party solution such as networkd-broker or networkd-dispatcher?
>
> Thanks.
>

It is kinda sad the kernel never choose other default than disabled..
If you post a patchset it would be nice if it also cover the other scaling
features and to have an "auto" or "yes" mode that sets it up magically for
you.

Re: [systemd-devel] [help] Benchmarking software shows degraded performance

[Cristian Rodríguez]

On Thu, Nov 30, 2023 at 1:17 AM  wrote:

> Hi all,
>
> We have decided to replace buysbox init with systemd in our development
> boards Buildroot images.
>
> One of the boards -
> https://www.microchip.com/en-us/development-tool/atsama5d27-som1-ek1
>
> While we notice the reduction in boot time as well as the systemd
> features useful (ex: systemd-networkd), we notice the degraded
> performance when we run bench-marking software.
>
> Benchmarking software uri - https://github.com/linux4sam/egt-benchmark.
>
> One of the benchmark case is, where it simply opens graphical window on
> LCD screen and then simply closes it. For this case, the egt-benchmark
> shows 9 iterations/sec for busybox init. And it's only 5 iterations/sec
> for systemd init.
>
> We have gone through some of the techniques mentioned in the bootlin's
> debugging slides
> (https://bootlin.com/doc/training/debugging/debugging-slides.pdf) to
> optimize the system performance. Didn't help much.
>
> Note that all the development boards we use are single core SoCs.
>
> Any pointers that would lead to narrow down the issue would be grateful
> here. Thanks in advance.
>
> --
> Thanks,
> Nayab
>
>
Nayab:

Without profiler data before/after it is just speculation that systemd got
anything to do with this.

Re: [systemd-devel] Help! iSCSI based file systems with "_netdev" causing ordering cycles to occur (random services and mounts fail)

[Cristian Rodríguez]

On Sat, Oct 28, 2023 at 12:46 AM Tony Rodriguez 
wrote:

> On 10/27/23 07:06, Lennart Poettering wrote:
> > On Do, 26.10.23 19:03, Tony Rodriguez (unixpro1...@gmail.com) wrote:
> >
> >> Experiencing this same issue with iSCSI and systemd-239 for RH8/Rocky8
> and
> >> RH9/Rocky9 system-252. Nothing was done on my end to create this
> issue.  In
> >> other words, no custom mount/unit files or services, just your typical
> ISO
> >> install and rpm updates.
> >>
> >> An ordering cycle occurs, when "_netdev" is specified within /etc/fstab
> for
> >> systemd.  This happens with systemd-239-14 and systemd-239-18 using
> iSCSI
> >> based file systems.Seems others are experiencing this as well (see
> link
> >> below).  I can also confirm this happens with systemd-252 (RH9/Rocky9)l.
> >> Especially if "_netdev" is used with either "/var" or "/usr" iSCSI based
> >> devices/file systems.  The system may not boot, may not mount file
> systems,
> >> may not start services/unit files, and the system becomes slow during
> system
> >> boot.
> >>
> >> Does anyone know of a fix/patch and root cause for this?
> >>
> >> Please see this link:
> >>
> https://issues.redhat.com/browse/RHEL-12987?jql=project%20%3D%20RHEL%20AND%20affectedVersion%20%3D%20rhel-9.2.0%20AND%20text%20~%20%22iscsi%22
> >>
> >> # cat /etc/fstab
> >> [...
>
> 1) Lennart's recommendation of removing "/tmp" within /etc/fstab and
> using tmpfs for "/tmp" appears to stop the dependency issue for
> systemd-239 for systemd-252.  However, RH8 and RH9 don't support
> systemd-networkd, I am wondering how this can be overcome if removing
> "/tmp" and using "tmpfs" aren't options?  Would I have to modify various
> services and targets? What would I need to add or remove within services
> and targets to avoid these dependencies?
>

everything on the system depends on /tmp having behaviour and semantics of
a local filesystem. it is literally part of ABI if you wish. it is
hardcoded everywhere
it must "be there" always and until the last minute.
Don't do that then ! it is not only systemd..

What is exactly your problem ? you cannot commit a little ram to tmpfs ?

Re: [systemd-devel] IPv6 Compliance Issues witih networkd

[Cristian Rodríguez]

On Wed, Jul 12, 2023 at 6:38 PM Muggeridge, Matt 
wrote:

> Hi there,
>
> I am noticing networkd has a number of IPv6 compliance issues, where it is
> not meeting various RFC's "must" requirements.  For comparison, when I stop
> networkd and configure the network via legacy methods, the protocol
> exchanges comply with the RFCs.
>
> Would you prefer I raise the issues in your github or discuss the failures
> in this mailing list?
>
> Kind regards, Matt.
>

Please file a bug report, cite which standard it is breaking, make sure to
mention which legacy method you are using

Re: [systemd-devel] [EXT] Splitting large message written to stdout, explanation?

[Cristian Rodríguez]

On Thu, May 25, 2023 at 10:44 PM Virendra Negi <
virendra.n...@sugarboxnetworks.com> wrote:

> @Windl but the logs are sent to rsyslog is over unix socket.
>

It doesn't matter. just don't. This is a bad idea, will perform very poorly
on production, it is not designed from the ground up for arbitrarily large
log messages. it is the wrong protocol, it can't go well forward.

Re: [systemd-devel] systemd-resolved: performance question

[Cristian Rodríguez]

On Fri, Mar 24, 2023 at 7:41 AM Lennart Poettering 
wrote:

>
>
> There are conflicting goals here: nice, reliably behaviour that config
> changes are guaranteed to be taken into account, and a simple goal of
> performance to reduce these stat calls.
>


An option to simply ignore resolv.conf updates for advanced users might as
well just work, other dns software already have such options.

Re: [systemd-devel] How to grant systemd-nspawn access to USB device?

[Cristian Rodríguez]

On Wed, Mar 9, 2022 at 12:09 PM Kevin P  wrote:
>
> Hello Greg and thanks for answering :)
> I never used strace, so I couldn't figure from the output, but further 
> research led me to this post: 
> http://www.pclinuxos.com/forum/index.php?topic=135714.0
> So I just tried (on the host):
> chmod o+rw /dev/bus/usb/001/005
> And it is now working. I was not expecting this to be the solution.
>

This is not the solution.. of course. Your seat does have access to
the device, it doesn't have the correct permissions.

Re: [systemd-devel] systemd.sockets vs xinetd

[Cristian Rodríguez]

On Thu, Feb 10, 2022 at 5:42 AM Yolo von BNANA  wrote:

> If you’ve done any investigation into systemd.sockets, you may believe that 
> it makes super servers like xinetd obsolete. At this point in time, that is 
> not true. The xinetd super server offers more functionality than 
> systemd.sockets can currently deliver.

Well..contact the author so he can fix that in a future errata. It is
up to the author to back up any such claims.

Re: [systemd-devel] sd_bus_process() + sd_bus_wait() is it not suitable for application?

[Cristian Rodríguez]

What do you mean with memory increase ?
sd_bus is unlikely to have any severe memory leak under normal
conditions (if there is any, they are usually found in error paths) so
you are either mis-using the api or misunderstanding memory
management. if there is any memory leak either in your code or in
sd_bus it will be found building both your code and systemd with leak
sanitizer.

On Sat, Jan 22, 2022 at 3:16 AM www  wrote:
>
> Dear all,
>
> When using sd_bus_process() + sd_bus_wait()  to implement the 
> application(Service), call the methods function on the service can obtain the 
> correct information.  Run a certain number of times will lead to insufficient 
> memory and memleak does occur.
>
> It should not be a problem with the DBUS method, because a single call does 
> not increase memory, it needs to call the method 65 ~ 70 times, and you will 
> see the memory increase. After stopping the call, the memory will not 
> decrease. It seems that it has nothing to do with the time interval when the 
> method is called.
>
> code implementation：
> int main()
> {
> ..
> r = sd_bus_open_system(&bus);
> ...
> r = sd_bus_add_object_vtable(bus, ..);
> ..
> r= sd_bus_request_name(bus, "xxx.xx.xx.xxx");
> ..
>
> for( ; ; )
> {
> r = sd_bus_process(bus, NULL);
> ...
> r = sd_bus_wait(bus, -1);
> ..
> }
> sd_bus_slot_unref(slot);
> sd_bus_unref(bus);
> }
>
> thanks,
> Byron
>
>
>
>
>
>
>
>
>

Re: [systemd-devel] asset failure that looks like it's coming from systemd/

[Cristian Rodríguez]

On Sat, Dec 25, 2021 at 1:04 PM Steve Dodd  wrote:

> On Fri, 24 Dec 2021 at 10:11, Jonathan Kelly  wrote:
>
> > No. I'm in the middle here ... trying to compile unicon and it borks ...
> the unicon people don't know anything about random-util.c ... it not part
> of their software.
>
> Only thing I can think of is that something used in the compilation
> process is pulling in one of the systemd nss or pam modules? Though
> heaven only knows why ...
>
> S


yep, something like that and the load caused by the build process is
causing r = not to be equal to n ... but.. larger ? wut?

Re: [systemd-devel] asset failure that looks like it's coming from systemd/

[Cristian Rodríguez]

On Thu, Dec 23, 2021 at 10:53 PM Jonathan Kelly 
wrote:

> Hi,
>
> in trying to compile unicon programming language - I'm on arch linux ...
>
> Linux arch 5.15.10-arch1-1 #1 SMP PREEMPT Fri, 17 Dec 2021 11:17:37
> + x86_64 GNU/Linux
>
>   ... I'm getting this error
>
> make[2]: Entering directory '/usr/local/src/unicon/uni/lib'
> ../../bin/unicon -s -c gui.icn
> Assertion '(size_t) r < n' failed at src/basic/random-util.c:232,
> function genuine_random_bytes(). Aborting.
> make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted (core dumped)
>
>
> does anyone have any clues as to what is going on, and/or how to resolve
> the issue?
>
>
So, what happened that getrandom didn't return exactly the number of bytes
requested but more ? huh?

Re: [systemd-devel] PIDFile creation logic

[Cristian Rodríguez]

On Mon, Oct 18, 2021 at 4:44 PM Kenneth Porter  wrote:
>
> I just installed the new-to-EPEL ndppd service and am seeing this in my log:
>
> Oct 17 21:10:08 saruman systemd: Can't open PID file
> /var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory
>
> Examining the source, I see that the pidfile is created by the child
> process, not the parent. I'm guessing that systemd is expecting the pidfile
> to exist when the parent exits? (I want to file the issue on the upstream
> program and want to make sure I understand how this should work.)
>
> Source in question. Note how daemonize() forks and exits and main() invokes
> daemonize and then creates the pidfile. I'm thinking that daemonize()
> should create the pidfile before it invokes exit().
>
> 

the steps needed for this to work are clearly documented : man 7
daemon, section sysv daemons,
unfortunately I am yet to see any software in the wild doing this right..
but it doesn't matter. just..don't. execstart this program without -d
or -p switches, set the service Type= exec

Now.. you might consider networkd instead too.

Re: [systemd-devel] New developer building systemd

[Cristian Rodríguez]

The function is used.. only when HAVE_LIBCRYPTSETUP.

You either need to define it on an #ifdef HAVE_LIBCRYPTSETUP or add add an
__attribute__(__unused__) to it, then the warning will shut up and the
linker may garbage collect it later.



On Fri, Sep 10, 2021 at 12:50 PM Marcus Harrison 
wrote:

> Hey folks,
>
> I've downloaded the systemd sources and am attempting to build with GCC
> 9.4 on
> KDE Neon and am receiving the build error described in build-error.txt on
> updated main branch (as of writing).
>
> I've patched around it using the change described in
> remove_unused_function.patch, which allows the build to follow through,
> but
> the test suite has multiple failures, and requires manual intervention
> multiple times - for example, dropping to a BusyBox recovery shell or
> log-in
> shell, and some of the tests will hang indefinitely.
>
> I'm wondering how much of this is intended, and if my patch broke anything.
>
> Cheers,
> Marcus

Re: [systemd-devel] [hostnamed] Why the service will automatically exit after 30 seconds

[Cristian Rodríguez]

On Tue, Aug 17, 2021 at 9:35 PM 李成刚  wrote:
>
> How to configure this service so that it will not automatically exit


So what are you trying to accomplish with this ? why do you need yet
another service running when it is totally idle ?

> When the systemd-hostnamed service is started through policykit, the password 
> window will automatically exit, which seems to be a terrible experience

DAFUQ? if polkit is really talking to hostnamed then has to deal with
things so they either remaining alive or connect again ...

Re: [systemd-devel] Exception safety od sd-bus

[Cristian Rodríguez]

On Thu, Jul 22, 2021 at 9:16 AM Norbert Lange  wrote:
>

> It should be "supported" in the way that exceptions will *not*
> propagate in C libraries, and your program will call std::terminate
> should one callback throw an exception.
> Mark your callbacks with 'noexcept', statical analysis might be able
> to warn if you potentially create exceptions.

Yes, and we should make c this fact clear to the compiler annotating
sd-* libraries'  functions with __attribute__((__nothow__) like glibc
does.. however this will make headers uglier.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Alias for SMTP providers [ie. mutually exclusive service alternatives]

[Cristian Rodríguez]

On Tue, Jun 15, 2021 at 5:13 AM Kenneth Porter  wrote:
>
> What happens if I list multiple services in a Wants= and After= clause that
> are mutually exclusive (eg. sendmail/postfix/exim? How can I say "This unit
> needs to send mail" without knowing which is enabled?

Unfortunately "need to send mail" is not well defined..

a) does it need to talk to smtp/smpts/submission ports ? then your
smtp daemon needs to socket activate properly
b) Needs to execute the sendmail binary ? your sendmail command must
queue your messages for "later",

Otherwise your service must start after any of this services but not
want any of them, bad news is it will race anyway  and your app still
shouldn't care about what daemon or not is handling the email so goto
a)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sdbus errors and their underlaying int value: unique?

[Cristian Rodríguez]

On Tue, Mar 2, 2021 at 7:55 AM Carlo Wood  wrote:

> On Tue, 2 Mar 2021 10:40:25 +0100
> Carlo Wood  wrote:
>
> > I'm not writing my own C++ wrappers around sbus.
>
> I'm now* writing my own C++ wrappers around sbus.
>
>
JUst curious..what is wrong with QTDbus.. ? I strongly suggest you against
the path of reinventing this particular wheel.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Looking for known memory leaks ... [ISOLATED?]

[Cristian Rodríguez]

>
>
>
>   $ systemctl status $$
>
>   They wrote a tight loop that just kept calling that command,
>

I just did and memory use remain constant, so whatever your problem is I
cannot reproduce or was fixed ages ago.

A noticeable memory leak should be easily reproducible and fixed building
systemd with asan and running your tests.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

[Cristian Rodríguez]

On Mon, Feb 22, 2021 at 8:22 AM Robert P. J. Day 
wrote:

> On Thu, 18 Feb 2021, Lennart Poettering wrote:
>
> > On Do, 18.02.21 11:48, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
> >
> > >   A colleague has reported the following apparent issue in a fairly
> > > old (v230) version of systemd -- this is in a Yocto Project Wind River
> > > Linux 9 build, hence the age of the package.
> > >
> > >   As reported to me (and I'm gathering more info), the system was
> > > being put through some "longevity testing" by repeatedly adding,
> > > removing, activating and de-activating network interfaces. According
> > > to the report, the result was heap space slowly but inexorably being
> > > consumed.
> > >
> > >   While waiting for more info, I'm going to examine the commit log for
> > > systemd from v230 moving forward to collect any commits that address
> > > memory leaks, then peruse them more carefully to see if they might
> > > resolve the problem.
> > >
> > >   I realize it's asking a bit for folks here to remember that far
> > > back, but does this issue sound at all familiar? Any pointers that
> > > might save me some time? Thanks.
> >
> > Note that our hash tables operate with an allocation cache: when
> > adding entries to them and then removing them again the memory
> > required for that is not returned to the OS but added to a local
> > cache. When the next entry is then added again, we recycle the
> > cached entry instead of asking for new memory again. This allocation
> > cache is a bit quicker then going to malloc() all the time, but
> > means if you just watch the heap you'll assume there's a leak even
> > though there isn't really, the memory is not lost after all, and
> > will be reused eventually if we need it.
> >
> > You may use the env var SYSTEMD_MEMPOOL=0 to turn this logic off,
> > but not sure v230 already knew that env var.
>
>   well, we seem to have isolated the issue, here it is in a nutshell
> based on a condensed note i got from someone who tracked it down this
> weekend. the memory leak is triggered by:
>
>   $ ssh root@ -p 830 -s netconf   [830 = netconf over SSH]
>
> long story short, according to jemalloc profiling, there is a massive
> memory leak in DBUS code,


Ok, give that data to whoever supports your system.. you are not giving us
anything useful..
Now.. Can it have memory leaks ? yeah, it could, however I have reviewed
the code (Admit a long time ago) and leaks on the systemd binaries are
usually limited to error paths not exercised often and frankly in the path
to extinction.

What you see most of time are not leaks in the code, but leaks in
understanding of memory management techniques.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Should services be able to run without /proc?

[Cristian Rodríguez]

Glibc needs /proc mounted so the answer is no.

El El mar, 9 de feb. de 2021 a la(s) 12:05, Antonius Frie <
antonius.f...@ruhr-uni-bochum.de> escribió:

> Hi!
>
> So this is kind of a follow-up to the thread in [1], and the
> corresponding PR in [2].
>
> In short, the PR made some changes to allow for cases where /proc was
> not available in the mount namespace of the service, and added a test
> [3] to make sure that this would work. This test was later removed and
> rewritten to block /sys instead [4], because it turned out that having
> /proc unavailable sometimes caused problems with close_all_fds(), which
> is called in exec_child() after namespaces have been set up.
>
> On current master, services that don't have /proc mounted don't work at
> all anymore, since find_executable_full() ends up opening the given path
> and calling access_fd() on the resulting fd, and access_fd uses
> /proc/self/fd/* to turn the fd back into a path it can call access() on.
> As far as I can tell, the reason for not using access on the path
> directly is that access_fd is more elegant since it avoids a potential
> race condition.
>
> In addition to this, setup_private_users() also needs access to
> /proc/$pid/{uid_map, gid_map, setgroups} to do its job.
>
> Given all this, I guess my question is whether it is still desirable to
> allow units to run without /proc, especially given that ProtectProc and
> ProcSubset exist now.* If not, it might be nice to just always mount
> /proc if it wouldn't otherwise be there (i.e. if RootImage/RootDirectory
> is used); currently, MountAPIVFS=yes is basically a required option
> because of this. (I guess you could mount proc manually, but then you
> can't use ProtectProc/ProcSubset.) I'm a bit unhappy about this, because
> MountAPIVFS also mounts /sys and /dev, and then you need separate
> options just to protect those again. Either way, maybe it would be good
> to explicitly state this requirement in the documentation?
>
> Anyway, I hope that this was okay to post here, I don't really know a
> lot about this and maybe there are good reasons for why things are the
> way they are. I'd be happy about feedback though.
>
> Cheers,
> Antonius
>
> * Using both ProtectProc=ptraceable and ProcSubset=pid really doesn't
> let a lot of things through, and I don't think those interfere with any
> of the functions described above. The only thing I'm unsure about is
> setup_private_users(), since that spawns off a child process which then
> goes and writes to /proc/$parent_pid/, but I guess children can ptrace
> their parents? At least it seemed to work when I just tested it.
>
> [1]:
> https://lists.freedesktop.org/archives/systemd-devel/2017-April/038634.html
> [2]: https://github.com/systemd/systemd/pull/5985
> [3]: https://github.com/systemd/systemd/pull/6017
> [4]:
>
> https://github.com/systemd/systemd/commit/054d871d41039fcfc1a4a661c979941b9660c9e6
> ___
> 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] Is LTO worth it?

[Cristian Rodríguez]

On Mon, Jan 11, 2021 at 12:39 PM Lennart Poettering
 wrote:


> https://fedoraproject.org/wiki/LTOByDefault
>
> (I think Suse is even further ahead on this)

Yes. lto is already on by default, on worthiness of t..the jury is still out..
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-timesyncd - use unprivileged ports

[Cristian Rodríguez]

On Wed, Mar 11, 2020 at 4:17 PM Jędrzej Dudkiewicz
 wrote:

> Sorry, of course source port -

No, you really want UDP source port randomization using whatever
algorithm the kernel chooses to, due to security reasons.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] perform fsck on everyt boot

[Cristian Rodríguez]

On Mon, Nov 11, 2019 at 9:34 AM Belisko Marek  wrote:
>
Am I still
> missing something? Thanks.

Yes, what you are trying to do is the wrong thing(tm) to do, please
figure out why there is filesystem corruption in the first place,
while ext4 of course has bugs like any software around, it is not
known for being fragile. I'd bet money on the SD card being crappy.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] EXT: sdbus_event loop state mark as volatile?

[Cristian Rodríguez]

> >while (e->state != SD_EVENT_FINISHED) {
> >r = sd_event_run(e, (uint64_t) -1);
> >
> > But since e->state is changed by another thread it

Well..then the game is up because sd-bus does not claim to be thread
safe or even aspires to be..  accessing e from different threads will
cause unspecified behaviour.

In any case this patch is not quite what is needed to make it safe.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] MongoDB error after the changing the Path

[Cristian Rodríguez]

El 09-01-2019 a las 10:35, hemanthkuma...@vakilsearch.com escribió:

Hi All,

I am facing the problem in MongDB after the Path. So help me ti sort the 
issue


[root@ca-mongo mongo]# cat /etc/mongod.conf




Please ask in mongodb users list, this problem has nothing to do with 
systemd development.


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

Re: [systemd-devel] How to add a second bridge to a nspawn container?

[Cristian Rodríguez]

El 04-01-2019 a las 2:50, Mantas Mikulėnas escribió:


That's because the specified interface is not a bridge...



Yeah, that and it is a wireless interface..it may not work .. OP needs 
to use ipvlan instead.

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

Re: [systemd-devel] Systemd logging..

[Cristian Rodríguez]

El 21-11-2018 a las 11:08, deepan muthusamy escribió:


 > Can u please tell me what are all the things I have to add in .service

file to store all logs into a log file.


Some daemons provide an option to log to file, use that if available, 
otherwise make your program write debug or log messages to stderr and 
the journal will capture it.. then you can extract them to a text file.


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

Re: [systemd-devel] Environment-variable security?

[Cristian Rodríguez]

El 13-11-2018 a las 9:49, David Parsley escribió:
I disagree; privacy of environment variables to individual users on the 
system is as fundamental as Unix file permissions.


Please find us ONE reference to a relevant, current *nix standard that 
says environment variables are either secret, suitable for secrets, 
private or the system is expected to treat them as such.


Breaking news.. no such requirement or even suggestion exists, 
environment variables just work this way. No need to be so stubborn when 
the world does not work the way you want to..just find a different 
proper solution to fix the problem.








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

Re: [systemd-devel] Data flow is slow

[Cristian Rodríguez]

El 09-11-2018 a las 1:08, deepan muthusamy escribió:
I created a session bus as system service. And iam connecting to that 
session bus. My requirement is like this, that's why I'm doing this.@ Simon.


Well..considering that Simon literally wrote the dbus daemon I will 
certainly listen to what he is saying on the matter.. So I will repeat 
what he said once again.. system services are not part of a session.. 
when you "start them manually" your shell is.



There is no test program for this. App2 should return the data to app1 
and app1 should show Change in UI. this whole thing taking long time. @ 
Mantas


I do not know if there is a language barrier or what.. but your posts 
are not conductive to give you any help whatsoever.. you provide no hard 
data to look at, error messages, what exactly is taking a crapload of 
time..

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

Re: [systemd-devel] Systemd service taking huge memory

[Cristian Rodríguez]

El 08-11-2018 a las 11:02, deepan muthusamy escribió:
If I start my application as system service, it is consuming huge 
memory. This leads to my system getting slow down.

If I start manually, it's not consuming that much memory.

What can be the possible reasons?


Your application has a memory leak on a path that is only excercised 
when started as a permanently running application..hard to tell without 
a concrete example and memory usage data.. use


#pmap $(pidof yourprogram)
and see if the PSS size keeps growing or what.

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

Re: [systemd-devel] A question about the race condition between two service

[Cristian Rodríguez]

El 05-11-2018 a las 3:17, piliu escribió:


During this service, the power state can not be got from sysfs, neither
it can be got by systemd's utility. So is it acceptable to signal the
failure of service by a tmp file under /tmp ? I.e adding
FailureAction=touch /tmp/poweroff_fail in systemd-poweroff.service.


No, that will likely race too.. please focus on why you think you need 
this contrieved,hackish solution.


If as you say in your other message, if you start just one operation, 
either reboot or poweroff but not both it will be ok.





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

Re: [systemd-devel] A question about the race condition between two service

[Cristian Rodríguez]

El 01-11-2018 a las 5:34, piliu escribió:


Any suggestion?



Yeah. Don't..if poweroff fails reboot will too..please attack the root 
cause of this problem.. why the machine fails to poweroff, is it a 
service blocking poweroff ? is there a kernel bug ?

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

Re: [systemd-devel] Run OpenVPN unprivileged as systemd user service

[Cristian Rodríguez]

El 01-11-2018 a las 9:41, Paul Menzel escribió:



If yes, do you have any hints before I start to dig into that?


opening TUN/TAP interfaces and changing routing is a privileged operation.

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

Re: [systemd-devel] bpfilter blocks root unmount during shutdown

[Cristian Rodríguez]

El 24-09-2018 a las 13:30, Andrei Borzenkov escribió:


This process is spawned as special kernel thread, even though it is
otherwise normal user process.


WUT ? So how is this new kind of task supposed to be handled by 
userspace ? looks like a kernel bug to me.




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

Re: [systemd-devel] How to build only udev

[Cristian Rodríguez]

El 04-07-2018 a las 15:42, Kevin Greene escribió:
Thanks Simon. I have tried doing that actually, but the arm64 version 
doesn't seem to be available. I'm on Ubuntu 16.04 fwiw.


Are you entirely sure that's the case?.. I mean.. you do not go very far 
without libudev-dev in a modern binary distribution like Ubuntu..pretty 
sure it must be available..


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

Re: [systemd-devel] [ty...@mit.edu: Re: Linux messages full of `random: get_random_u32 called from`]

[Cristian Rodríguez]

El 02-05-2018 a las 6:25, Lennart Poettering escribió:

On Di, 01.05.18 18:08, Vito Caputo (vcap...@pengaru.com) wrote:



Or maybe this confusion is just another iteration of the stuff
dicussed here? https://github.com/systemd/systemd/issues/4167


On modern x86 hardware we could fallback to rdrand but only when 
getrandom returns EAGAIN.


For other non-cryptographic uses maybe implementing xoroshiro128+ or 
Mersenne Twister would suffice, until libc gets a sane random interface 
if ever.

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

Re: [systemd-devel] SSL handshake error from offlineimap when using systemd to initialize

[Cristian Rodríguez]

El 21-01-2018 a las 8:12, Yubin Ruan escribió:

Hi,

I use offlineimap to synchronize my emails. I want it to do a synchronization
at system startup so recently I add a systemd service for it. However I always
get error like this:

EOF occurred in violation of protocol (_ssl.c:590)


Socket was closed but not the SSL session.. not a systemd problem..


Currently I don't know what the problem is, but:

 1. usually (after system startup) the same service is invoked by a timer
 and it works well so there is no problem with the script.


It is racing against initial network setup.. once the network settles it 
works as expected.




 2. I believe the network is reachable, because the system will
 auto-connect WIFI after system startup. Maybe the initialization order is
 not configured properly? If so please see my mail service file below.


You may want to order your services after network-online and enable the 
systemd-network-online service.. however that may still race.


I heard that to perform a SSL handshake the system have to contain some
randomness (such that some random keys can be generated),


Correct, but any of the ssl libraries in linux will inmediately return 
or terminate the process in case of a entropy failure, because such 
failure is fatal and the whole security of the ssl session is screwed.




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

Re: [systemd-devel] Required kernel version for pid1 only?

[Cristian Rodríguez]

El 09-01-2018 a las 5:35, 林自均 escribió:

Hi Zbyszek and Mantas,

I got it. Thank you for the detailed answers.

John Lin


Note that unless you have a kernel supported by a reliable distributor 
you should not use anything older than what kernel.org tells you to.


You probably want instead to fix whatever code that prevents you from 
running an "stable" supported kernel.


Whatever effort you do to forward port your code is probably worth it, 
on the contrary attempting to maintain an old kernel release with your 
patches on top and keep it current with all hundreds of security fixes 
is going to be an extremely painful experience that you will regret 
unless you have the wallet, manpower and knowledge to do so.


Cheers.



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

Re: [systemd-devel] Packagekit crashes

[Cristian Rodríguez]

El 08-09-2017 a las 16:58, Robert Washbourne escribió:

On systemctl start packagekit:

packagekitd[18300]: failed to setup context: metadata expire time too 
small, has to be at least one second




I'm sorry if this is the wrong place to post, please point me in the 
right direction




Polkit is not part of systemd, ask on: 
http://lists.freedesktop.org/mailman/listinfo/polkit-devel list.


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

[systemd-devel] [PATCH] shared: add statx(2) to @file-system syscall filter list

[Cristian Rodríguez]

---
 src/shared/seccomp-util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/shared/seccomp-util.c b/src/shared/seccomp-util.c
index 29eb2b17d..0857f5907 100644
--- a/src/shared/seccomp-util.c
+++ b/src/shared/seccomp-util.c
@@ -403,6 +403,7 @@ const SyscallFilterSet 
syscall_filter_sets[_SYSCALL_FILTER_SET_MAX] = {
 "stat64\0"
 "stat\0"
 "statfs\0"
+"statx\0"
 "symlink\0"
 "symlinkat\0"
 "truncate64\0"
-- 
2.14.1

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

Re: [systemd-devel] systemd-udevd invoked oom-killer

[Cristian Rodríguez]

El 11-07-2017 a las 18:23, WANG Siyuan escribió:
> Hi, all
> systemd-udevd invoked oom-killer during Linux boot. I open debug message
> of systemd-udevd. But I can't find where the problem is. Could anybody
> help me? Thanks very much.

The oom-killer should never be invoked on udev at boot.. either you are
working in very memory constrained device or there is a problem in your
kernel/toolchain/etc build.

At least tell use what distribution are you using if any and/or what
systemd version, you could also disable the oom-killer on
systemd-udev.service..




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

Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

[Cristian Rodríguez]

El 20-03-2017 a las 10:26, D.S. Ljungmark escribió:
> I find your argument to be strange.
> 
> "The kernel has this functionality, please do not use it and rather
> reimplement it in every piece of userspace that ever needs it, because
> that's supposed to be more secure."
> 
> I simply don't buy your argument here.

I guess we can't please everyone.. next it will come the "systemd has
too many library dependencies" crowd :-|


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

Re: [systemd-devel] Systemctl causes Spark native thread creation issue

[Cristian Rodríguez]

El 20-02-2017 a las 18:44, Rao Vz escribió:
> Hi, Guys

> Any help is appreciated.
> 
Most likely you went over TasksMax.


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

Re: [systemd-devel] MYSQL SERVICE FAILED

[Cristian Rodríguez]

On Sat, Apr 30, 2016 at 3:32 PM, Alessandro Cellini  wrote:
> ***

> -- Unit mysql.service has failed.
> --
> -- The result is failed.


HI:

Neither the mysql package nor the mysql.service are provided by the
systemd project but by your distribution. please file a bug report if
one does not exists by the proper channels.

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

Re: [systemd-devel] about libmount

[Cristian Rodríguez]

On Thu, Nov 5, 2015 at 12:30 PM, Martin Pitt  wrote:
> Hello Yankun,
>
> yan...@iscas.ac.cn [2015-11-05 23:24 +0800]:
>> I can not find a available uri for systemd in china
>
> Sorry, but I don't understand at all what this means.

It may be blocked by internet censors..is that what you mean ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 3.7s for systemd-logind.service starting

[Cristian Rodríguez]

On Fri, Jul 3, 2015 at 5:00 AM, RayBloodworth  wrote:

>  From this boot chart, dbus.service starts after systemd-logind.service, but
> dbus.service takes littile time for launching.

This is a bug, fixed in v209.. commit
8f9c6fe5ff1d59001aecbf3fbf9ca0ed7ff28ba7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 3.7s for systemd-logind.service starting

[Cristian Rodríguez]

On Fri, Jul 3, 2015 at 2:05 AM, RayBloodworth  wrote:
> Hi, everyone
>
> I'm optimizing booting performance of my system.
>
> systemd version: 208
> platform: freescale i.MX6D Cortex-A9

Please test again with a current release, I doubt anyone here will
help if you are using an older release.


> I found "systemd-logind.service" takes about 3.7s for starting.
> Then I added many logs about system time and found that method
> "manager_connect_bus()" in logind.c takes 2.4718s.
>
> Method "dbus_bus_get_private()" in  "manager_connect_bus()"  blocks 2.3s
> ...
>
> Could anyone help me with this issue?

Your system is most likely overwhelmed by I/O
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SysVInit service migration to systemd

[Cristian Rodríguez]

On Mon, Jun 29, 2015 at 10:58 AM, Lesley Kimmel  wrote:
> Jonathan;
>
> Thanks for the background and information. Since you clearly seem to have a
> grasp of systemd please humour me with a few more questions (some of them
> slightly ignorant):
>
> a) Why are PID bad?

Because they pretend to work but they really don't.
This is because only a tiny portion of software implements pid file
creation correctly,
this is in part due to the lack of a FREEBSD-like pidfile_*()
interface that at least tries to be correct.

> b) Why are lock files bad?

Mostly because at least till the *very recent* advent of File-private
POSIX locks (un-POSIX locks)
the OS facilities were terrible.

> c) If a/b are so bad why did they persist for so many years in SysVInit?

Because sysvinit is unable to track processes, in that case you need
at least to know what is the PID of the deamon, in order to be able to
kill it:
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Weird udev issue: char device replaced by regular file on suspend

[Cristian Rodríguez]

On Thu, Jun 25, 2015 at 4:15 PM, Johannes Bauer  wrote:
> Hi list,
>
> I'm seeing a very odd issue with udev and I'm not really sure which
> component could/would be responsible -- udev is pretty much my only hope.
>

Probably GregKH can assist you with this problem, udev is not at fault
because it does not create device nodes since the advent of devtmpfs
and this is therefore a kernel bug.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why we need to read/save random seed?

[Cristian Rodríguez]

On Mon, Jun 15, 2015 at 12:33 PM, cee1  wrote:
> Hi,
>
> I maybe got confused.
>
> First, systemd-random-seed.service will save a "seed" from
> /dev/urandom when shutdown, and load that "seed" to /dev/urandom when
> next boot up.
>
> My questions are:
> 1. Can we not save a seed, but load a seed that is read from **
> /dev/random ** to ** /dev/urandom **?

No, at boot you do not have enough entropy to begin with.

> 2. Saving a seed on disk, and someone reads the content of it later,
> will this make the "urandom" predictable?

Yes, that's why the file is only readable by root.

> Talking about /dev/random, it consumes an internal entropy pool, some
> system events(disk reading/page fault, etc) enlarges this pool, am I
> right?

See this article http://www.2uo.de/myths-about-urandom/

> And write to /dev/random will mix the input data into the pool, but
> not enlarge it, right?

It is up to the kernel to "credit" the data written to it as entropy (or not)

  What benefits can it get when only mix data
> but not enlarge the entropy pool?

The data written to it may be predictable..

> 3.16+ will mix data from HWRNG, does it also enlarges the entropy pool?

Yes but it might not be given "credit" depending what the source is.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why we need to read/save random seed?

[Cristian Rodríguez]

On Sun, Jun 14, 2015 at 6:45 PM, Greg KH  wrote:
> On Sun, Jun 14, 2015 at 02:11:53PM -0300, Cristian Rodríguez wrote:
>> On Sun, Jun 14, 2015 at 1:43 PM, Greg KH  wrote:
>> > On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote:
>> >>
>> >> El jun. 14, 2015 10:21, "cee1"  escribió:
>> >> >
>> >> > Hi all,
>> >> >
>> >> > Why we need to read/save random seed? Can it be read from /dev/random 
>> >> > each
>> >> time?
>> >>
>> >> Because the kernel is borked and still is needs to be fed of entropy at 
>> >> system
>> >> startup by user space. Please read the random man page.
>> >>
>> >> I agree we shouldn't have to do this at all..
>> >
>> > Really?  And how do you suggest we "fix" the kernel when the hardware
>> > itself doesn't provide us with a proper random number "seed" in the
>> > first place?  What do you suggest we do instead?
>>
>> Las time I checked , it required this userspace help even when the
>> machine has rdrand/rdseed or when a virtual machine is fed from the
>> host using the virtio-rng driver.. (may take up to 60 seconds to
>> report
>> random: nonblocking pool is initialized) Any other possible solution
>> that I imagined involves either blocking and/or changes in the
>> behaviour visible to userspace and that is probably unacceptable
>> .
>
> Really?

Yes, this is why for example you will find an "haveged" dracut module
that SUSE added during the SLE 12 development. to start entropy feed
from user-space as early as possible
this is not because folks are crazy but because it took  way too long
to initialize at that time..

>A lot of changes went into seeding the initial random generator
> in the kernel in the past year, you might want to try it out again.

Sure, I will check it again..

>> The random-seed tool also does not increment the entropy count (It
>> writes to /dev/random instead of using the ioctls) so the ultimate
>> result is still a system with very little entropy to go on, only
>> starting rngd or haveged *very* early in the boot sequence seem to
>> help.
>
> Then why not fix the random-seed tool to use the correct interface?

yeah, I think we should take a look on this too.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why we need to read/save random seed?

[Cristian Rodríguez]

On Sun, Jun 14, 2015 at 1:43 PM, Greg KH  wrote:
> On Sun, Jun 14, 2015 at 12:49:55PM -0300, Cristian Rodríguez wrote:
>>
>> El jun. 14, 2015 10:21, "cee1"  escribió:
>> >
>> > Hi all,
>> >
>> > Why we need to read/save random seed? Can it be read from /dev/random each
>> time?
>>
>> Because the kernel is borked and still is needs to be fed of entropy at 
>> system
>> startup by user space. Please read the random man page.
>>
>> I agree we shouldn't have to do this at all..
>
> Really?  And how do you suggest we "fix" the kernel when the hardware
> itself doesn't provide us with a proper random number "seed" in the
> first place?  What do you suggest we do instead?

Las time I checked , it required this userspace help even when the
machine has rdrand/rdseed or when a virtual machine is fed from the
host using the virtio-rng driver.. (may take up to 60 seconds to
report
random: nonblocking pool is initialized) Any other possible solution
that I imagined involves either blocking and/or changes in the
behaviour visible to userspace and that is probably unacceptable
.
The random-seed tool also does not increment the entropy count (It
writes to /dev/random instead of using the ioctls) so the ultimate
result is still a system with very little entropy to go on, only
starting rngd or haveged *very* early in the boot sequence seem to
help.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why we need to read/save random seed?

[Cristian Rodríguez]

El jun. 14, 2015 10:21, "cee1"  escribió:
>
> Hi all,
>
> Why we need to read/save random seed? Can it be read from /dev/random
each time?

Because the kernel is borked and still is needs to be fed of entropy at
system startup by user space. Please read the random man page.

I agree we shouldn't have to do this at all..

> --
> Regards,
>
> - cee1
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Performance of systemctl status tab completion

[Cristian Rodríguez]

On Tue, Jun 2, 2015 at 1:18 PM, Chris Morgan  wrote:
> Hi all.
>
> systemd 216 here on an embedded arm system, 1ghz with a load of 60% or
> more. I enabled tab completion, because I really don't like to type,
> and quickly found out that something like:
>
> systemctl status xx

What shell are you using ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl as non-root

[Cristian Rodríguez]

On Thu, May 28, 2015 at 9:21 PM,   wrote:
> Brandon Philips  wrote on 05/28/2015 05:10:33 PM:
>> Access to the system dbus is controlled by dbus policies. You will
>> need to write a policy for giving this user access to the systemd1 object.
>>
>
> I compiled systemd without dbus support (--disable-dbus), and there is no
> dbus daemon or dbus lib on the system.

That's not what --disable-dbus means..please read the configure description..
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to wait for specific interface/IP?

[Cristian Rodríguez]

On Sat, May 23, 2015 at 1:03 PM, Ian Pilcher  wrote:
> Is there a simple way to make a service require that a specific network
> interface/IP address be active?

You have to wait for the *link* to be active, not for the interface..

> I have a manually set up bridge and dnsmasq configuration for my VM
> traffic, but dnsmasq is getting started before NetworkManager has
> configured the bridge and failing because it cannot bind to the bridge's
> IP address.

This is problem has more than one face..

1) Enable the NetworkManager-wait-online service
2) order dnsmasq after the network-online target.

But this is all a workaround.. you could configure dnsmasq not to fail
to bind on interfaces that are not yet available at the point the
daemon is started.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] core: if PR_SET_CHILD_SUBREAPER fails, log_error instead of warning

[Cristian Rodríguez]

It was a warning when we still supported kernel < 3.4. current
minimum version is 3.7.
---
 src/core/main.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/core/main.c b/src/core/main.c
index c39815b..3bebc98 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1608,9 +1608,7 @@ int main(int argc, char *argv[]) {
 if (arg_running_as == MANAGER_USER) {
 /* Become reaper of our children */
 if (prctl(PR_SET_CHILD_SUBREAPER, 1) < 0) {
-log_warning_errno(errno, "Failed to make us a 
subreaper: %m");
-if (errno == EINVAL)
-log_info("Perhaps the kernel version is too 
old (< 3.4?)");
+log_error_errno(errno, "Failed to make us a subreaper: 
%m");
 }
 }
 
-- 
2.4.1

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

Re: [systemd-devel] [PATCH] buildsys: remove always true autoconf checks

[Cristian Rodríguez]

On Thu, May 21, 2015 at 11:39 AM, Lennart Poettering
 wrote:
> On Tue, 19.05.15 20:17, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
>
>> All this checks are always true in any modernish linux system.
>> ---
>>  configure.ac | 11 ---
>>  1 file changed, 11 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 3efee22..cd6375b 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1293,17 +1293,6 @@ AC_CHECK_HEADERS_ONCE([valgrind/memcheck.h 
>> valgrind/valgrind.h])
>>  have_myhostname=no
>>  AC_ARG_ENABLE(myhostname, AS_HELP_STRING([--disable-myhostname], [disable 
>> nss-myhostname support]))
>>  if test "x$enable_myhostname" != "xno"; then
>> -AC_HEADER_STDC
>> -AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h
>> netinet/in.h stdlib.h string.h sys/socket.h sys/time.h unistd.h
>> nss.h sys/ioctl.h sys/auxv.h])
>
> sys/auxv.h at least is a relatively recent addition to glibc, hence
> simply removing this all appears too broad...

Right.. that's an oversight..

>
> Not sure however why this is in the enable_myhostname part however, it
> should just be moved up. Could you prep a patch that does that?

Sure.. stay tuned ;)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] buildsys: remove always true autoconf checks

[Cristian Rodríguez]

All this checks are always true in any modernish linux system.
---
 configure.ac | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3efee22..cd6375b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1293,17 +1293,6 @@ AC_CHECK_HEADERS_ONCE([valgrind/memcheck.h 
valgrind/valgrind.h])
 have_myhostname=no
 AC_ARG_ENABLE(myhostname, AS_HELP_STRING([--disable-myhostname], [disable 
nss-myhostname support]))
 if test "x$enable_myhostname" != "xno"; then
-AC_HEADER_STDC
-AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h netinet/in.h 
stdlib.h string.h sys/socket.h sys/time.h unistd.h nss.h sys/ioctl.h 
sys/auxv.h])
-
-AC_C_CONST
-AC_TYPE_SIZE_T
-AC_HEADER_TIME
-
-AC_FUNC_MALLOC
-AC_FUNC_SELECT_ARGTYPES
-AC_CHECK_FUNCS([gethostbyaddr gethostbyname gettimeofday inet_ntoa 
memset select socket strcspn strdup strerror strncasecmp strcasecmp strspn])
-
 have_myhostname=yes
 fi
 AM_CONDITIONAL(HAVE_MYHOSTNAME, [test "$have_myhostname" = "yes"])
-- 
2.4.1

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

Re: [systemd-devel] Reduce unit-loading time

[Cristian Rodríguez]

On Tue, May 19, 2015 at 5:39 PM, Cristian Rodríguez
 wrote:
> On Mon, May 18, 2015 at 7:24 AM, cee1  wrote:
>> 2015-05-17 17:45 GMT+08:00 Martin Pitt :
>>> Hello cee,
>>>
>>> cee1 [2015-05-16  0:46 +0800]:
>>>> Thanks for the suggestion, it was other processes running in parallel
>>>> which presumably consuming lots of IO, after sending SIGSTOP at the
>>>> first (and SIGCONT later), the unit loading time is decreased to
>>>> ~100ms.
>>>
>>> You probably want to use some readahead solution. We found that it
>>> makes a significant improvement on ARM boards with slow MMC cards.
>
> You could also
>
> posix_fadvise(fileno(f), 0, 0, POSIX_FADV_SEQUENTIAL);
> in the bits that load the unit file..the kernel is free to ignore that
> advice however.

This however.. won't be of any help, as the default readhead window is
128kb.. which is way bigger than any unit file.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Reduce unit-loading time

[Cristian Rodríguez]

On Mon, May 18, 2015 at 7:24 AM, cee1  wrote:
> 2015-05-17 17:45 GMT+08:00 Martin Pitt :
>> Hello cee,
>>
>> cee1 [2015-05-16  0:46 +0800]:
>>> Thanks for the suggestion, it was other processes running in parallel
>>> which presumably consuming lots of IO, after sending SIGSTOP at the
>>> first (and SIGCONT later), the unit loading time is decreased to
>>> ~100ms.
>>
>> You probably want to use some readahead solution. We found that it
>> makes a significant improvement on ARM boards with slow MMC cards.

You could also

posix_fadvise(fileno(f), 0, 0, POSIX_FADV_SEQUENTIAL);
in the bits that load the unit file..the kernel is free to ignore that
advice however.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] resolved crashes on SIGTERM

[Cristian Rodríguez]

On Mon, May 18, 2015 at 6:25 PM, Lennart Poettering
 wrote:

> Fixed in git. Please verify.

It is OK now.. Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] buildsys: Remove X_SERVER from AM_CPPFLAGS

[Cristian Rodríguez]

It is a leftover from multi-seat-x wrapper which is long
gone.
---
 Makefile.am | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 211ce6a..4639b2f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -203,7 +203,6 @@ AM_CPPFLAGS = \
-DSYSTEM_SLEEP_PATH=\"$(systemsleepdir)\" \
-DSYSTEMD_KBD_MODEL_MAP=\"$(pkgdatadir)/kbd-model-map\" \
-DSYSTEMD_LANGUAGE_FALLBACK_MAP=\"$(pkgdatadir)/language-fallback-map\" 
\
-   -DX_SERVER=\"$(bindir)/X\" \
-DUDEVLIBEXECDIR=\"$(udevlibexecdir)\" \
-DPOLKIT_AGENT_BINARY_PATH=\"$(bindir)/pkttyagent\" \
-DQUOTACHECK=\"$(QUOTACHECK)\" \
-- 
2.3.7

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

[systemd-devel] [PATCH] timedate: fix memory leak in timedated

[Cristian Rodríguez]

$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)

=
==396==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 928 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
#1 0x562a83ae60cf in bus_message_from_header 
src/libsystemd/sd-bus/bus-message.c:480
#2 0x562a83ae6f5a in bus_message_from_malloc 
src/libsystemd/sd-bus/bus-message.c:576
#3 0x562a83ad3cad in bus_socket_make_message 
src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message 
src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method 
src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)

Indirect leak of 77 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
#1 0x562a83ad418a in bus_socket_read_message 
src/libsystemd/sd-bus/bus-socket.c:963
#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#4 0x562a83b1f46d in sd_bus_call_method 
src/libsystemd/sd-bus/bus-convenience.c:94
#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#6 0x562a83aae1af in main src/timedate/timedated.c:730
#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)

Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
#1 0x562a83b0229b in bus_message_parse_fields 
src/libsystemd/sd-bus/bus-message.c:5382
#2 0x562a83ae7290 in bus_message_from_malloc 
src/libsystemd/sd-bus/bus-message.c:601
#3 0x562a83ad3cad in bus_socket_make_message 
src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message 
src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method 
src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)

SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).

This is due to missing  _cleanup_bus_message_unref_ in context_read_ntp()
---
 src/timedate/timedated.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index c5ebb4a..4e8ae94 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -182,7 +182,7 @@ static int context_write_data_local_rtc(Context *c) {
 
 static int context_read_ntp(Context *c, sd_bus *bus) {
 _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
-sd_bus_message *reply = NULL;
+_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
 const char *s;
 int r;
 
-- 
2.3.7

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

[systemd-devel] [PATCH] sd-bus: fix potential UB in bus_socket_auth_verify_client()

[Cristian Rodríguez]

When built with GCC undefined behaviour sanitizer the following problem
surfaces:

src/libsystemd/sd-bus/bus-socket.c:180:11: runtime error: null pointer
passed as argument 1, which is declared to never be null

Indeed, calling memmem where b->rbuffer == NULL is undefined behaviour.

Fix that by returning if rbuffer is null or rbuffer_size < 2
---
 src/libsystemd/sd-bus/bus-socket.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/libsystemd/sd-bus/bus-socket.c 
b/src/libsystemd/sd-bus/bus-socket.c
index 94a5c04..6463f7c 100644
--- a/src/libsystemd/sd-bus/bus-socket.c
+++ b/src/libsystemd/sd-bus/bus-socket.c
@@ -177,6 +177,9 @@ static int bus_socket_auth_verify_client(sd_bus *b) {
 /* We expect two response lines: "OK" and possibly
  * "AGREE_UNIX_FD" */
 
+if(!b->rbuffer || b->rbuffer_size < 2)
+return 0;
+
 e = memmem(b->rbuffer, b->rbuffer_size, "\r\n", 2);
 if (!e)
 return 0;
-- 
2.3.7

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

Re: [systemd-devel] [PATCH] sd-bus: fix memory leak in test-bus-chat

[Cristian Rodríguez]

On Wed, May 13, 2015 at 8:01 AM, Daniel Mack  wrote:

> We should still keep this flush, right?
>
>> -sd_bus_unref(bus);
>>  }
>>

The cleanup function already does :

static inline void sd_bus_close_unrefp(sd_bus **bus) {
   if (*bus) {
   sd_bus_flush(*bus);
   sd_bus_close(*bus);
   sd_bus_unref(*bus);
   }
}

Or I am missing something ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] core: fix memory leak in manager_run_generators()

[Cristian Rodríguez]

If systemd is built with GCC address sanitizer or leak sanitizer
the following memory leak ocurs:

May 12 02:02:46 linux.site systemd[326]: 
=
May 12 02:02:46 linux.site systemd[326]: ==326==ERROR: LeakSanitizer: detected 
memory leaks
May 12 02:02:46 linux.site systemd[326]: Direct leak of 101 byte(s) in 3 
object(s) allocated from:
May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup 
(/usr/lib64/libasan.so.2+0x6293f)
May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5336 in strv_new_ap 
src/shared/strv.c:163
May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new 
src/shared/strv.c:185
May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths 
src/shared/path-lookup.c:223
May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in 
manager_run_generators src/core/manager.c:2828
May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup 
src/core/manager.c:1121
May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main 
src/core/main.c:1667
May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main 
(/lib64/libc.so.6+0x208c4)
May 12 02:02:46 linux.site systemd[326]: Direct leak of 29 byte(s) in 1 
object(s) allocated from:
May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup 
(/usr/lib64/libasan.so.2+0x6293f)
May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5288 in strv_new_ap 
src/shared/strv.c:152
May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new 
src/shared/strv.c:185
May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths 
src/shared/path-lookup.c:223
May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in 
manager_run_generators src/core/manager.c:2828
May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup 
src/core/manager.c:1121
May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main 
src/core/main.c:1667
May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main 
(/lib64/libc.so.6+0x208c4)
May 12 02:02:46 linux.site systemd[326]: SUMMARY: AddressSanitizer: 130 byte(s) 
leaked in 4 allocation(s).

There is a leak due to the the use of cleanup_free instead _cleanup_strv_free_
---
 src/core/manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/core/manager.c b/src/core/manager.c
index 28b9427..8254090 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2815,7 +2815,7 @@ static void trim_generator_dir(Manager *m, char 
**generator) {
 }
 
 static int manager_run_generators(Manager *m) {
-_cleanup_free_ char **paths = NULL;
+_cleanup_strv_free_ char **paths = NULL;
 const char *argv[5];
 char **path;
 int r;
-- 
2.3.7

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

[systemd-devel] resolved crashes on SIGTERM

[Cristian Rodríguez]

resolved crashes on SIGTERM with ...

=
==33557==ERROR: AddressSanitizer: heap-use-after-free on address
0x60c0bd60 at pc 0x556098c5 bp 0x7fffde70 sp
0x7fffde68
READ of size 8 at 0x60c0bd60 thread T0
   #0 0x556098c4 in dns_cache_flush src/resolve/resolved-dns-cache.c:88
   #1 0x555e123d in link_set_dns_server src/resolve/resolved-link.c:321
   #2 0x55608c7e in dns_server_free src/resolve/resolved-dns-server.c:96
   #3 0x555df543 in link_free src/resolve/resolved-link.c:76
   #4 0x555cf138 in manager_free src/resolve/resolved-manager.c:531
   #5 0x555cb5e7 in manager_freep src/resolve/resolved-manager.h:151
   #6 0x555cbd58 in main src/resolve/resolved.c:32
   #7 0x75d6586f in __libc_start_main (/lib64/libc.so.6+0x2086f)
   #8 0x555cb498 in _start
(/home/crrodriguez/scm/systemd/systemd-resolved+0x77498)

0x60c0bd60 is located 32 bytes inside of 128-byte region
[0x60c0bd40,0x60c0bdc0)
freed by thread T0 here:
   #0 0x76f049aa in __interceptor_free (/usr/lib64/libasan.so.2+0x969aa)
   #1 0x556021a9 in dns_scope_free src/resolve/resolved-dns-scope.c:97
   #2 0x555df4a2 in link_free src/resolve/resolved-link.c:71
   #3 0x555cf138 in manager_free src/resolve/resolved-manager.c:531
   #4 0x555cb5e7 in manager_freep src/resolve/resolved-manager.h:151
   #5 0x555cbd58 in main src/resolve/resolved.c:32
   #6 0x75d6586f in __libc_start_main (/lib64/libc.so.6+0x2086f)

previously allocated by thread T0 here:
   #0 0x76f04db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
   #1 0x55601785 in dns_scope_new src/resolve/resolved-dns-scope.c:41
   #2 0x555df67b in link_allocate_scopes src/resolve/resolved-link.c:89
   #3 0x555e0933 in link_update_monitor src/resolve/resolved-link.c:248
   #4 0x555cc591 in manager_process_link src/resolve/resolved-manager.c:78
   #5 0x555cd267 in manager_rtnl_listen src/resolve/resolved-manager.c:235
   #6 0x555cefbc in manager_new src/resolve/resolved-manager.c:498
   #7 0x555cba15 in main src/resolve/resolved.c:75
   #8 0x75d6586f in __libc_start_main (/lib64/libc.so.6+0x2086f)

SUMMARY: AddressSanitizer: heap-use-after-free
src/resolve/resolved-dns-cache.c:88 dns_cache_flush
Shadow bytes around the buggy address:
 0x0c187fff9750: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
 0x0c187fff9760: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
 0x0c187fff9770: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
 0x0c187fff9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
 0x0c187fff9790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c187fff97a0: fa fa fa fa fa fa fa fa fd fd fd fd[fd]fd fd fd
 0x0c187fff97b0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
 0x0c187fff97c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0c187fff97d0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
 0x0c187fff97e0: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
 0x0c187fff97f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
 Addressable:   00
 Partially addressable: 01 02 03 04 05 06 07
 Heap left redzone:   fa
 Heap right redzone:  fb
 Freed heap region:   fd
 Stack left redzone:  f1
 Stack mid redzone:   f2
 Stack right redzone: f3
 Stack partial redzone:   f4
 Stack after return:  f5
 Stack use after scope:   f8
 Global redzone:  f9
 Global init order:   f6
 Poisoned by user:f7
 Container overflow:  fc
 Array cookie:ac
 Intra object redzone:bb
 ASan internal:   fe
==33557==ABORTING

apparently, it crashes on

void dns_cache_flush(DnsCache *c) {
   DnsCacheItem *i;

   assert(c);

   while ((i = hashmap_first(c->by_key))) --> here, because
c->by_key was already free'd at this point.. can someone familiar thr
the code look at this ?


to reproduce, build with --enable-address-sanitizer , start resolved
in gdb .. then send SIGTERM to the running binary..
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] modules-load: fix memory leak

[Cristian Rodríguez]

=
==64281==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f623c961c4a in malloc (/usr/lib64/libasan.so.2+0x96c4a)
#1 0x5651f79ad34e in malloc_multiply 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x2134e)
#2 0x5651f79b02d6 in strjoin 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x242d6)
#3 0x5651f79be1f5 in files_add 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x321f5)
#4 0x5651f79be6a3 in conf_files_list_strv_internal 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x326a3)
#5 0x5651f79bea24 in conf_files_list_nulstr 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x32a24)
#6 0x5651f79ad01a in main 
(/home/crrodriguez/scm/systemd/systemd-modules-load+0x2101a)
#7 0x7f623c11586f in __libc_start_main (/lib64/libc.so.6+0x2086f)

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).

This happens due to the wrong cleanup attribute is used (free vs strv_free)
---
 src/modules-load/modules-load.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/modules-load/modules-load.c b/src/modules-load/modules-load.c
index 76e9403..5bbe314 100644
--- a/src/modules-load/modules-load.c
+++ b/src/modules-load/modules-load.c
@@ -252,7 +252,7 @@ int main(int argc, char *argv[]) {
 }
 
 } else {
-_cleanup_free_ char **files = NULL;
+_cleanup_strv_free_ char **files = NULL;
 char **fn, **i;
 
 STRV_FOREACH(i, arg_proc_cmdline_modules) {
-- 
2.3.7

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

[systemd-devel] [PATCH] shared: Use O_EXCL with O_TMPFILE in open_tmpfile

[Cristian Rodríguez]

In this usecase, the file will never be materialized
with linkat().
---
 src/shared/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index c5c1b0c..f295edb 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -4838,7 +4838,7 @@ int open_tmpfile(const char *path, int flags) {
 
 #ifdef O_TMPFILE
 /* Try O_TMPFILE first, if it is supported */
-fd = open(path, flags|O_TMPFILE, S_IRUSR|S_IWUSR);
+fd = open(path, flags|O_TMPFILE|O_EXCL, S_IRUSR|S_IWUSR);
 if (fd >= 0)
 return fd;
 #endif
-- 
2.3.7

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

[systemd-devel] [PATCH] sd-bus: fix memory leak in test-bus-chat

[Cristian Rodríguez]

Building with address sanitizer enabled on GCC 5.1.x a memory leak
is reported because we never close the bus, fix it by using
cleanup variable attribute.
---
 src/libsystemd/sd-bus/test-bus-chat.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/libsystemd/sd-bus/test-bus-chat.c 
b/src/libsystemd/sd-bus/test-bus-chat.c
index 99261fa..1e50dfc 100644
--- a/src/libsystemd/sd-bus/test-bus-chat.c
+++ b/src/libsystemd/sd-bus/test-bus-chat.c
@@ -262,7 +262,7 @@ fail:
 
 static void* client1(void*p) {
 _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
-sd_bus *bus = NULL;
+_cleanup_bus_close_unref_ sd_bus *bus = NULL;
 sd_bus_error error = SD_BUS_ERROR_NULL;
 const char *hello;
 int r;
@@ -345,8 +345,6 @@ finish:
 else
 sd_bus_send(bus, q, NULL);
 
-sd_bus_flush(bus);
-sd_bus_unref(bus);
 }
 
 sd_bus_error_free(&error);
-- 
2.3.7

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

[systemd-devel] [PATCH] buildsys: *_la_CPPFLAGS takes $(AM_CPPFLAGS) not $(AM_CFLAGS)

[Cristian Rodríguez]

---
 Makefile.am | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 1ec1e77..e4d00a8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6333,7 +6333,7 @@ libsystemd_journal_la_SOURCES = \
src/compat-libs/libsystemd-journal.sym
 
 libsystemd_journal_la_CPPFLAGS = \
-   $(AM_CFLAGS) \
+   $(AM_CPPFLAGS) \
-imacros$(top_srcdir)/src/compat-libs/linkwarning.h
 
 libsystemd_journal_la_LDFLAGS = \
@@ -6351,7 +6351,7 @@ libsystemd_login_la_SOURCES = \
src/compat-libs/libsystemd-login.sym
 
 libsystemd_login_la_CPPFLAGS = \
-   $(AM_CFLAGS) \
+   $(AM_CPPFLAGS) \
-imacros$(top_srcdir)/src/compat-libs/linkwarning.h
 
 libsystemd_login_la_LDFLAGS = \
@@ -6368,7 +6368,7 @@ libsystemd_id128_la_SOURCES = \
src/compat-libs/libsystemd-id128.sym
 
 libsystemd_id128_la_CPPFLAGS = \
-   $(AM_CFLAGS) \
+   $(AM_CPPFLAGS) \
-imacros$(top_srcdir)/src/compat-libs/linkwarning.h
 
 libsystemd_id128_la_LDFLAGS = \
@@ -6385,7 +6385,7 @@ libsystemd_daemon_la_SOURCES = \
src/compat-libs/libsystemd-daemon.sym
 
 libsystemd_daemon_la_CPPFLAGS = \
-   $(AM_CFLAGS) \
+   $(AM_CPPFLAGS) \
-imacros$(top_srcdir)/src/compat-libs/linkwarning.h
 
 libsystemd_daemon_la_LDFLAGS = \
-- 
2.3.7

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

[systemd-devel] [PATCH] po: Remove src/fsckd/fsckd.c from filelist

[Cristian Rodríguez]

Otherwise make check ends in failed state.
---
 po/POTFILES.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/po/POTFILES.in b/po/POTFILES.in
index 70e7594..b4c1121 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -5,4 +5,3 @@ src/locale/org.freedesktop.locale1.policy.in
 src/login/org.freedesktop.login1.policy.in
 src/machine/org.freedesktop.machine1.policy.in
 src/timedate/org.freedesktop.timedate1.policy.in
-src/fsckd/fsckd.c
-- 
2.3.7

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

[systemd-devel] [PATCH] tree-wide: Introduce a dup_cloexec inline helper

[Cristian Rodríguez]

- Nicer & easier to remember than fcntl(fd, F_DUPFD_CLOEXEC, 3)
- Update CODING_STYLE
- Use it tree-wide
---
 CODING_STYLE | 6 +++---
 src/import/curl-util.c   | 2 +-
 src/import/importd.c | 4 ++--
 src/journal/cat.c| 2 +-
 src/libsystemd-terminal/grdev-drm.c  | 4 ++--
 src/libsystemd-terminal/idev-evdev.c | 4 ++--
 src/libsystemd/sd-bus/bus-message.c  | 6 +++---
 src/login/inhibit.c  | 2 +-
 src/login/pam_systemd.c  | 2 +-
 src/run/run.c| 2 +-
 src/shared/copy.c| 2 +-
 src/shared/fdset.c   | 2 +-
 src/shared/install.c | 2 +-
 src/shared/util.h| 5 +
 14 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/CODING_STYLE b/CODING_STYLE
index a295ca7..19891ce 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -233,12 +233,12 @@
   fork()ed off a child process, please use _exit() instead of exit(),
   so that the exit handlers are not run.
 
-- Please never use dup(). Use fcntl(fd, F_DUPFD_CLOEXEC, 3)
-  instead. For two reason: first, you want O_CLOEXEC set on the new fd
+- Please never use dup(). Use the dup_cloexec() helper instead.
+  For two reasons: first, you want O_CLOEXEC set on the new fd
   (see above). Second, dup() will happily duplicate your fd as 0, 1,
   2, i.e. stdin, stdout, stderr, should those fds be closed. Given the
   special semantics of those fds, it's probably a good idea to avoid
-  them. F_DUPFD_CLOEXEC with "3" as parameter avoids them.
+  them.
 
 - When you define a destructor or unref() call for an object, please
   accept a NULL object and simply treat this as NOP. This is similar
diff --git a/src/import/curl-util.c b/src/import/curl-util.c
index d390cfb..dfa5acc 100644
--- a/src/import/curl-util.c
+++ b/src/import/curl-util.c
@@ -131,7 +131,7 @@ static int curl_glue_socket_callback(CURLM *curl, 
curl_socket_t s, int action, v
  * anymore. Hence, duplicate the fds here, and keep a
  * copy for epoll which we control after use. */
 
-fd = fcntl(s, F_DUPFD_CLOEXEC, 3);
+fd = dup_cloexec(s);
 if (fd < 0)
 return -1;
 
diff --git a/src/import/importd.c b/src/import/importd.c
index d4da4b2..416a43c 100644
--- a/src/import/importd.c
+++ b/src/import/importd.c
@@ -765,7 +765,7 @@ static int method_import_tar_or_raw(sd_bus *bus, 
sd_bus_message *msg, void *user
 if (!t->local)
 return -ENOMEM;
 
-t->stdin_fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+t->stdin_fd = dup_cloexec(fd);
 if (t->stdin_fd < 0)
 return -errno;
 
@@ -826,7 +826,7 @@ static int method_export_tar_or_raw(sd_bus *bus, 
sd_bus_message *msg, void *user
 if (!t->local)
 return -ENOMEM;
 
-t->stdout_fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+t->stdout_fd = dup_cloexec(fd);
 if (t->stdout_fd < 0)
 return -errno;
 
diff --git a/src/journal/cat.c b/src/journal/cat.c
index 2e236f0..9e26e7c 100644
--- a/src/journal/cat.c
+++ b/src/journal/cat.c
@@ -138,7 +138,7 @@ int main(int argc, char *argv[]) {
 goto finish;
 }
 
-saved_stderr = fcntl(STDERR_FILENO, F_DUPFD_CLOEXEC, 3);
+saved_stderr = dup_cloexec(STDERR_FILENO);
 
 if (dup3(fd, STDOUT_FILENO, 0) < 0 ||
 dup3(fd, STDERR_FILENO, 0) < 0) {
diff --git a/src/libsystemd-terminal/grdev-drm.c 
b/src/libsystemd-terminal/grdev-drm.c
index 066a4d8..deb7e94 100644
--- a/src/libsystemd-terminal/grdev-drm.c
+++ b/src/libsystemd-terminal/grdev-drm.c
@@ -2782,7 +2782,7 @@ static int managed_card_resume_device_fn(sd_bus *bus,
  * TakeDevice(). However, lets be safe and use this FD in case
  * we really don't have one. There is no harm in doing this
  * and our code works fine this way. */
-fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+fd = dup_cloexec(fd);
 if (fd < 0) {
 log_debug_errno(errno, "grdrm: %s/%s: cannot duplicate 
fd: %m",
 session->name, cm->card.base.name);
@@ -2874,7 +2874,7 @@ static int managed_card_take_device_fn(sd_bus *bus,
 return 0;
 }
 
-fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+fd = dup_cloexec(fd);
 if (fd < 0) {
 log_debug_errno(errno, "grdrm: %s/%s: cannot duplicate fd: %m",
 session->name, cm->card.base.name);
diff --git a/src/libsystemd-terminal/idev-evdev.c 
b/src/libsystemd-terminal/idev-evdev.c
index 91ae507..c49ba90 100644
--- a/src/libsystemd-terminal/idev-evdev.c
+++ b/src/libsystemd-terminal/idev-evdev.c
@@ -559,7 +559,7 @@ static int managed_evdev_take_device_fn(sd_bus *bus,
 if (paused)
 return 0;
 
-fd = 

Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Cristian Rodríguez]

On Fri, Apr 17, 2015 at 4:06 PM, Matt Hoosier  wrote:
> On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering
>  wrote:
>>
>> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@gmail.com) wrote:
>>
>> > Hi,
>> >
>> > I'm writing to see whether there's a "best" way to allow systemd to
>> > inherit
>> > ownership of a process forked from a hand-crafted /sbin/init process
>> > before
>> > that hand-crafted process turns over the keys to systemd by doing
>> > exec("/lib/systemd/systemd") over the top of itself and allowing it to
>> > take
>> > over as PID 1.
>>
>> We support this only really for "kernel-like" processes that are
>> started from the initrd, and basically run as long as the system is up
>> without every being restarted in between, thus effectively appearing
>> much like a kernel process and nothing systemd should
>> manage. Processes like this should be marked with argv[0][0] = '@',
>> see for details:
>>
>> https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/
>>
>> > I know that sounds like an odd thing to ask about. The use-case has to
>> > do
>> > with being able to start some work extremely early during boot of
>> > embedded
>> > systems to achieve performance goals. I don't wish to subvert systemd,
>> > and
>> > in fact would love for systemd to be able to monitor the process, stop
>> > it,
>> > restart according to the normal [Service] configuration in a unit file
>> > describing the process.
>>
>> Hmm, are you sure that invoking the binary from systemd as first
>> service is really that much slower than starting systemd only afterwards?
>
>
> The bootcharting that I do seems to show that about 1.2 - 1.5 sec are spent
> internal to systemd before any external processes get run for the particular
> embedded CPU I'm using. That gap is a killer at the moment.

Did you watch this presentation ?

https://www.youtube.com/watch?v=RFVlbaDqll8

what part of systemd is taking 1.5 seconds to start, on what CPU and
how much of RAM does the board has ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Cristian Rodríguez]

On Fri, Apr 17, 2015 at 7:51 AM, Lennart Poettering
 wrote:

> Groups *suck* as authentication scheme. If you add one group for each
> privilege you want, then you'll have a huge number of groups, and
> that's hardly desirable. It's pretty close to being unmanagable with
> user/group editors. Also, you can never take group membership away,
> since users who once where members of group can create sgid binaries
> which allows them to always return into that group forever.

Not to mention, we are running out of system users and groups in
distributions (if we didn't already) and some people want us to
provide fixed UID/GID system users
across distributions for clustering applications...this is a totally
unworkable way forward.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Check if systems is container in "systemd-remount-fs.service"

[Cristian Rodríguez]

On Wed, Apr 8, 2015 at 6:55 PM, Lennart Poettering
 wrote:
> On Tue, 17.03.15 10:54, Peter Paule (systemd-de...@fedux.org) wrote:
>
>> Hi,
>>
>> does it make sense to check if the system is started as a container in
>> "systemd-remount-fs.service" and only start the service if the system is NOT
>> a container?
>
> Why?
The service always fail when running in a container.. for example

systemd-nspawn -D / -xb

Apr 08 23:59:30 xps15z systemd-remount-fs[16]: /bin/mount for / exited
with exit status 1.
Apr 08 23:59:30 xps15z systemd-remount-fs[16]: mount: can't find
UUID=01a467ea-82ff-4d5a-a8a1-f2fb4e797ea0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] hwdb: ship ids-update.pl & sdio.ids in the release tarballs.

[Cristian Rodríguez]

On Fri, Mar 20, 2015 at 3:02 AM, Michael Biebl  wrote:

> Are you saying https://pci-ids.ucw.cz/v2.2/pci.ids is wrong in adding
> a license header?

Just like the timezone database this file collects facts  (hardware X
by manufacturer Y has ID Z) into a machine readable form.. this is
non-copyrightable.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd

[Cristian Rodríguez]

On Mon, Mar 2, 2015 at 12:48 PM, Jordan Hargrave  wrote:
> It would be nice if systemd could discover and display enclosure/bay slot
> mappings for drives in the system.  The /dev/disk/by-path method doesn't
> quite work, for SAS drives the ID can change on hotplug.  The slot mapping
> also doesn't handle PCIe SSD devices as they are bare block devices and
> don't use SCSI midlayer.  Proposing to add support for something like
> /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices.

As far as I am aware, no new things dealing with storage naming rules
will be added to udev/systemd, it has to go to whatever other
project..(sg3_utils last time I checked)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] journal: fix Inappropriate ioctl for device on ext4

[Cristian Rodríguez]

Logs constantly show

systemd-journald[395]: Failed to set file attributes: Inappropriate
ioctl for device

This is because ext4 does not support FS_NOCOW_FL.
---
 src/journal/journal-file.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 9c9a548..ecabfd3 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -2610,7 +2610,8 @@ int journal_file_open(
  * checksumming). */
 r = chattr_fd(f->fd, true, FS_NOCOW_FL);
 if (r < 0)
-log_warning_errno(errno, "Failed to set file 
attributes: %m");
+if(r != -ENOTTY)
+log_warning_errno(errno, "Failed to set file 
attributes: %m");
 
 /* Let's attach the creation time to the journal file,
  * so that the vacuuming code knows the age of this
-- 
2.3.0

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

Re: [systemd-devel] tmpfiles.d specifier support on "argument" when operating on files

[Cristian Rodríguez]

On Wed, Feb 18, 2015 at 6:17 PM, Cristian Rodríguez
 wrote:

> Is the attached version cool for you ?

Ping ? Any comments about this one ? note that implementing the
specifier expansion in all cases for "argument" does not make sense to
me unless I am missing something .
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] feature request: dlopen

[Cristian Rodríguez]

El 22/02/15 a las 22:37, Luke Kenneth Casson Leighton escribió:



  well, you could provide hints in the documentation (and force them to
be read by deliberately changing the API)


Wow.. so what you want is even nuttier than I thought..


that would be a good place to start, showing people how to begin the
process of dlopen()ing libsystemd0, documenting it well so that it was
easy to follow.


No, again. using dlopen with libsystemd is crazy, you will only turn 
software even more complex and ugly than already is. and with this 
little gem:


-- a/Makefile.am
+++ b/Makefile.am
@@ -3046,7 +3046,7 @@ libsystemd_la_CFLAGS = \
$(libsystemd_journal_internal_la_CFLAGS)

 libsystemd_la_LDFLAGS = \
-   $(AM_LDFLAGS) \
+   $(AM_LDFLAGS) -Wl,-z,nodlopen \

we can stop the madness from becoming reality :-)



  * distros are forced to follow suit on upstream decisions, without
consulting what any other distros do


No, distros are welcome to come here and influence the direction of the 
project and its components, before reality imposes itself. those who do 
the work, make decisions.




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

Re: [systemd-devel] feature request: dlopen

[Cristian Rodríguez]

El 22/02/15 a las 23:08, Luke Kenneth Casson Leighton escribió:


  the problem, zbigniew, is that the intended use of this "silent noop"
feature - to make it *possible* to have an alternative PID1 - *hasn't
happened*.  any upstream software developer who has added in support
for systemd has done so by *ripping out* the former alternative code.
not a single upstream system that i've seen has done *any* kind of
run-time detection *at all*.  it's all compile-time.


This is because software is written mostly by sane people who has at 
least a clue about what they are doing and talking, they are not doing 
what you wish, because what you are proposing is batshit insane.




  aside from getting the message across to upstream developers about
doing runtime detection, i feel that what you guys really need to do
is to set up conferences with everyone, to talk - urgently - about
ways to ensure that the alternative systems which the wholesale
adoption of systemd has excluded may be reinstated as *runtime*
choices (not compile-time).


Ha! that's a funny one.. why should we do that? the burden on doing that 
is on the people that want this theorical alternatives.


 that may mean discussing a set of APIs

that end up being DL'd (like PAM is, right now),


PAM is not dlopen'ed.. pam *modules* are.. and PAM is not something to 
cite as an example how to do things *today* in 2015..



the situation now is one where people believe that systemd is being
heavily promoted to the exclusion of all other PID1 alternatives,
developed with a focus on fedora / redhat to the exclusion of all
other distros, developed for desktop systems *only* to the exclusion
of servers and embedded systems... it's no wonder that there's a lot
of upset people in the software libre community!


You dropped your tinfoil hat now..


  i know it sounds weird to go backwards, but the situation is -
amongst other not very nice things - that the GNU/Linux world now has
a new monoculture attack vector at the PID1 level in code that's
being *actively developed and extended, dramatically*.



Please go and learn how and particulary *why* things work a certain way 
before telling people how to do it, in fact don't tell.. .post patches 
or experiment yourself.


You can dlopen systemd libraries at your own risk, if you know exactly 
what you are doing and why it will work..in most cases it will end in a 
terrible mess that we will get the blame for it.. I just wrote a patch 
to disallow dlopen of libsystemd alltogether..I hope it won't be needed 
because I still trust developers not to be that misguided.









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

[systemd-devel] [PATCH 8/9] shared: AFS is also a network filesystem

[Cristian Rodríguez]

---
 src/shared/util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/shared/util.c b/src/shared/util.c
index dc65280..6729461 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1692,6 +1692,7 @@ bool chars_intersect(const char *a, const char *b) {
 
 bool fstype_is_network(const char *fstype) {
 static const char table[] =
+"afs\0"
 "cifs\0"
 "smbfs\0"
 "sshfs\0"
-- 
2.3.0

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

[systemd-devel] [PATCH] shared: fix wrong assertion in barrier_set_role()

[Cristian Rodríguez]

 assert(b->pipe[0] >= 0 && b->pipe[0] >= 0);

Test the same condition twice, pretty sure we mean

 assert(b->pipe[0] >= 0 && b->pipe[1] >= 0);
---
 src/shared/barrier.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/shared/barrier.c b/src/shared/barrier.c
index f65363a..b7dca75 100644
--- a/src/shared/barrier.c
+++ b/src/shared/barrier.c
@@ -178,7 +178,7 @@ void barrier_set_role(Barrier *b, unsigned int role) {
 assert(b);
 assert(role == BARRIER_PARENT || role == BARRIER_CHILD);
 /* make sure this is only called once */
-assert(b->pipe[1] >= 0 && b->pipe[1] >= 0);
+assert(b->pipe[0] >= 0 && b->pipe[1] >= 0);
 
 if (role == BARRIER_PARENT)
 b->pipe[1] = safe_close(b->pipe[1]);
-- 
2.3.0

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