[systemd-devel] (no subject)

[Marc]

stop putting this useless shit in dmesg

out-of-date, rotating.
[60542.641705] systemd-journald[493]: Data hash table of 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill 
level at 75.0 (7568 of 10090 items, 5812224 file size, 768 bytes per hash table 
item), suggesting rotation.
[60542.641724] systemd-journald[493]: 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal 
header limits reached or header out-of-date, rotating.
[64142.308221] systemd-journald[493]: Data hash table of 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill 
level at 75.1 (7574 of 10090 items, 5812224 file size, 767 bytes per hash table 
item), suggesting rotation.
[64142.308244] systemd-journald[493]: 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal 
header limits reached or header out-of-date, rotating.
[67622.472249] systemd-journald[493]: Data hash table of 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill 
level at 75.0 (7568 of 10090 items, 5812224 file size, 768 bytes per hash table 
item), suggesting rotation.
[67622.472273] systemd-journald[493]: 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal 
header limits reached or header out-of-date, rotating.
[71582.874668] systemd-journald[493]: Data hash table of 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill 
level at 75.0 (7569 of 10090 items, 5812224 file size, 767 bytes per hash table 
item), suggesting rotation.
[71582.874687] systemd-journald[493]: 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal 
header limits reached or header out-of-date, rotating.
[75362.841598] systemd-journald[493]: Data hash table of 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill 
level at 75.0 (7569 of 10090 items, 5812224 file size, 767 bytes per hash table 
item), suggesting rotation.
[75362.841613] systemd-journald[493]: 
/run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal 
header limits reached or header out-of-date, rotating.

Re: [systemd-devel] (no subject)

[Mantas Mikulėnas]

On Tue, Oct 17, 2023 at 7:33 AM Tim Richardson 
wrote:

> There is a long standing and long bug report in Ubuntu which attributes
> the inability to start the Firefox snap (or any snap with sandboxing) to
> snapd.
> In fact, the users having this problem mostly have in common that their
> session is started with a remote desktop session.
> such as
> nomachine (workstation, which starts a virtual session) and x2go, and
> sometimes various vnc connections, those which spawn remote sessions rather
> than screen sharing an existing session, I suspect.
>
> Comment 17 implies that the problem is the user session is not being setup
> correctly.
> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/comments/17
>
>
> An expert commentor Maciej Borzecki said:
> I've commented before, but if your desktop session is correctly set up,
> the systemd --user instance should be available, then a transient scope
> can be created for snap and proper device access filtering can be set up
> in that cgroup, thus completing the sandbox. Cgroup v1 works
> differently, in that there is a separate hierarchy which could be set up
> for a snap and there's no need to ask ssytemd to set up anything on
> behalf of the snap. This is no longer the case for v2.
>
> AFAICT gdm/kdm/xdm seem to be able to do that correctly. Most trouble
> seems to be coming from X2go/vnc or similar solutions which appear to
> give you a desktop access, but it's half baked, and are either missing
> session dbus or the systemd --user instance. Perhaps it's not really
> going through PAM, hence things that would have been set up through
> pam_systemd are missing.
>
> Specifically, the environment variable DBUS_SESSION_BUS_ADDRESS is not
> correct.
>
> A typical fix is for users to do this:
>
> export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"
>
>
> before running the snap.
> snaps are surfacing this problem for some reason but I don't think it is
> snap problem. When the snap launches it finds itself in an unexpected
> cgroup.
>
> In one of my experiments, running systemd --user in a shell and starting a
> snap from there worked. It was when I compared the environment generated
> here vs the environment after logging in via nomachine that I discovered
> the workaround of exporting that variable. But it is not a very good
> workaround. It only allows one session per user, for instance.
>
> I think the problem is in the login stage, as Maciej says.
> I can't find documentation on how the "modern" login process works, at
> least detailed enough to explain how you make sure the pam_systemd setup is
> invoked. I got lost in the scripts trying to work it out.
>

The steps needed from login services are not any different from what it was
before systemd, really. When a network service needs to verify a password,
it loads libpam and calls "pam_authenticate()"; when it needs to verify the
user's access rights it calls "pam_acct_mgmt()"; and when it needs to
initialize the various environment for the freshly logged-in user, it calls
"pam_open_session()". That's what sshd and /sbin/login and GDM have been
doing for decades before systemd – pam_systemd is just one more module
that's listed in /etc/pam.d/sshd.

It's probably safe to assume that x2go uses PAM already, so the first thing
to check is whether it has the correct 'session' modules in /etc/pam.d/x2go
or similar. On Ubuntu it should be including the "common-session" file.
There *might* be some complications, e.g. it not passing some of the
necessary fields to PAM, or calling pam_open_session() in the wrong process
that makes it a no-op, or the process doing everything might immediately
exit...

