Re: [systemd-devel] [PATCH] keymap: remap microphone mute keycode for Lenovo Thinkcentre M800z

[Daniel Mack]

On 01/06/2016 03:37 AM, Hui Wang wrote:
> This Lenovo machine use codec Line2 to implement a microphone mute
> button, it depends on the unsolicited interrupt to generate key event,
> the scan code for this button is assigned to 0x00 in the linux kernel
> driver, and the keycode is KEY_MICMUTE(248), we need to remap this
> keycode to KEY_F20 to make this hotkey work in X11.
> 
> BugLink: https://bugs.launchpad.net/bugs/1531362
> Signed-off-by: Hui Wang 

FTR: this is merged upstream as 03198122.


Thanks,
Daniel



> ---
>  hwdb/60-keyboard.hwdb | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb
> index 94906ab..69a1e8f 100644
> --- a/hwdb/60-keyboard.hwdb
> +++ b/hwdb/60-keyboard.hwdb
> @@ -652,6 +652,11 @@ 
> evdev:atkbd:dmi:bvn*:bvr*:svnLENOVO*:pn*IdeaPad*Z370*:pvr*
>  evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*Lenovo*V480*:pvr*
>   KEYBOARD_KEY_f1=f21
>  
> +# Lenovo Thinkcentre M800z AIO machine
> +# key_scancode 00 is KEY_MICMUTE
> +keyboard:name:Microphone Mute Button:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*
> + KEYBOARD_KEY_00=f20
> +
>  # enhanced USB keyboard
>  evdev:input:b0003v04B3p301B*
>   KEYBOARD_KEY_90001=prog1 # ThinkVantage
> 

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

Re: [systemd-devel] Unable to store fds with systemd and reterive it back again

[Daniel Mack]

Hi,

On 01/06/2016 12:07 AM, Pathangi Janardhanan wrote:
> Hi All,
> 
>  After trying a few things out, here are couple doubts that I have.
> 
> 1. I am able to get this to work, if I modify the way the sendmsg is
> being done, here is a temp. function that I wrote in my own service
> to mimic the actions of sd_pid_notify_with_pids and with this I am able
> to store the fds with systemd and reterive it back again on a
> service restart.
> 
>  The only real difference is that I do a connect on the socket before
> doing the sendmsg call, and searching through some stuff on google seems
> to indicate that you need to do connect for unix domain sockets, but not
> sure if that is the right thing to do?

It's only necessary to connect() sockets that are in connection mode
(SOCK_STREAM or SOCK_SEQPACKET), but this one is a SOCK_DGRAM socket.

The reason why this is failing is because your systemd version is too
old. All versions prior to v227 have a bug that causes a miscalculation
of the msg_controllen value of the message header, hence the syscall
rightfully fails. Any chance the Ubuntu people could backport a5bd3c32?
Martin?

As a workaround, you basically have to options:

a) open-code the routine as you did, but you can leave off the connect()
call, that's not needed.

b) Pass your own PID to sd_pid_notify_with_fds().

> 2. The other issue I now have, is that after my service is restarted, I
> am able to reterive this and continue to service the client. But I am
> not able to delete this from the systemd state.
> 
>  The sequence is,
> 1. Start the service, and handle some clients
> 2. On a trigger, store the client fds
> 3. Do a systemctl restart of the service, and the service gets these fds
> in the new invocation

This is intended. systemd holds a reference to the file descriptor you
passed, so it will have it ready for you on each start of the service.
This way, if the task just drops everything on idle, or even if it
crashes, all fds that have been passed over earlier will be restored.

> 4. it handles the client and the client closes the connection
> 5. Now I do another restart of the service, but I still get this fd

This shouldn't happen. If the client closes the connection, systemd
should get EPOLLHUP on the fd and remove it from the set of file
descriptors, hence dropping its reference. Are you sure the client
properly closes its side of the communication?


HTH,
Daniel

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

[systemd-devel] Using systemd to as a FD Store to provide service while package upgrade

[Pathangi Janardhanan]

Hi,

I had a previous thread on some issues in using sd_pid_notify_with_fds, but
started this as a separate thread, as this is not just about that call,
which anyway seems to be because I am using a older version.

 I am trying to provide continuous service to connected clients (over TCP
socket) while my service package is being upgraded.

 In regard to that I had a few questions on what is the best way to handle
this:

1. When I initiate the upgrade, I have my service store the fds into
systemd using the call sd_pid_notify_with_fds.

Currently in my package scripts I am doing a service stop and start.
But when I need to do an upgrade, if I do a service stop, systemd clears
all the fds. So would that mean that my package scripts would have to:

 a. In case of upgrade, do not call stop, but ensure that the fds are
saved, and then after the upgrade, ensure that we call a service restart?
Is it safe to remove/change the service files while it is executing?

 b. In case the service package is being removed, do a normal stop in the
scripts

   Is this approach o.k., or are there other recommendations?

2. I had also indicated in the other thread, that systemd does not seem to
clear the fds, even if the fds are actually closed. So to repeat, the
sequence is

   a. First invocation of the service, start servicing the clients, and