(For example, if the login is actually handled via SSH and not by X2go
itself, then it might be a similar issue as with Mosh – sshd logs you in,
creates a session, does everything properly... but the session immediately
ends as its only purpose was to bootstrap mosh-server, and once that's
running the client disconnects and sshd does pam_close_session() even
though your apparent Mosh "login" has just begun. Although, with current
systemd versions this at least leaves you a "closing" session, which is
still better than nothing.)

As a last resort, you could ask systemd-logind to always keep your 'systemd
--user' instance running by doing `loginctl enable-linger $USER`. That'll
give you a permanently available $XDG_RUNTIME_DIR/bus and everything else,
even if you're not logged in "correctly", though you'll still need to set
$XDG_RUNTIME_DIR and such by hand. (The bus is only a means for snapd to
access 'systemd --user', though.)


> I have no practical understanding of the login process, so I am bad person
> to be asking this question, but no one else seems to trying. Just a lot of
> complaining users adding to the bug report.
>
> I use nomachine, and while I have mentioned my suspicions to their tech
> support, I can't be very technically convincing since I don't understand
> what has changed in the 

[systemd-devel] (no subject)

[Tim Richardson]

There is a long standing and long bug report in Ubuntu which attributes the
inability to start the Firefox snap (or any snap with sandboxing) to snapd.
In fact, the users having this problem mostly have in common that their
session is started with a remote desktop session.
such as
nomachine (workstation, which starts a virtual session) and x2go, and
sometimes various vnc connections, those which spawn remote sessions rather
than screen sharing an existing session, I suspect.

Comment 17 implies that the problem is the user session is not being setup
correctly.
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491/comments/17


An expert commentor Maciej Borzecki said:
I've commented before, but if your desktop session is correctly set up,
the systemd --user instance should be available, then a transient scope
can be created for snap and proper device access filtering can be set up
in that cgroup, thus completing the sandbox. Cgroup v1 works
differently, in that there is a separate hierarchy which could be set up
for a snap and there's no need to ask ssytemd to set up anything on
behalf of the snap. This is no longer the case for v2.

AFAICT gdm/kdm/xdm seem to be able to do that correctly. Most trouble
seems to be coming from X2go/vnc or similar solutions which appear to
give you a desktop access, but it's half baked, and are either missing
session dbus or the systemd --user instance. Perhaps it's not really
going through PAM, hence things that would have been set up through
pam_systemd are missing.

Specifically, the environment variable DBUS_SESSION_BUS_ADDRESS is not
correct.

A typical fix is for users to do this:

export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"


before running the snap.
snaps are surfacing this problem for some reason but I don't think it is
snap problem. When the snap launches it finds itself in an unexpected
cgroup.

In one of my experiments, running systemd --user in a shell and starting a
snap from there worked. It was when I compared the environment generated
here vs the environment after logging in via nomachine that I discovered
the workaround of exporting that variable. But it is not a very good
workaround. It only allows one session per user, for instance.

I think the problem is in the login stage, as Maciej says.
I can't find documentation on how the "modern" login process works, at
least detailed enough to explain how you make sure the pam_systemd setup is
invoked. I got lost in the scripts trying to work it out.
I have no practical understanding of the login process, so I am bad person
to be asking this question, but no one else seems to trying. Just a lot of
complaining users adding to the bug report.

I use nomachine, and while I have mentioned my suspicions to their tech
support, I can't be very technically convincing since I don't understand
what has changed in the login process causing them to miss something.

x2go is barely maintained, which is a hint to me that the login process
needs some kind of systemd enhancement missing in older code.

Is there someone on this mailing list who can join the dots and give good
clues about what might be going wrong with the login process of nomachine,
x2go etc

How could I prove to nomachine tech support that nomache workstation iis
not logging in correctly?


-- 
Tim Richardson

[systemd-devel] (no subject)

[Sascha Daoudia]

Sascha Daoudia 

[systemd-devel] (no subject)

[Narayana yeruva]

Okay

[systemd-devel] (no subject)

[Sascha Daoudia]

S. Dadudida

[systemd-devel] (no subject)

[Cloud90 Workspace]

[systemd-devel] (no subject)

[Haradhan Sharma]

Dec  1 04:39:04 vmi1027878 systemd: Starting Web server Apache...
Dec  1 04:39:10 vmi1027878 kernel: Firewall: *TCP_IN Blocked* IN=eth0
OUT= MAC=00:50:56:48:14:f9:74:83:ef:4e:ae:4b:08:00 SRC=67.11.199.196
DST=38.242.209.222 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=64136 DF
PROTO=TCP SPT=57544 DPT=30303 WINDOW=64240 RES=0x00 SYN URGP=0
Dec  1 04:39:11 vmi1027878 systemd: httpd.service: control process
exited, code=exited status=1
Dec  1 04:39:11 vmi1027878 systemd: Failed to start Web server Apache.
Dec  1 04:39:11 vmi1027878 systemd: Unit httpd.service entered failed state.
Dec  1 04:39:11 vmi1027878 systemd: httpd.service failed.
Dec  1 04:39:11 vmi1027878 kernel: Firewall: *TCP_IN Blocked* IN=eth0
OUT= MAC=00:50:56:48:14:f9:74:83:ef:4e:ae:4b:08:00 SRC=67.11.199.196
DST=38.242.209.222 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=64137 DF
PROTO=TCP SPT=57544 DPT=30303 WINDOW=64240 RES=0x00 SYN URGP=0
Dec  1 04:39:13 vmi1027878 kernel: Firewall: *TCP_IN Blocked* IN=eth0
OUT= MAC=00:50:56:48:14:f9:74:83:ef:4e:ae:4b:08:00 SRC=67.11.199.196
DST=38.242.209.222 LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=64138 DF
PROTO=TCP SPT=57544 DPT=30303 WINDOW=64240 RES=0x00 SYN URGP=0

Very Best

[systemd-devel] (no subject)

[Ricardo Elias Giraldo Gartner]

unsuscribe

-- 
*ri*


*Ricardo Elías Giraldo Gärtner*
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] (no subject)

[Noe Rentería]

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

[systemd-devel] (no subject)

[Noe Rentería]

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

Re: [systemd-devel] firewalld subject: allowing icmp echo-request

[Lennart Poettering]

On Fr, 06.12.19 12:17, Andy Pieters (syst...@andypieters.me.uk) wrote:

> Hi everyone
>
> This is on Centos 7.7.1908 and firewalld 0.6.3
>
> I could not find a firewalld-specific mailing list and I hope it is ok
> to ask it here.

This is the systemd mailing list. There's no overlap between systemd
and firewalld, neither technical nor in people.

Hence, please contact the firewalld community about this (maybe you
can track down a maintainer email at least), or your distro's
community, but this is really not the place to discuss this, we really
want to keep noise level down here.

Thank you for understanding,

Lennart

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

Re: [systemd-devel] firewalld subject: allowing icmp echo-request

[Andy Pieters]

On Fri, 6 Dec 2019 at 13:08, Kenneth Porter  wrote:
>
> --On Friday, December 06, 2019 12:17 PM + Andy Pieters
>  wrote:
>
> > This is on Centos 7.7.1908 and firewalld 0.6.3
> >
> > I could not find a firewalld-specific mailing list and I hope it is ok
> > to ask it here.
>
> firewalld list is here. It's been pretty quiet lately.
>
> 
Thank you I see it now on google it's the 9th result. It's been very
rare that I had to scroll down that far to find something on google
though.
>
> > I wanted to allow pings on a LAN server
>
> I didn't do anything special to allow ICMP. I notice that one of your links
> suggests making the drop zone the default zone. That may be the source of
> the problem.

I think I reverted everything that didn't work

> Try posting the output of "firewall-cmd --list-all-zones" and/or
> "iptables-save" to a pastebin for readers to inspect.
>
here it is with thanks: https://pastebin.com/CzRt8ht6


Thank you

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

Re: [systemd-devel] firewalld subject: allowing icmp echo-request

[Kenneth Porter]

--On Friday, December 06, 2019 12:17 PM + Andy Pieters 
 wrote:



This is on Centos 7.7.1908 and firewalld 0.6.3

I could not find a firewalld-specific mailing list and I hope it is ok
to ask it here.


firewalld list is here. It's been pretty quiet lately.




I wanted to allow pings on a LAN server


I didn't do anything special to allow ICMP. I notice that one of your links 
suggests making the drop zone the default zone. That may be the source of 
the problem.


Try posting the output of "firewall-cmd --list-all-zones" and/or 
"iptables-save" to a pastebin for readers to inspect.




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

[systemd-devel] firewalld subject: allowing icmp echo-request

[Andy Pieters]

Hi everyone

This is on Centos 7.7.1908 and firewalld 0.6.3

I could not find a firewalld-specific mailing list and I hope it is ok
to ask it here.

I wanted to allow pings on a LAN server and have tried a number [1] of
[2] different [3] things[4]. After adding the direct rules and
inspecting the iptables output, I see the direct rule that allows ICMP
ping is being matched (the packet counter increases), however the
packet is still being dropped somewhere.

The closest I have gotten to getting ping to work is by adding a
source to the trusted zone, but I do not want to add the entire
network to the trusted zone, nor relax the public zone to the point of
allowing everything just to make this echo working.

Any suggestions, please? Pointers to more suitable mailing lists also welcome.

Thank you

Andy

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-managing_icmp_requests
[2] https://www.tecmint.com/firewalld-rules-for-centos-7/2/
[3] 
https://superuser.com/questions/1114065/getting-firewalld-to-allow-ping-requests
[4] 
https://superuser.com/questions/853207/firewalld-allowing-icmp-in-custom-zone-centos-7-redhat-7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] (no subject)

[Lennart Poettering]

On Fr, 19.01.18 18:16, Reindl Harald (h.rei...@thelounge.net) wrote:

> if you don't bother to write a subject it can't be that important

Reindl, it's not necessary to constantly write such snarky
replies. Please be more friendly if mailing list submissions aren't up
to your standards right-away.

Lennart

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

Re: [systemd-devel] (no subject)

[Reindl Harald]

Am 19.01.2018 um 18:22 schrieb Matt Zagrabelny:
On Fri, Jan 19, 2018 at 11:16 AM, Reindl Harald > wrote:


if you don't bother to write a subject it can't be that important

Sometimes people make mistakes. Like forgetting to enter a subject. 
Don't assume the worst


proper mail clients ask if you menat that serious and before compose a 
mail i normally summarize it's content in the subejct before start to 
write it anyways

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

Re: [systemd-devel] (no subject)

[Matt Zagrabelny]

On Fri, Jan 19, 2018 at 11:16 AM, Reindl Harald 
wrote:

> if you don't bother to write a subject it can't be that important
>

Sometimes people make mistakes. Like forgetting to enter a subject. Don't
assume the worst.

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

Re: [systemd-devel] (no subject)

[Reindl Harald]

if you don't bother to write a subject it can't be that important
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] (no subject)

[philip is hungry]

I am trying to use "sd_watchdog_enabled".  If I run my service without forking, 
the sd_watchdog_enabled function works as expected:

Jan 18 15:05:29 thinkpad systemd[1]: Starting WaitonlyServer...
Jan 18 15:05:30 thinkpad waitonly[11172]: PID before fork  = 11172
Jan 18 15:05:30 thinkpad waitonly[11172]: Return from lockme = 0
Jan 18 15:05:30 thinkpad waitonly[11172]: PID to compare with watchdog_pid: 
11172
Jan 18 15:05:30 thinkpad waitonly[11172]: Return from watchdog = 1

however if i run the forkme function (to put process in the background) it 
behaves as follows:

Jan 18 15:06:25 thinkpad waitonly[11228]: Return from forkme = 11228
Jan 18 15:06:25 thinkpad waitonly[11228]: Return from lockme = 0
Jan 18 15:06:25 thinkpad waitonly[11228]: PID to compare with watchdog_pid: 
11228
Jan 18 15:06:25 thinkpad waitonly[11228]: systemd watchdog not enabled - not 
sending watchdog keepalives!
Jan 18 15:06:25 thinkpad waitonly[11228]: systemd watchdog pid = -1905553534
Jan 18 15:06:25 thinkpad waitonly[11228]: Return from watchdog = 0

where am I going wrong? any help with this is greatly appreciated.

thanks!

main.c ---

pid_t pid;
int watchdogInfo = 0;
int ret;

int main() {

  setlogmask (LOG_UPTO (LOG_INFO));
  openlog (NULL, LOG_CONS | LOG_PID | LOG_NDELAY, LOG_LOCAL1);

  pid = getpid();
  syslog (LOG_NOTICE, "PID before fork  = %d", pid);
  ret = forkme();
  syslog (LOG_NOTICE, "Return from forkme = %d", ret);

  ret = lockme();
  syslog (LOG_NOTICE, "Return from lockme = %d", ret);

  pid = getpid();
  syslog (LOG_NOTICE, "PID after fork  = %d", pid);

  watchdogInfo = systemd_get_watchdog_time();
  syslog (LOG_NOTICE, "Return from watchdog = %d", watchdogInfo);

  for (;;) { // Run forever
    sleep(10);
    syslog (LOG_NOTICE, "Service Running...");
}
}

forkme.c ---

pid_t pid;
int forkme(void) {
  if ((pid = fork()) < 0)
    exit(1);
  else if(pid != 0) /* parent */
    exit(0);
  setsid();
}

lockme.c ---

#define LOCKFILE "/var/run/waitonly.pid"
#define LOCKMODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH)

int lockme(void)
{
  int fd;
  char buf[16];
  fd = open(LOCKFILE, O_RDWR|O_CREAT, LOCKMODE);
  if (fd < 0) {
    syslog(LOG_ERR, "can’t open %s: %s", LOCKFILE, strerror(errno));
    exit(1);
  }
  ftruncate(fd, 0);
  sprintf(buf, "%ld", (long)getpid());
  write(fd, buf, strlen(buf)+1);
  return(0);
}

systemd.c ---

//  return watchdog - 0 means that watchdog is not enabled
int systemd_get_watchdog_time(void)
{
uint64_t usec;
char *watchdog = NULL;
char *watchdog_pid = NULL;
int ret;

ret = sd_watchdog_enabled(0, );

if (ret == 0) {
  syslog (LOG_NOTICE, "systemd watchdog not enabled - not sending watchdog 
keepalives!");
  watchdog_pid = getenv("WATCHDOG_PID");
  syslog (LOG_NOTICE, "systemd watchdog pid = %d", watchdog_pid);
}
if (ret < 0) {
  syslog (LOG_NOTICE, "systemd watchdog returned error %d - not sending 
watchdog keepalives", ret);
}
}
waitonly.service 
---
[Unit]Description=WaitonlyServer 
After=syslog.target networking.service
OnFailure=heartbeat-failed@%n.service

[Service]
Nice=-5
Type=forking
NotifyAccess=all
StartLimitInterval=3m
StartLimitBurst=3
TimeoutSec=1m
WatchdogSec=60s
PIDFile=/var/run/waitonly.pid
RestartSec=5
Restart=on-abnormal
LimitNOFILE=1024
ExecStart=/usr/bin/waitonly
ExecStop=/usr/bin/kill $MAINPID
ExecReload=/usr/bin/kill -HUP $MAINPID


[Install]
WantedBy=multi-user.target
   ___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] (no subject)

[systemd-devel-bounces]

From graw...@gmail.com Sat Aug 22 17:58:23 2015
MIME-Version: 1.0
References: 55d850ac.2050...@poczta.onet.pl
In-Reply-To: 55d850ac.2050...@poczta.onet.pl
Message-ID: CAPWNY8XAt8SebPVd3ZOJ46rzcg=kmv68wujoazou7_hgzia...@mail.gmail.com
Date: Sat, 22 Aug 2015 14:58:24 +
Subject: Re: [systemd-devel] user/session buses
From: =?UTF-8?Q?Mantas_Mikul=C4=97nas?= graw...@gmail.com
To: =?UTF-8?Q?Micha=C5=82_Zegan?= webczat_...@poczta.onet.pl, 
systemd-devel@lists.freedesktop.org
Content-Type: multipart/alternative; boundary=001a114b9560bdfa07051de79d10

--001a114b9560bdfa07051de79d10
Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
Content-Transfer-Encoding: base64

V2VsbCwgeW91IGp1c3Qgd291bGRuJ3QgaGF2ZSBtb3JlIHRoYW4gb25lIGdyYXBoaWNhbCBzZXNz
aW9uLiBUaGF0J3MgcGFydCAgDQpvZiB0aGUgZ2VuZXJhbCBwbGFuIGFmYWlrLg0KDQpOb3RlIHRo
YXQgdGhpcyBpcyBhbHJlYWR5IGhhbGYtYnJva2VuLCBiZWNhdXNlIHNvbWUgb2YgdGhvc2UgcHJv
Z3JhbXMgIA0KYWN0dWFsbHkgKmV4cGVjdCogdG8gYmUgdW5pcXVlICpwZXIgdXNlciog4oCTIGVn
IGRjb25mLWRhZW1vbiBmb3Igd3JpdGluZyB0byAgDQp0aGUgZGNvbmYgZGIg4oCTIGFuZCBoYXZp
bmcgdHdvIGNvcGllcyBvZiBpdCBpbiB0d28gc2Vzc2lvbnMgbWlnaHQgYmUgYmFk4oCmDQoNCg0K
DQpPbiBTYXQsIEF1ZyAyMiwgMjAxNSwgMTM6MzYgTWljaGHFgiBaZWdhbiA8d2ViY3phdF8yMDBA
cG9jenRhLm9uZXQucGw+IHdyb3RlOg0KDQoNCkhlbGxvLg0KDQpJIGJlbGlldmUsIGFsdGhvdWdo
IG1heSBiZSB3cm9uZywgdGhhdCBzZXNzaW9uIGJ1c2VzIHdlcmUgdXNlZCB0bw0KZW5mb3JjZSBz
aW5nbGUgaW5zdGFuY2VzIG9mIHByb2dyYW1zLCBsaWtlIGEgcHJvZ3JhbSByZWdpc3RlcmVkIGEg
bmFtZQ0Kb24gZGJ1cyBhbmQgYW5vdGhlciBpbnN0YW5jZSBvZiB0aGUgc2FtZSBwcm9ncmFtIGNv
dWxkIG5vdCBydW4uDQpIb3cgd291bGQgaXQgYWZmZWN0IHVzZXIgYnVzZXMgaW4gY2FzZSBvZiBt
dWx0aXBsZSBncmFwaGljYWwgdXNlciBzZXNzaW9ucz8NCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpzeXN0ZW1kLWRldmVsIG1haWxpbmcgbGlzdA0Kc3lz
dGVtZC1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcNCmh0dHA6Ly9saXN0cy5mcmVlZGVza3Rv
cC5vcmcvbWFpbG1hbi9saXN0aW5mby9zeXN0ZW1kLWRldmVsDQoNCg0K
--001a114b9560bdfa07051de79d10
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

p dir=3DltrWell, you just wouldn#39;t have more than one graphical ses=
sion. That#39;s part of the general plan afaik./p
p dir=3DltrNote that this is already half-broken, because some of those=
 programs actually *expect* to be unique *per user* =E2=80=93 e.g. dconf-da=
emon for writing to the dconf db =E2=80=93 and having two copies of it in t=
wo sessions might be bad=E2=80=A6/p
brdiv class=3Dgmail_quotediv dir=3DltrOn Sat, Aug 22, 2015, 13:36=
=C2=A0Micha=C5=82 Zegan lt;a href=3Dmailto:webczat_...@poczta.onet.pl;w=
ebczat_...@poczta.onet.pl/agt; wrote:br/divblockquote class=3Dgmai=
l_quote style=3Dmargin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1exHello.br
br
I believe, although may be wrong, that session buses were used tobr
enforce single instances of programs, like a program registered a namebr
on dbus and another instance of the same program could not run.br
How would it affect user buses in case of multiple graphical user sessions?=
br
___br
systemd-devel mailing listbr
a href=3Dmailto:systemd-devel@lists.freedesktop.org; target=3D_blanksy=
stemd-de...@lists.freedesktop.org/abr
a href=3Dhttp://lists.freedesktop.org/mailman/listinfo/systemd-devel; rel=
=3Dnoreferrer target=3D_blankhttp://lists.freedesktop.org/mailman/list=
info/systemd-devel/abr
/blockquote/div
--001a114b9560bdfa07051de79d10--
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] (no subject)

[Andrey Shinkevich]

Hello,
 
My name is Andrey. I would like to activate a service by socket or D-Bus and  
stop it when unneeded. The activation works fine but I failed to find a way how 
the service can be stopped/deactivated automatically when it is no longer 
needed by using applications.
Would you please help me with information on that subject? I will appreciate.
 
Kind regards,  
Andrey Shinkevich___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] (no subject)

[Lennart Poettering]

On Tue, 02.12.14 23:50, Andrey Shinkevich (andys...@mail.ru) wrote:

Heya,

 My name is Andrey. I would like to activate a service by socket or
 D-Bus and stop it when unneeded. The activation works fine but I
 failed to find a way how the service can be stopped/deactivated
 automatically when it is no longer needed by using applications.

Services need to determine internally when they are idle and then
exit. We cannot determine from the outside if a daemon is idle, and
hence we cannot decide when the right time would be to shut down a
service.

There might be a variety of reasons why a daemon is busy: it might be
client connections, and all kinds of background work, but systemd from
the outside cannot really know much about that.

Please contact the authors of the daemons you are interested in, and
ask them to consider implementing an exit-on-idle logic.

Lennart

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

[systemd-devel] (no subject)

[К В]

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

[systemd-devel] (no subject)

[Tony Seo]

Hello.
I tried to execute a process by using socket activation.
As it is referred at systemd manual, I made  server and client process
by using sd-daemon.h and sd-daemon.c.
when I made those processes, I used UDS(Unix Domain Socket) to make
communication between server and client.
(I also made /run/test_server which executes like /run/foobar.sk in
example of systemd manual for socket activation)
http://0pointer.de/blog/projects/socket-activation.html

And then, In order to make the process started, I made test_server.socket
and test_server.service.
those thing have contents like below:

test_server.socket---
[Socket]
ListenStream=/run/test_server

[Install]
WantedBy=sockets.target


test_server.service---
[Service]
Type=oneshot
ExecStart=/bin/sh /usr/bin/kill-avn-process.sh
StandardOutput=journal+console
TTYPath=/dev/ttyTCC0


[Install]
WantedBy=multi-user.target



As soon as I executed the client process, test_server.service worked
rapidly but it seemed to run in infinite loop with changing it's PID and
then, it showed  that error messages like:
systemd[1]: test_server.service start request repeated too quickly,
refusing to start.
systemd[1]: Failed to start test_server.service.

I already knew that a process executed by socket activation would be
respawn.
But, what the important thing is that I don't know how to control the
number of respawn.
And, why does systemd make the error about request timing.

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

Re: [systemd-devel] (no subject)

[David Timothy Strauss]

I replied in the thread with a subject line.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] (no subject)

[Yang Zhiyong]

Signed-off-by: Yang Zhiyong yangzy.f...@cn.fujitsu.com
---
 src/udev/udevadm-settle.c |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)
 mode change 100644 = 100755 src/udev/udevadm-settle.c

diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
old mode 100644
new mode 100755
index c4fc4ee..cacc7e3
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -62,8 +62,13 @@ static int adm_settle(struct udev *udev, int argc, char 
*argv[])
 int seconds;
 
 option = getopt_long(argc, argv, s:e:t:E:qh, options, NULL);
-if (option == -1)
+if (option == -1) {
+if (optind  argc) {
+fprintf(stderr, unknown option\n);
+exit(EXIT_FAILURE);
+}
 break;
+}
 
 switch (option) {
 case 's':
@@ -74,10 +79,14 @@ static int adm_settle(struct udev *udev, int argc, char 
*argv[])
 break;
 case 't':
 seconds = atoi(optarg);
-if (seconds = 0)
+if (seconds  0)
 timeout = seconds;
-else
+else if (seconds == 0  !strcmp(optarg,0))
+timeout = seconds;
+else {
 fprintf(stderr, invalid timeout value\n);
+exit(EXIT_FAILURE);
+}
 break;
 case 'q':
 quiet = 1;
-- 
1.7.1


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

Re: [systemd-devel] (no subject)

[Wanlong Gao]

On 10/22/2013 05:03 PM, Yang Zhiyong wrote:
 Signed-off-by: Yang Zhiyong yangzy.f...@cn.fujitsu.com

You missed the patch subject and change log.

Thanks,
Wanlong Gao

 ---
  src/udev/udevadm-settle.c |   15 ---
  1 files changed, 12 insertions(+), 3 deletions(-)
  mode change 100644 = 100755 src/udev/udevadm-settle.c
 
 diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
 old mode 100644
 new mode 100755
 index c4fc4ee..cacc7e3
 --- a/src/udev/udevadm-settle.c
 +++ b/src/udev/udevadm-settle.c
 @@ -62,8 +62,13 @@ static int adm_settle(struct udev *udev, int argc, char 
 *argv[])
  int seconds;
  
  option = getopt_long(argc, argv, s:e:t:E:qh, options, 
 NULL);
 -if (option == -1)
 +if (option == -1) {
 +if (optind  argc) {
 +fprintf(stderr, unknown option\n);
 +exit(EXIT_FAILURE);
 +}
  break;
 +}
  
  switch (option) {
  case 's':
 @@ -74,10 +79,14 @@ static int adm_settle(struct udev *udev, int argc, char 
 *argv[])
  break;
  case 't':
  seconds = atoi(optarg);
 -if (seconds = 0)
 +if (seconds  0)
  timeout = seconds;
 -else
 +else if (seconds == 0  !strcmp(optarg,0))
 +timeout = seconds;
 +else {
  fprintf(stderr, invalid timeout value\n);
 +exit(EXIT_FAILURE);
 +}
  break;
  case 'q':
  quiet = 1;
 

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

[systemd-devel] (no subject)

[Sean McGovern]

Here is my new attempt for interface naming for cards in non-zero domains.
Oddly enough, I still get an f0 at the end of mine even though it is not
PCI multifunction.

sean@hanyuu ~ $ udevadm test-builtin net_id /sys/class/net/enP2p32s15f0 
2/dev/null | grep PATH
ID_NET_NAME_PATH=enP2p32s15

sean@hanyuu ~ $ udevadm info /sys/class/net/enP2p32s15f0 2/dev/null | grep 
NAME_PATH
E: ID_NET_NAME_PATH=enP2p32s15f0


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

Re: [systemd-devel] no subject

[Lennart Poettering]

On Wed, 17.10.12 16:16, Dennis Semakin (insan...@yandex.ru) wrote:

 Hi,
 
 I'm currently compiling systemd-194.
 Very often I get the error about undeclarated definitions MS_REC, MS_PRIVATE, 
 MS_MOVE... in mount func.
 I know that's because of old glibc headers...
 But. may be it would be useful to write something like that:
 
 #ifndef MS_REC  /* May not be defined in older glibc headers */
 #define MS_REC 16384
 #endif
 
 #ifndef MS_PRIVATE  /* May not be defined in older glibc headers */
 #define MS_PRIVATE (118) /* change to private */
 #endif
 
 #ifndef MS_SLAVE/* May not be defined in older glibc headers */
 #define MS_SLAVE (119) /* change to slave */
 #endif
 
 #ifndef MS_SHARED   /* May not be defined in older glibc headers */
 #define MS_SHARED (120) /* change to shared */
 #endif
 
 For those who didn't want or can update glibc.

We actually have a number of definitions like these in
src/shared/missing.h. How old is your glibc? If it is Ok'ish old, and
you are convinced enough that there is value in supporting this upstream
we could add these missing definitions to missing.h given that the
change would be simple. Patch appreciated!

Lennart

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

Re: [systemd-devel] (no subject)

[Lennart Poettering]

On Mon, 03.09.12 23:46, Colin Guthrie (co...@mageia.org) wrote:

 Hi,

Heya,
 
 OK, so these are the changes I'd propose to fix the issues mentioned
 in this thread. I've not tested them so this is more for general
 feedback as to whether this approach is generally a good one or not.
 
 The initial patch is just extra debugging I added to try and work out
 why my gdm session is not marked with type=greeter so seems like a
 generally useful change when in debug mode.

I merged all your patches. Thanks!

I made one little change though: the require_active parameter now is a
tree state:

 0   -- return *all* sessions/seats of a user
== 0  -- return online/active sessions/seats of a user
 0   -- return active sessions/seats of a user

I think this is the nicest way to model this. It does change a bit the
meaning of the param from before but one could argue that this change
actually unbreaks PA without making any changes necessary in PA, right? 

(I update the man page accordingly)

Thanks for the thorough investigation of the problem and the flawless
patches!

Thanks,

Lennart

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

Re: [systemd-devel] (no subject)

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 12/09/12 07:34 did gyre and gimble:
 On Mon, 03.09.12 23:46, Colin Guthrie (co...@mageia.org) wrote:
 
 Hi,
 
 Heya,

 OK, so these are the changes I'd propose to fix the issues mentioned
 in this thread. I've not tested them so this is more for general
 feedback as to whether this approach is generally a good one or not.

 The initial patch is just extra debugging I added to try and work out
 why my gdm session is not marked with type=greeter so seems like a
 generally useful change when in debug mode.
 
 I merged all your patches. Thanks!

\o/

 I made one little change though: the require_active parameter now is a
 tree state:
 
  0   -- return *all* sessions/seats of a user
 == 0  -- return online/active sessions/seats of a user
 0   -- return active sessions/seats of a user
 
 I think this is the nicest way to model this. It does change a bit the
 meaning of the param from before but one could argue that this change
 actually unbreaks PA without making any changes necessary in PA, right? 
 
 (I update the man page accordingly)

Yup, I prefer these semantics too TBH (I think that's what I said in my
mail after the patch was written. And yes, this should mean no changes
are needed in PA (or other similar programs which could be affected),
which I think is better even with the slight change in the meaning of
the param.

 Thanks for the thorough investigation of the problem and the flawless
 patches!

No worries :)

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] (no subject)

[Colin Guthrie]

Hi,

OK, so these are the changes I'd propose to fix the issues mentioned
in this thread. I've not tested them so this is more for general
feedback as to whether this approach is generally a good one or not.

The initial patch is just extra debugging I added to try and work out
why my gdm session is not marked with type=greeter so seems like a
generally useful change when in debug mode.

Cheers

Col


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

Re: [systemd-devel] (no subject)

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 03/09/12 23:46 did gyre and gimble:
 Hi,
 
 OK, so these are the changes I'd propose to fix the issues mentioned
 in this thread. I've not tested them so this is more for general
 feedback as to whether this approach is generally a good one or not.
 
 The initial patch is just extra debugging I added to try and work out
 why my gdm session is not marked with type=greeter so seems like a
 generally useful change when in debug mode.

It seems that while I still think the principle behind these changes
makes sense, that the various env var files are simply not updated
correctly when various changes occur:

e.g. compare the output and note the discrepancy in the [Ss]tate= values:

[colin@jimmy systemd (master)]$ loginctl show-session 1
Id=1
Timestamp=Tue, 04 Sep 2012 00:27:37 +0100
TimestampMonotonic=12876139
DefaultControlGroup=name=systemd:/user/gdm/1
VTNr=1
Display=:0
Remote=no
Service=gdm-launch-environment
Leader=3075
Audit=1
Type=x11
Class=user
Active=no
State=closing
KillProcesses=no
IdleHint=no
IdleSinceHint=1346714860433194
IdleSinceHintMonotonic=16273801
Name=gdm

[colin@jimmy systemd (master)]$ cat /run/systemd/sessions/1
# This is private data. Do not parse.
UID=492
USER=gdm
ACTIVE=0
STATE=online
REMOTE=0
KILL_PROCESSES=0
TYPE=x11
CLASS=user
CGROUP=/user/gdm/1
FIFO=/run/systemd/sessions/1.ref
SEAT=seat0
DISPLAY=:0
SERVICE=gdm-launch-environment
VTNR=1
LEADER=3075
AUDIT=1




I do have a patch that adds various calls to seat_save(),
session_save(), user_save() at appropriate junctures, but I've not
tested this yet and it would appear to be quite easy to get tied in
knots and add infinite loops!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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