then store the fds in systemd
b. Do a restart, the new instance gets these fds, and continues to
service the clients. things work o.k.
c. the client closes the connection, the service also closes all its
state and connection about this client.
d. I do another restart and since at this time there is no client fds,
the service does not store anything with  systemd
e. In the new invocation of my service, in sd_listen_fds, I still get
the older fd that I had stored.
f. currently in my service, this is not a problem, since when my
service tries to do a select on these fds, it gets a notification and then
closes out the fd.

But this behaviour could cause some issues later on, and also since
systemd does not seem to ever let go of the fds, If i continue to do many
restarts, would the set of fds build up to a large set in systemd?

What is the correct approach to handle this situation?

3. Is Systemd intended for this type of fd store for upgrade handling, and
if others have any other approaches or limitations with this approach, that
would be welcome?

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

Re: [systemd-devel] Unable to store fds with systemd and reterive it back again

[Pathangi Janardhanan]

Hi Daniel,
 >It's only necessary to connect() sockets that are in connection mode
>(SOCK_STREAM or SOCK_SEQPACKET), but this one is a SOCK_DGRAM socket.

>The reason why this is failing is because your systemd version is too
>old. All versions prior to v227 have a bug that causes a miscalculation
>of the msg_controllen value of the message header, hence the syscall
>rightfully fails. Any chance the Ubuntu people could backport a5bd3c32?
>Martin?

>As a workaround, you basically have to options:
>a) open-code the routine as you did, but you can leave off the
connect()call, that's not needed.

  Yes, it works without the connect thank you. Maybe I will try to see if I
can locally move to the latest version.

>b) Pass your own PID to sd_pid_notify_with_fds()

 I had tried that before and it does not work, looks like even though my
nfds is never zero, the have_pid flag is causing the issue,
and to set that flag I have to pass a PID that is not my process PID?

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

[systemd-devel] On calendar timer

[arnaud gaboury]

I am not sure about how to express date/time in a timer unit.

I want the timer to be start every year(*), on month 1,3,5,7,9,11,
first day of month at 02:00:00 AM. Here is what I wrote:

[Timer]
OnCalendar=*-1,3,5,7,9,11-01 02:00:00

Is this correct ?

Now if I want instead not the first day of the cited months, but the
first Sunday:

OnCalendar=Sun, *-1,3,5,7,9,11-01 02:00:00

Or the above will only trigger the service IF first day of the cited
month is a Sunday?

Thank you for help

-- 

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

Re: [systemd-devel] Using systemd to as a FD Store to provide service while package upgrade

[Pathangi Janardhanan]

Hi,

 To add, another issue with systemd holding on to the service fds is that
if after a restart, the service does a sd_listen_fds gets the saved fds and
starts providing the service. Later on if the service decides to close a
connection than it performs a close, but the remote client is not going to
see the close, since systemd is still holding on to that fd? So we need to
have a mechanism to be able to tell systemd to
"forgot" all the fds that it is holding on behalf of this service (except
for the fds that are coming through the .socket socket invocation)

Thanks
Jana


On Wed, Jan 6, 2016 at 1:05 PM, Pathangi Janardhanan 
wrote:

> Hi,
>
> I had a previous thread on some issues in using sd_pid_notify_with_fds,
> but started this as a separate thread, as this is not just about that call,
> which anyway seems to be because I am using a older version.
>
>  I am trying to provide continuous service to connected clients (over TCP
> socket) while my service package is being upgraded.
>
>  In regard to that I had a few questions on what is the best way to handle
> this:
>
> 1. When I initiate the upgrade, I have my service store the fds into
> systemd using the call sd_pid_notify_with_fds.
>
> Currently in my package scripts I am doing a service stop and start.
> But when I need to do an upgrade, if I do a service stop, systemd clears
> all the fds. So would that mean that my package scripts would have to:
>
>  a. In case of upgrade, do not call stop, but ensure that the fds are
> saved, and then after the upgrade, ensure that we call a service restart?
> Is it safe to remove/change the service files while it is executing?
>
>  b. In case the service package is being removed, do a normal stop in the
> scripts
>
>Is this approach o.k., or are there other recommendations?
>
> 2. I had also indicated in the other thread, that systemd does not seem to
> clear the fds, even if the fds are actually closed. So to repeat, the
> sequence is
>
>a. First invocation of the service, start servicing the clients, and
> then store the fds in systemd
> b. Do a restart, the new instance gets these fds, and continues to
> service the clients. things work o.k.
> c. the client closes the connection, the service also closes all its
> state and connection about this client.
> d. I do another restart and since at this time there is no client fds,
> the service does not store anything with  systemd
> e. In the new invocation of my service, in sd_listen_fds, I still get
> the older fd that I had stored.
> f. currently in my service, this is not a problem, since when my
> service tries to do a select on these fds, it gets a notification and then
> closes out the fd.
>
> But this behaviour could cause some issues later on, and also since
> systemd does not seem to ever let go of the fds, If i continue to do many
> restarts, would the set of fds build up to a large set in systemd?
>
> What is the correct approach to handle this situation?
>
> 3. Is Systemd intended for this type of fd store for upgrade handling, and
> if others have any other approaches or limitations with this approach, that
> would be welcome?
>
> Thanks
> Jana
>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel